FongMi 影视常见问题解答

leanback 是面向电视和遥控器的界面，mobile 面向手机触控。把手机版装进电视后，出现竖屏或焦点难操作，应先核对安装包类型；只改横屏设置不能把手机版变成完整电视版。

1. 在电视的应用信息中记录当前版本，并保存已有配置。
2. 从维护者发布仓库选 leanback 包；手机或平板则选 mobile。
3. 再按设备支持的 ABI 选位数，安装后用方向键和确认键检查焦点。

安装包要匹配 Android 系统支持的 ABI。电视用了 64 位芯片，也可能只提供 32 位应用环境。维护者提供 arm64-v8a 与 armeabi-v7a 包，应查系统支持列表来选择。

1. 用设备信息工具查看“支持的 ABI”，记录是否包含 arm64-v8a。
2. 仅列出 armeabi-v7a 的设备选对应 32 位包。
3. 若仍无法安装，再检查最低 Android 版本、已有应用签名和存储空间。

FongMi 5.6.3 最低要求为 Android 7.0（API 24），不支持 Android 4.4、5.1、6.0。旧文章提到 kitkat 或老系统专版，不能证明当前主版本也兼容。

1. 在电视“设置→关于”查看 Android 版本，不只看厂商系统名称。
2. 低于 Android 7.0 时不要反复安装同一个新版 APK。
3. 若考虑旧版，核对该具体版本的来源及兼容要求；也可使用受支持的外接盒子。

维护者说明不同签名的 APK 不能直接覆盖安装。即使名称和版本号相同，自编译包或二改包也可能使用另一签名。应先备份配置和个人记录，再判断是否更换发行渠道，避免卸载后丢失数据。

1. 先记录版本、下载来源，并在原应用内完成备份。
2. 优先从原有可信发行渠道取得同签名更新包。
3. 需要换包时先确认备份能保留到应用外，再按新项目的恢复说明操作。

维护者发布的影视是可配置播放应用，本身不附带节目来源。只要界面能够正常打开，没有站点或频道通常还需要添加自己的点播或直播配置，也可以先用本地视频验证播放功能。

1. 先从文件管理器打开一段自己的本地视频，确认播放器能工作。
2. 在设置中添加来源清楚、可自行维护的点播配置或直播列表。
3. 配置加载报错时记录错误文本，并核对地址是否返回真正的配置内容。

点播站点和直播列表由不同配置结构管理。点播配置中的 sites 不等于直播频道；直播需要 lives 内容，或者另外导入独立 LiveConfig。一个地址能显示影片分类，并不能证明它同时提供直播。

1. 检查自己的点播 JSON 是否实际包含 lives 数组。
2. 没有 lives 时，在直播配置入口添加自己的直播列表或独立直播配置。
3. 重新进入直播页，确认当前选中的是刚添加的配置。

当前维护者文档列出 M3U、TXT、JSON 直播格式。可以把自己的列表作为直播配置的 url，也可以用 JSON 直接定义分组与频道。列表格式、频道地址和网络可达性要分别检查，不能只改文件后缀。

1. 先确认文件实际内容符合 M3U、TXT 或 JSON 中的一种格式。
2. 在自己的 LiveConfig 中用 lives 数组填写列表名称与 url。
3. 先用一个已确认可访问的自有频道测试，再逐步添加分组。

节目单与视频流是两份数据，直播可播不代表 XMLTV 数据也可用。应分别核对节目单地址、频道标识和时区；频道名称或 tvg-id 对不上，节目表就可能为空，时间设置错误也会让当前节目错位。

1. 检查配置的 epg 地址返回的是有效节目单，而非网页或错误页。
2. 把列表内的频道标识与 XMLTV 对应条目逐项对照。
3. 确认电视系统时间及直播配置 timeZone，刷新后观察同一频道。

节目单只描述播出安排，不包含历史视频。回看还需要来源服务提供可按时间访问的节目，并使用相匹配的 catchup 配置。给普通直播地址补一段回看参数，并不会让服务端自动生成昨天的节目。

1. 先向自有或已订阅服务确认回看权限与保留时长。
2. 按该服务文档填写 catchup 类型、地址模板和时间格式。
3. 用保留期内的一档节目测试；实时直播也失败时先修复直播连接。

Live 配置中的 boot 表示该直播配置载入后自动进入直播。它属于应用内的启动流程，不等于厂商系统允许软件随电视开机运行。设置了 boot 但电视仍停留在桌面，应检查两层不同的行为。

