科技 · 实用指南
Jellyfin升级后播放列表不见了？恢复前先核对显示与条目
列表入口消失、列表变空和媒体路径不可读，需要不同的处理。先保全证据，再选择对应的恢复方法。
播放列表从某个Jellyfin界面消失，并不能证明条目已经删除。先用同一服务器、同一账户，对照Jellyfin网页端与出问题的客户端，再判断列表是完全不显示、显示但为空，还是已有条目却无法播放。
本文提供证据记录和恢复分流方法，不提供数据库修复脚本，适用于升级或重启后列表缺失、变空的情况。历史10.11版本的报告不能证明当前安装仍有同一故障；Jellyfin 12也已改变播放列表条目的存储方式。
1. 先保存现场，再尝试修复
记录改动内容、最后一次正常时间及首次发现故障的时间。妥善保存相关启动、迁移、扫描和清理日志。如果数据库迁移仍在进行，应观察其进度；Jellyfin明确提醒不要在迁移中停止服务器，也不要为测试症状而反复重启。
迁移结束后，按官方备份流程操作。手动复制前须停止服务器，并复制实际使用的数据目录和配置目录。把这份当前状态副本与升级前原始备份分开保存，标记各自对应的服务器版本。故障发生后的备份可能只保存了已受损状态。
2. 确认是否仅为显示问题
在干净的网页会话中，用受影响账户登录同一服务器。对照网页端与第三方客户端的播放列表，检查媒体库筛选条件及所选服务器。每个受影响列表单列一行，记录名称、所有者或共享情况、是否可见、显示条目数以及条目能否打开。
若网页端有完整条目而另一个客户端没有，应先调查该客户端。Feishin维护者曾建议对照客户端播放列表响应与Jellyfin网页界面，但其本人未能复现报告的问题。管理员可在本地检查响应，向外提交求助材料时应移除令牌、Cookie及私人媒体路径。
3. 再次清理前先查存储
如果条目存在但播放失败，应确认Jellyfin能够访问条目引用的准确媒体文件。容器环境须记录当前挂载配置中的主机来源与容器目标路径；主机上可见的文件，未必在容器所用路径中存在。Jellyfin迁移文档要求，将现有安装迁入Docker时保持路径匹配。
Jellyfin任务文档警告，媒体不可访问时，合集和播放列表清理任务可能导致播放列表丢失，而且该任务通常在启动时运行。主动重启或执行清理前，先恢复可靠的媒体访问，并检查任务触发条件。禁用一个触发器不会恢复已丢失的条目，也不能保证解决所有扫描相关问题。
4. 清点真正保留下来的内容
检查旧状态与当前状态的副本，不直接修改运行中的数据库。对每个可能恢复的列表，记录来源快照、预期条目数和按顺序排列的媒体引用。重复出现的同一媒体也应保留各自位置。若只剩名称，或无法理解文件内容，应将成员情况标为未知，不能假定完整。
不要仅因文件名相同，就照搬旧版SQL或XML处理方法。Jellyfin 12已把播放列表条目保存为独立数据库行，并允许重复曲目。因此，基于旧LinkedChildren字段的解释不能通用于当前存储。磁盘上的XML可作为证据，但不能证明当前服务器识别该列表或其所有者。
5. 选择范围明确的恢复方法
仅客户端不一致，就调查客户端；路径不可读，就修复存储。若确认成员丢失且有已知良好备份，可在独立工作副本上，使用与备份匹配的应用版本测试官方恢复流程。与生产数据目录隔离，并避免工具写入原始媒体。不要让旧版服务器直接打开已经迁移的生产数据。
若只保留了部分列表证据，可通过受支持的操作，从已核实媒体重建一个新列表，同时保留原始证据。不要把所有者ID改成全零、合并数据库或批量替换路径当作通用修复。无法确认所有权、顺序或媒体身份的条目，应保留为未解决，并寻求对应版本的帮助。
6. 按列表逐项验收
对照记录表检查恢复后的条目数、每项顺序、重复位置及代表性播放结果，并确认目标用户的可见性和编辑权限。仅名称或数量相同，仍可能掩盖错曲、顺序改变或权限问题。新旧条目ID需要核对，不能自动视为同一媒体的证明。
存储持续可用后，再通过一次受控重启及适用版本要求的扫描验证结果。验收前保留恢复副本。本文是基于来源核验的决策流程，未实际执行Jellyfin迁移或恢复，也无法重建所有存续副本中都已不存在的条目。
