这个用Python写的MPD客户端终于发布了,从写完到发布居然用了快两个月的时间,总共写这个才用了不到一个礼拜,我也不知道中间都干了些什么别的事情……

mpy源于ncmpcr,但比ncmpcr更稳定,更成熟。逻辑控制更清晰,UI也有改善。这一切得力于Python的精简,一行可以做完C几行的任务,这样就可以把 更多精力放在流程控制上。

当然,用Python会有些性能损失。CPU的执行效率在这么一个客户端上并不明显,但内存占用和C还是有差距的。以下是用ps命令检测到的分别在停止/播放/使用一 段时间后的内存占用:

# stop
ncmpcr            6316
ncmpc             6760
mpy              24416
sonata           58644
mpd              65604

# start
ncmpcr            6316
ncmpc             6760
mpy              25036
mpd              65672
sonata           97524

# after a while
ncmpcr            6316
ncmpc             6760
mpy              25036
mpd              68092
sonata          107240

可以看出mpy比ncmpcr多用一些内存,但运行时内存占用还是比较稳定的。ncmpc和sonata是另外两个分别用C和Python写的MPD客户端,可供对比 参考。sonata带图形界面,所以会多吃一些内存。

因为照顾远程使用MPD的用户,把音乐的rating信息保存在了服务器端,存取音乐的rating用了sticker,所以是一条一条进行的,播放列表(不是总的歌 曲数据库)里的歌曲多,而且网速慢的话rate时会有点慢,不过几百首之内都无所谓(网速太慢也没法用MPD吧……)。如果数据库里有成千上万的歌曲的话,就不要都往 播放列表里堆了(几万首也听不完吧……),或者在配置文件里关闭rating这个feature好了。不过还是建议打开这个feature,因为当初就是因为用ncm pc无法记录哪些歌好听哪些歌不好听才写了ncmpcr和后来的mpy的。

当然我后来考虑了一下这个功能实现在客户端也无可非议,因为即便同样的歌曲不同人觉得好听与否都未必一致。而且我觉得多数人都是在localhost上用MPD的。实 现在客户端的话速度就会快很多了。这个改起来不难,只是不知道未来什么时候有时间了。

嗯,就这么多吧。项目主页在http://projects.cykerway.com/ncmpy

Update. 由于在PyPI上名字冲突,mpy已经改名为ncmpy。嗯,这个nc前缀还是没能逃过去。