1. 在当前选中的直播配置中核对 boot 值。
2. 手动启动影视，观察配置加载后是否进入直播。
3. 只有应用内跳转正常后，再检查电视系统是否提供该应用的开机启动选项。

站点存在、是否显示和是否参与搜索是不同设置。维护者字段中 searchable 控制搜索，hide 控制站点列表隐藏；站点扩展还必须真正实现搜索能力。改显示名称不能修复一个不提供搜索的扩展。

1. 核对该站点自己的 searchable 和 hide 字段。
2. 先在该站点内用一个准确标题测试，判断是不是跨站搜索的问题。
3. 如果扩展未实现搜索或接口返回错误，按维护者说明更新扩展并保留错误信息。

主配置内的相对路径会按主配置的位置展开。把 JSON 移到别的目录后，原来的 ./spider.jar 可能已指向错误位置；文档还特别区分外部数组及直播列表内部的地址，不能假定它们会再次自动展开。

1. 逐个核对失败文件相对于主 JSON 的真实位置。
2. 先把一个失败路径改成自己服务器上的完整 URL 验证。
3. 按维护者示例整理目录后再恢复相对路径，并检查服务器是否返回实际文件。

Java 站点用 csp_ 类名并依赖 JAR；JS、Python 站点指向对应脚本。全局 spider 可供站点共用，站点 jar 可以覆盖它。它们是扩展入口，配置须与扩展作者的接口约定一致。

1. 先确认扩展类型和所需文件，不要仅凭文件名字改 type。
2. Java 扩展核对类名和 JAR 是否配套；脚本扩展核对 api 路径。
3. 只用一个站点做最小验证，成功后再并入完整配置。

当前项目支持外部 SRT、SSA、ASS 字幕，并提供播放中的字幕选择与局域网推送。选中后没有显示，要区分文件无法读取、字幕轨未启用和时间轴不匹配，不能只反复切换视频地址。

1. 播放自己的视频后打开字幕选择入口，选择可读取的对应字幕文件。
2. 跳到字幕文件中确实有对白的时间，确认字幕轨已启用。
3. 再检查文件编码及字幕对应的影片版本，必要时换一份简单 SRT 做对照。

维护者的 5.6.3 发布说明明确列出双字幕、字形设置及 libass 支持，电视和手机端都有相关更新。旧教程或旧安装包可能没有同样入口；还需有可用字幕轨，开启功能不会自动生成翻译字幕。

1. 先在关于页核对版本和发行渠道。
2. 从该项目发布仓库查看对应版本更新说明后再升级。
3. 播放带字幕的视频，在字幕选择及设置中检查可用轨道、字体和渲染选项。

音轨选择只会列出当前媒体和播放引擎识别到的轨道。可以在播放时切换，但文件只含一种语言时，软件不能补出另一条配音。若有多轨却没有声音，再检查电视输出方式及该音频编码的兼容性。

1. 播放视频并打开音轨选择，查看轨道的语言与格式信息。
2. 选取目标音轨后停顿数秒，确认播放已切换。
3. 没有目标语言时核对源文件；选中仍无声时用立体声轨道作对照。

当前播放器工厂会对 DRM 媒体或 smb 协议优先使用 Exo；mpv 未就绪时也会回退到 Exo。因此出现不同播放引擎不一定是设置失效，应先看媒体协议和引擎可用性，再判断是否需要报错。

1. 记录实际媒体协议及是否使用 DRM。
2. 用自己的普通 HTTP 视频或本地视频对照测试 mpv。
3. 仅非强制场景仍无法使用时，再核对安装包与 mpv 引擎是否匹配。

有声无画可能涉及视频解码或渲染路径。当前电视端提供解码与渲染设置；应先用一段确认正常的视频作对照，每次只改一个选项并重新播放。若只在某一格式发生，记录编码比盲目重装更有用。

1. 用自己的普通 H.264 视频确认应用和显示输出正常。
2. 在播放设置中切换硬解与软解，重新打开同一问题视频。
3. 仍黑屏时再单独测试渲染模式，并记录设备型号、格式与有效组合。

当前手机版同步界面支持设备发现、刷新和扫码。目标电视必须运行影视且其局域网服务可访问；同一个路由器名称并不能保证设备互通，访客网络隔离或旧设备地址都可能让列表空白。

1. 让手机与电视连到可以互访的家庭网络，并打开两端影视。
2. 在同步界面刷新设备；必要时按应用提供的二维码连接。
3. 核对电视显示的实际 IP 与端口，清除失效设备项后重新发现。

