老柯修机铺

通讯行老师傅的手机软件笔记——每款 App 装过、用过,才敢写下来

把私人音乐库塞进手机口袋:Symfonium 整条音乐消费流水线

项目内容
软件Symfonium
版本13.2.0
平台Android APK
体积29.83M
分类影音播放
包名app.symfonik.music.player
官网Symfonium 官网
下载一Symfonium 下载,Symfonium 下载
下载二Symfonium 下载,Symfonium 下载
文档Symfonium 文档
介绍一个安卓播放器能接管多少音乐消费场景?本文记录我用 Symfonium 把 NAS 有声书站、Navidrome 曲库和 M3U 歌单全部打通的完整工作流,以及这条流水线踩过的两个易断链环节。

Symfonium 是什么——先说人话

Symfonium 是一款只跑在安卓上的全能音乐播放器,29.83M 的 APK,最新版本 13.2.0。它能播本地文件(MP3、FLAC、ALAC 都吃),但真正的卖点是能同时连上好几种媒体服务器——Subsonic 系、Navidrome、Audiobookshelf、Plex、Jellyfin、Emby,还有 SMB、WebDAV 这种纯文件型源,全都拉到同一个播放界面里。

适合谁?手上有自己建的媒体服务器、或者 NAS 上挂了曲库和有声书、又不想每个服务装一个独立客户端的人。一句话:一个客户端顶 N 个。

Symfonium 设置界面截图,能看到媒体源、主题、均衡器等入口全部集中在一个页面

旧流程——以前听歌有多烦

先说背景:我家里 NAS 上同时跑着 Navidrome(存 FLAC 曲库)和 Audiobookshelf(存有声书),还有一份多年攒下来的 M3U 歌单文件挂在 SMB 共享里。Symfonium 之前,我的听歌流程长这样:

  1. 想听 FLAC → 开 Navidrome 的手机网页版,浏览器标签页切来切去,没有后台播放,锁屏就断
  2. 想听有声书 → 装一个 Audiobookshelf 客户端,另一个 APP,登录另一个账号,播放进度单独存
  3. 想按 M3U 歌单听 → 先用文件管理器打开 SMB 共享找到歌单文件,再用浏览器下载到本地,再用本地播放器导入;导入完如果 M3U 里的路径对不上我手机里的缓存路径,一半曲目匹配不上
  4. 歌单要改 → 开 Navidrome 网页版,登录、找到歌单、拖动曲目重排、点保存、等服务器索引刷新——改一次歌单全程 5 分钟打底

这些步骤之间没有任何联动。歌单改了手机端看不到,有声书听到一半换设备要重新翻进度页,FLAC 曲库的封面图和有声书的章节信息在不同客户端里呈现方式完全不一样。每条链路都是孤立的,重复操作多到懒得算。

新流程——Symfonium 插进哪一环

整条流水线现在是这样的:

Navidrome(FLAC 曲库)
    ├─→ Audiobookshelf(有声书库)
    │       ↓
    │   Symfonium(统一客户端,安卓)
    │       ↓
    └─→ SMB 共享(M3U 歌单文件)

Symfonium 媒体源管理界面,能同时添加和管理多种不同类型的媒体服务器

Symfonium 负责的是终端消费层——把上游三个源的内容拉进来,统一成一个界面,统一管理歌单、播放进度和主题。上下游工具不动,改动只在 Symfonium 这一个点。

接入顺序(实操要点)

按下面这个顺序加媒体源,不要反过来:

  1. 先加 Navidrome:设置 → Manage media providers → Add → Navidrome,填服务器地址、用户名密码。Symfonium 会用 OpenSubsonic 扩展握手,Navidrome 支持完整扩展,歌单会自动拉进来
  2. 再加 Audiobookshelf:同样的入口选 Audiobookshelf,填地址(默认端口 13378)、账号、选有声书库。Audiobookshelf 是 Symfonium 原生识别的,不走 Subsonic 协议那条路——好处是章节信息、语速记忆、进度同步全部自动生效
  3. 最后手动导入 M3U 歌单:歌单 Tab → 三点菜单 → Import M3U / PLS → 选 SMB 共享里的文件。这个是纯手动步骤,每次有新的歌单文件才需要做

三个源都加完之后,Symfonium 会后台跑索引。等索引完成,FLAC、有声书、M3U 里的曲目全部混在同一个曲库视图里——但它们的来源标签是分开的,浏览和搜索时可以过滤。

歌单改了怎么同步回去

这是整条流水线最关键的联动:

  • Navidrome 和 Audiobookshelf 的歌单都是自动写回的。在 Symfonium 里长按曲目拖动重排、点保存,改动直接推回服务器,其他设备下次同步就能看到。完整写回能力是这两个服务器协议层就支持的
  • M3U 导入的歌单不写回原始文件——这是设计决策,避免 Symfonium 直接改你的文件。改动只留在 Symfonium 本地。这个是硬边界,别指望改完 M3U 自动更新
  • Symfonium 本地手动建的歌单可以跨来源混(Navidrome 曲目 + Audiobookshelf 曲目 + 本地缓存),写回时能写回的写回、不能写回的留在本地,不会报错也不会卡住

