过气HTPC升级记

HP MICROSEVER GEN8是我钟爱的一款适合当NAS的微型服务器,但当初考虑到客厅三星电视的Tizen ≈ 无系统,NAS+HTPC的方案看起来会挺棒,于是就有了这个(现在看来这是一个坏主意)。

到目前为止(2年来)它的软硬件都经历了不少变化,罗列一下话大概是这样:

OS: SteamOS(Debian) → Ubuntu Desktop → Openmediavault(Debian) → Windows 10 LTSC

MB: Gigabyte B150M D3H → Gigabyte B250M D3H

CPU: Celeron G3900 → Pentium G4560 → Pentium G4600

DIMM: ADATA 2133mhz DDR4 4G*2

OS方面,各种NAS系统其实我试过许多,包括上面没有提及的Nas4Free、Freenas等等,但从整体来看我的OS选择基本上是从Linux到Windows的过渡,这里面其实没什么特别的理由,仅仅是Linux不支持HEVC硬解。

主板是淘汰旧电脑的时候顺手换上的。

CPU方面,G3900换成G4560的原因依然是为了HEVC的硬解(G3900仅支持到HEVC 8Bit),而事实上G4560也依然未能成为4K电影的解决方案,其原因就在于4K电影几乎标配HDR。为了迎合Intel的核显HDR支持方针,我又把CPU换成了搭载HD630的G4600。然而我只算到了显卡的要求,忽视了板载HDMI1.4和DP1.2均无法支持HDR这一点。

接口问题除了上独显或者换主板外基本无解,过高的升级成本让我不得不选择廉价好用的电视盒子来解决影音需求。所以这一整套4K HTPC方案可以说是彻头彻尾的失败品了。

RX 560

其实电视盒子除了需要忍受解不动H264 Hi10P这一点之外作为影音方案已经非常优秀,但轮番用过很多盒子(非高端)后还是有一些小毛小病,如界面卡顿(视频库一旦臃肿后)、莫名其妙地初始化等等。

加上H264 Hi10P这个问题对于常看动画的人来说实在是一个痛点,回归HTPC这个念头始终萦绕在我的心间。

绕着绕着,某天我便打开了闲鱼,于是又有了这个。

没选1030的原因主要是它阉割掉了NVENC,那样的话就无法利用Steam的流式传输投放到房间的电视上了,此外madVR对显卡3D性能有一定要求,1030存在后期继续长草换卡的风险。

而560在AVS论坛的那篇Guide: Building a 4K HTPC for madVR 有作为廉价选择明确被推荐(虽然那边推荐的是Baffin XT,而这张560是Polaris XL的)。

安装显卡前先检查下目前功耗状态,大概30W上下,然后开装。

不得不吐槽下这个支架的位置竟然刚好挡住供电口,原本一插就完事了现在还得连硬盘架一起卸下来。

安装结束,待机功耗50W上下,高了整整20W,稍微超过了点预期(这里也有电源转换率低的原因)。

开机装驱动重启,稍微设置一下lav跟madvr后就大功告成了。

无法逃离PLEX的魔爪

在搞定IPV6后终于可以如愿以偿地在地铁上听PLEX上的歌了,但不知是我家上行带宽太小还是IPV6本身不稳定的缘故,间歇性的连接失败总是在比较尴尬的时刻来临。

想了想我收藏的歌其实也不是很多,为什么不直接把它们丢在第三方公有云上呢。一番搜索后得知吃灰已久的Apple Music已经提供类似网易音乐云盘的功能(iTunes Match)。

PLEX本身不会去修改任何文件信息(比如ID3),所以如果要打算回到iTunes上,那么从源头去整理ID3才是一劳永逸的。

继续一番搜索后找到了这个叫MusicBrainz的服务。

使用下来匹配精度要比PLEX高不少,针对一些疑难杂歌提供的手动匹配功能也非常顺手,唯一的缺点大概就是它只使用自家的数据库以至于确实有一部分刮削不到信息,但对于勤劳的我来说只要能自行编辑数据库那就不是问题。

得益于MusicBrainz优秀的操作体验,我花了大概儿时手动整理歌曲1/100的时间就处理完了大半的歌。

在批量执行ID3写入的时间里我打开了那个又卡又臃肿的iTunes,一边导入音乐库的同时我掏出了手机正准备订阅AM会员。而就在我打算支付的时候我才注意到资料库依旧是空空如也。

嗯!9102年了iTunes还是不支持FLAC。

iTunes再见,PLEX我又回来了。

 

通过IPv6连接你的PLEX服务器

目前国内IPv6的推进速度已经相当不错,对于有家庭服务器需求的用户来说,获取一个不知道能用多久的公网IPv4可能已经远远超过了获得原生IPv6的难度。

长期受到无公网IP的我拿到IPv6后想到的第一件事就是试试能不能透过公网连接自家的PLEX库。

