还好也是自己画的...

用过, API 实在不友好, 如果有选择的话, 可能读 @binux 的 pyspider 会更好.

看了下介绍，就我的理解，这种运行机制对智能播放列表的支持应该很差，于是我就可以忽略这种播放方式了……

另外，我这儿还有不少歌设过非零的起始播放时间和非默认的结束时间，这样我能忽略一些这些现场版的歌的掌声们。这一特性，支持起来虽然不难，但 fb 也应该是没做的（这个信息记得是记录到 xml 里面，而不是写入到音乐文件的）。

DynamicLyric 在我能接受的范围内，挺好用的。我觉得要解决歌词库不全的问题，符合逻辑的做法是找一个靠谱的歌词库，写好 parser ，提交给这些播放插件的开发者。而不是像这样，觉得人行道有点脏就跑大马路上去走。

@lfflyers 关键字 /思路都给到了, 不懂就找资料看嘛～ 程序员不踩坑天天用别人的库哪来的提高~

@diaodada 求消息来源?

嗯, 思路很简单, HTTP 加一个 range 的 header, 读前几个字节, 解出相关信息就行.

@pimin 用它做媒体管理的没人骂它

iTunes 是一个音乐资料库管理器, 它只不过恰好具有同步的功能而已. 如果是以同步的思路或者说想法来看 iTunes, 那你永远没法理解 iTunes 的逻辑. 只有当你往 iTunes 里面放了几千个媒体文件, 用它来管理自己的音乐库, 整理清楚后, 你会理解什么是 iTunes 的逻辑.

iTunes 是有各种各样的问题, 例如偶尔媒体文件会丢专辑封面, 偶尔内置转码器转出来的歌在 iPod/iPhone 上播放不了. 但是, 前面骂 iTunes 的诸位, 对你们而言, 真的不是 iTunes 本身有问题, 而是你们没能用 iTunes 的方式来思考罢了. 你们愿意用更合乎你们想法的东西去做同步这件事情(虽然做法是不是最合理, 有待商榷), 我完全能理解.

Please keep an open mind.

回作者一个吧, 前端问题不要想着后端解决.

看了下这位 @subvim 的发帖, 又看了下这儿的回复, 叹了口气.

对于 python 提高类的书而言, 这本书的结构散了点儿, 更多是 topic 而不是 chapter.

个人还是推荐 Fluent Python 或 Pro Python.

目的是给盗号者增加一些成本吧？

> 毕竟没有最稳定时期的 KDE4 用的舒服

我好怀念 KDE3.5.10...

@DaPanda 求邀, xiaket(at)gmail.com 多谢

@joye1230 网络流量传输不仅仅只有 http 的. 例如, 我走 webdav 的 omnifocus 也不希望人看到, 对吧? 还有那么多邮件, 没办法保证服务提供商都有加密选项.