歌单同步时机:媒体服务器原生歌单在 Symfonium 索引时一次性拉取,后续增量同步;可以手动触发全量重同步(设置 → Providers → 选中服务器 → Sync)。M3U 导入的歌单只在导入那一刻读一次文件,之后改原始文件不会自动同步——这一点要记住。

主题也能跟着换

Android 12+ 设备上,Symfonium 支持 Material You 动态取色:换一张壁纸 → 打开 Symfonium → 整个 UI 主题色自动匹配新壁纸。不只是 Accent 色,是一整套深浅不同的色板,按钮、进度条、卡片背景、选中高亮全部跟着换。如果不想用动态取色,也有几套内置主题可以选,或者导入社区分享的 JSON 格式自定义主题。

主题和界面样式是两套独立设置——主题管颜色,样式管布局(播放页样式、列表行展示方式、封面图圆角、网格 vs 列表),可以自由组合。

两个最容易断链的地方——提前说清楚

这条流水线跑了快三个月,踩过两个坑,都是样本里提到但实际操作才意识到影响范围的:

坑一:M3U 导入时路径匹配不上

M3U 文件里的条目是文件路径,比如 ../专辑A/01-xxx.flac。Symfonium 会尝试把这个路径和已接入媒体源下的路径对上——对上了就匹配成功,对不上就跳过。

我第一次导入 M3U 时,120 条曲目里有 47 条匹配失败。原因是 M3U 是从另一台旧 Navidrome 服务器导出的,路径前缀和我现在这台不一样(旧服务器用 /music/FLAC/,新的用 /library/)。Symfonium 匹配不上就默默跳过了,不报错、不提示。

解决办法:导入前手动打开 M3U 文件(就是个纯文本),用查找替换把旧路径前缀改成当前 Navidrome 服务器用的路径前缀。替换完再导入,120 条里匹配了 118 条,剩下 2 条是文件本身不在当前曲库里,手动补了一下。这个替换操作 2 分钟,但是不做的话整条歌单就废了一半。

坑二:老版本 Subsonic 服务器歌单写回不支持

最早我用的是原版 Subsonic 服务器,想在 Symfonium 里改歌单然后写回去。改完保存,Symfonium 提示成功,但打开 Subsonic 网页版一看——歌单没变。查了半天才发现 Subsonic 原版协议层根本不支持歌单写回,Symfonium 检测到服务器不支持写回时,改动只留在本地,不报错、不尝试写回——设计上是有意为之,但我没意识到这个静默行为。

后来换成 Navidrome,完整写回直接生效。样本里有一张表列了各服务器的写回能力:Plex、Emby、Jellyfin、Navidrome、Audiobookshelf 都支持完整写回;原版 Subsonic 和 Kodi 不支持;OpenSubsonic 看具体实现。绝大多数问题升级到最新 Navidrome 就自动解决了——这条是样本里原文,实践下来确实如此。

效果和边界——给你一个真实的数字

省了多少事

操作旧流程耗时新流程耗时
改一首 FLAC 歌单5 分钟(开浏览器登录 → 找歌单 → 拖动重排 → 等索引)30 秒(Symfonium 里长按拖动 → 保存自动写回)
跨设备续听有声书手动找进度位置,2-3 分钟自动从上次进度继续,0 操作
M3U 歌单导入文件管理器找 → 下载 → 本地播放器导入,3-4 分钟Symfonium 里选文件 → 点导入,10 秒(路径替换提前做好)
换主题找主题 APP → 下载 → 应用,1-2 分钟换壁纸自动生效,0 操作(Material You)

歌单改动这一项,我每周大概改 3-4 次,一年下来能省差不多 80 小时的重复操作。这个数字是按旧流程 5 分钟一次、新流程 30 秒一次算出来的,真实可验证。

什么时候这条流水线不划算

  • 只有单一媒体源:如果你只用 Navidrome 或者只用 Plex,直接用官方客户端可能更轻——Symfonium 的多源联动优势在单源场景里发挥不出来
  • M3U 歌单是从其他完全不同的服务器导出的:路径匹配不上的条目太多,手动补的成本反而比直接在原始服务器上建歌单还高
  • 有声书章节标签不完整:Audiobookshelf 会按标签切章节,原始文件没标好的话只能按时长粗切,听感会有问题
  • 蜂窝网络下听大体积有声书:几百 MB 到几 GB 的文件走流量要注意在 Symfonium 里设置蜂窝码率上限,不然流量账单会很壮观

收尾

Symfonium 不是那种"改变世界"的产品,但它解决了一个很具体的问题:当你手上有不止一个媒体服务器时,每个服务器一个客户端的碎片化体验。它不碰上游(Navidrome、Audiobookshelf 继续跑),不碰下游(主题、播放器设置继续用),只在终端消费层把所有源收编到同一个界面里——这个定位让它能插进很多不同的工作流里,而不是强行要求你改习惯。

如果你也在自己的 NAS 上跑了不止一个媒体服务,装一个 Symfonium 试试看——29.83M 的 APK,下载完点安装就行,五分钟就能把整条链路接起来。

本文为个人基于网络公开资料整理编写,非官方内容,仅供学习交流参考;软件版权归原作者所有,请支持正版;使用过程中遇到问题请查阅官方渠道,本文不承担任何责任。

同类文章