前期工作

首先是配置路由器给局域各网客户机分配地址,不同路由系统对IPv6的自动化配置程度有所差异,我的Ubnt ER-X就属于比较麻烦的那种,好在官方论坛已经有比较详尽的配置示范。

仅仅配置完路由器后还无法通过IPv6测试,打开WIN10的防火墙,添加一条入站规则放行ICMPv6后一切显示正常。

继续阅读“通过IPv6连接你的PLEX服务器”

Embuary中文字体乱码修复

Embuary是我比较喜欢的一个Kodi皮肤,在我看来是kodi众多皮肤中仅有的几个符合现代审美的皮肤之一。

界面基本承袭Emby UI的设计语言,搭配Kodi + Emby这样的融合方案可谓是天衣无缝,虽然当初站了Plex的队,不过自己修改一下配色的话跟Plex也是挺搭的。

此皮肤原生支持Arial字体用于显示中、日等文本,但有一部分文字会显示成口口,打开一些其他插件更是口得一塌糊涂。

继续阅读“Embuary中文字体乱码修复”

记一次春游

前几日二哥打电话过来提议野餐,想到最近几乎每天都在沉迷只狼需要转换下状态,遂赴约。

同行的小伙伴里大部分之前都没有见过,但相处还算愉快,若是四五年前的我的话大概会被自己惊讶到。

四月的第一个星期天已经初具夏天的味道,明媚的光照也非常迎合本次野餐的目的——拍照。

BOSE的Soundlink mini发挥不错,一开腔就赶走了JBL的保温杯,几年前入手的时候就觉得它很适合户外音乐,但真正应用在实际场合这还是第一次。

太湖的夕阳还算别致,二哥喝了不少,我也找到了能拿来写一则大概算得上是日志的东西。

主题更新

一直很喜欢暗黑系的主题,毕竟暗黑就是男人的浪漫。虽然也不止一两次被吐槽过看着压抑这个问题。

前一个主题想要尝试做出Nebula那种感觉,emmmm效果虽然不是很好但应该已经不会感到很压抑了。但是这个主题里使用了大量的块来区分内容,导致整个页面能够显示的内容非常少(如下图)。

这在当时并不算一个重大问题,但如今放在4K分辨率下,偌大的一块区域里只有这么一小部分内容看着实属不适,索性就重新作一版吧。

于是,尽管能够来吐槽主题配色的人早已不知踪影,但这次还是有刻意去弄得明亮一点。虽说是换,但相较旧主题其实未做任何布局变动,因此这只能算是一个2.0版本。

新的主题同样是基于TwentySixteen作简单的样式修改,不同的是这次使用了Child Theme(子主题)的方式进行修改。

Child Theme的本质其实就是引用原主题的布局和样式,再以更高的优先级读取新的布局和样式。这样的修改方式更优雅,可以很清晰看到哪些代码是自己的,哪些是原作者的。并且在原主题更新迭代的同时,Child Theme也可以一并引继以持续保持对WP良好的兼容性。

关于子主题的使用方式,在WP的官方文档里(zh-cn:子主题)已经写得很详细。

 

修复OMV4的Python报错

由于OMV4仍然是一个开发版本, 目前仍有一些小bug,目前发现的有NUT状态异常(提示找不到pid),Python时不时弹出错误信息(通常在安装卸载软件时出现,见下图)。

NUT在今天的插件更新后已经修复,剩下的就是Python了。

Python的报错到目前为止没有发现任何影响,但看到报错放着不管总觉得不太舒服,官方论坛里搜索了一番疑似是Python3.5的一个bug,可以直接修改对应文件解决(链接)

vim /usr/lib/python3.5/weakref.py

分别修改109和117两行即可(删除和高亮部分)

self, *args = args
if len(args) > 1:
raise TypeError(‘expected at most 1 arguments, got %d’ % len(args))
def remove(wr, selfref=ref(self)):
def remove(wr, selfref=ref(self), _atomic_removal=_remove_dead_weakref):
self = selfref()
if self is not None:
if self._iterating:
self._pending_removals.append(wr.key)
else:
# Atomic removal is necessary since this function
# can be called asynchronously by the GC
_remove_dead_weakref(d, wr.key)
_atomic_removal(d, wr.key)
self._remove = remove
# A list of keys to be removed
self._pending_removals = []

 

在Debian Stretch上通过Steam进行游戏串流

Steam在Linux下已经有不少游戏,但这可不是我用它的理由。

Steam的家庭流式传输可以使某台PC上的游戏画面以流媒体的形式传输到同网络下另一台装有Steam的设备上,并接受该设备反馈的按键信息。并且在画面损失和延迟控制方面平衡的相当好。