同步有双向、仅接收和仅发送之分。强制历史同步会先删除接收端对应配置的历史，强制收藏同步会先清空接收端收藏，再合并传入记录。因此选择方向和强制方式前，应先备份并明确需要保留哪端数据。

1. 先备份两端个人数据，明确来源设备和接收设备。
2. 先选择合适方向做普通同步，用一条记录验证结果；不要随意长按触发强制同步。
3. 只有确认可替换接收端数据并保留备份后，再按对应版本说明使用强制方式，完成后检查收藏与进度。

当前 History 同步会比较同名项目的记录时间，并结合配置与条目标识合并，不是把整个列表逐项无条件覆盖。两端同名影片、不同站点或错误系统时间，都值得一起核对，避免把正常合并误判为网络失败。

1. 确认两端系统时间准确，并记录影片对应的站点和配置。
2. 在来源设备播放到一个新位置，正常退出播放以保存记录。
3. 重新执行普通同步，再核对目标端同名项目的最新记录。

本次核验的 BackupManager 最多保留 7 份备份，文件名按日期生成并使用 .tv 后缀。同一天再次备份会写入同名文件，所以不能把应用自动备份当作长期、多时间点的归档系统。

1. 在应用备份列表中核对日期与最近成功状态。
2. 重要迁移前把备份另存到自己的电脑或存储位置。
3. 需要多个时间点时为导出的副本增加清楚的时间说明，再进行后续操作。

备份会检查当前配置是否为空；恢复检查的则是备份文件内的配置，并不要求新安装应用先有配置。恢复文件需要能解压并解析为本项目的有效备份，把其他软件的文件改成 .tv 后缀不能解决问题。

1. 执行备份失败时，先确认当前应用已有正常保存的配置。
2. 执行恢复失败时，检查备份文件的完整性、生成版本与配置内容；新设备无需为了恢复先添加配置。
3. 保留原始备份，使用本项目恢复入口；若仍失败，记录错误，不覆盖唯一副本。

127.0.0.1 指的是正在使用浏览器的设备自身。手机访问电视时应输入电视端影视显示的局域网 IP 和端口。服务会从 9978 到 9998 尝试可用端口，不能一律假定每台设备都使用 9978。

1. 先在电视启动影视，找到它显示的实际 HTTP 地址。
2. 手机连到可互访的家庭网络，完整输入该地址及端口。
3. 地址变化后重新获取；不要把局域网控制端口映射到公网。

推送入口把 URL 交给应用播放流程，并不保证任意视频网站页面都能转换为视频。媒体直链、需要登录的网页和带临时鉴权的链接有不同前提；先用自己的可播放媒体地址测试，才能判断连接是否正常。

1. 先从手机推送一个自己的有效媒体 URL，并看电视是否进入播放。
2. 只有网页链接失败时，核对该网页是否需要登录或专门的服务支持。
3. 保留电视实际错误提示及链接类型，不把“已发送”当作解码已成功。

维护者文档说明 /action 的 OK 通常只代表事件已派发；未知命令、缺少参数或没有播放服务时，也可能返回 OK。自动化程序应再检查播放状态和电视画面，不能只凭一个字符串判定操作成功。

1. 确认指令名称、必要参数和表单编码，避免把 JSON 请求体当普通表单。
2. 先在电视实际播放一段媒体，再执行暂停等最小指令。
3. 用 /media 状态和电视画面交叉验证，字幕则核对文件能否被电视读取。

当前电视播放设置会按所选引擎显示 mpv 相关选项；处于 Exo 模式时部分选项会隐藏，Vulkan 还要满足设备支持条件。因此选项缺失要先核对版本、引擎和硬件能力，不能照另一台设备的截图强开。

1. 确认使用的是本项目支持 mpv 的对应版本。
2. 在播放设置切换引擎后，再查看 mpv.conf 与 gpu-next 项。
3. Vulkan 仍未出现时核对设备支持；修改高级配置前保存原值，异常时恢复。

DLNA 投放用于把媒体交给另一台设备播放；历史与收藏同步则交换应用个人记录，是两条不同流程。投屏能成功不代表目标设备安装了同款影视，也不意味着它能接收 FongMi 的收藏数据库。

1. 只想在电视播放当前媒体时选择可用的 DLNA 目标。
2. 需要继续观看记录或收藏时，先确认两端是支持该同步机制的影视版本。
3. 从同步入口单独操作并核对方向，完成后再检查记录。