由于是它的本质是流媒体传输,因此对接受端的硬件要求非常低,只需一台能安装Steam且能流畅播放H264编码视频的机子而已(HTPC绝配)。

安装前首先确保登陆用户拥有以下权限

#usermod -a -G video,audio second_user

添加Steam的Non-free源到/etc/apt/sources.list

# SteamRepo Stretch

deb http://httpredir.debian.org/debian/ stretch main contrib non-free

对于64位的系统须添加i386的支持

dpkg --add-architecture i386

安装并使用aptitude进行包管理使它自动下载相关依赖

apt install aptitude

aptitude update

安装Steam

aptitude install steam

Steam在Stretch上不会像Jessie那样出现各种各样的问题,通常情况下安装完毕后就可以正常登陆。

串流时既可以使用接受设备的控制器(手柄、键盘等),也可直接使用源主机的设备(假如距离不远能收到信号的话)

由于Steam是32位的应用,无法使用64位的驱动,因此需要安装32位驱动才能开启硬件解码,否则在性能较低的设备上可能无法流畅运行。

apt install i965-va-driver:i386
apt install libva1:i386
apt install libva-x11-1:i386
apt install libva-glx1:i386

安装后重启Steam,进入设置>家用流式传输>高级客户端选项

确保硬件解码已经勾选,开启显示性能信息

再次通过流式传输打开游戏,左下方Debug区域Decoder一栏显示VAAPI hardware decoding就代表硬解生效了。

N卡和A卡的驱动及其他相关问题可从在通过以下连接查阅

https://wiki.debian.org/Steam

追记:

Steam的某次更新似乎修改了控制器的规则,在Debian上可能会遇到手柄无法被识别的情况,需自行添建立配置文件。

vim /etc/udev/rules.d/99-steam-controller-perms.rules
# This rule is needed for basic functionality of the controller in Steam and keyboard/mouse emulation
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"

# This rule is necessary for gamepad emulation; make sure you replace 'pgriffais' with a group that the user that runs Steam belongs to
KERNEL=="uinput", MODE="0660", GROUP="pgriffais", OPTIONS+="static_node=uinput"

# DualShock 4 wired
SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", MODE="0666"
# DualShock 4 wireless adapter
SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ba0", MODE="0666"
# DualShock 4 slim wired
SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", MODE="0666"

# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"

# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666"

# DualShock 4 over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:05C4*", MODE="0666"

# DualShock 4 Slim over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:09CC*", MODE="0666"

保存并退出后,重新加载一遍udev

udevadm control --reload
udevadm trigger

再次重启Steam应该就能正常识别手柄了。

在Debian Strech上开启Miredo

Miredo是Debian/Ubuntu上的类Teredo服务,通常可以用它来访问一些ipv6的网络,除此之外,每台Miredo的客户机都可以分到一个2001开头的ipv6 。

这个ipv6对于内网的BT软件是否有实质性的帮助一直都没有确切的说法,但使用Miredo一段时间后观察数据流量,可以发现确实从它上面走了一些流量,可见它虽然帮助不大,但聊胜于无。

Debian的官方源自带Miredo,所以

apt install miredo

查看网卡信息

ifconfig

出现名为teredo的接口即表示安装成功

若出现RTNETLINK permission denied的错误提示

则需要在sysctl.conf的末尾下添加以下几项

vim /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

保存退出重启,这时会遇到另外一个问题。Miredo的默认启动优先级要高于域名解析服务,于是它在每次开机的时候都会因为无法正常解析中继服务器的域名而导致启动失败。

最简单的办法是将这个地址改成IP

vim /etc/miredo.conf

将原有的地址注释掉,添加一条

ServerAddress 83.170.6.76

保存重启后,检查Miredo运行状况

service miredo status

一切正常

尝试ping以下ipv6的域名

依旧正常

这样就算是安装配置完毕了。

在OMV4上安装Transmission并开启自动下载

OMV4的插件库上暂时没有任何BT下载器,虽然使用DOCKER安装一样很方便,但Transmission本身有非常优秀的GUI远端控制,配置完后几乎不需要再去使用WEBUI来管理,因此这里直接通过CLI安装了。

Debian的官方源本身提供Transmission,所以只需

apt install transmission-daemon

安装完毕后先中止服务

service transmission-daemon stop

修改的它的配置文件

vim /etc/transmission-daemon/settings.json

确保相关设置为以下参数以启用远端管理

"rpc-enable" = true,

"rpc-password" = yourpassword,

"rpc-port" = 9091 (or customport),

"rpc-username" = transmission (or customname),

"rpc-whitelist" = "*",

在末尾添加watch相关参数以开启自动下载(非末尾项须逗号结尾)

"watch-dir": "PATH/TO/Watch”,

"watch-dir-enabled": true

保存并退出,重启Transimission应该就能用Transmission Remote GUI连接上了。

此时可直接通过Remote修改其他数值。