 lxh2875931338
|
111369c20c
|
feat(playback): 起播看门狗 + 起播耗时打点
现象（Plastic Love）：state=PLAYING、position 恒为 0，75 秒内没有任何
buffering/error 日志，mpv 既不报错也不推进。通用看门狗要求"近期有缓冲"，
因此完全没反应。
- 新增起播看门狗：position 持续为 0 超过 15s 且 playing=true → 强制重连
（不再要求 buffering 事件；暂停时 playing=false，不会误触发）
- 中段卡死判定也放宽为 playing || recentlyBuffering
- 打点：
* PlaybackService: "open 完成 xxxms，play 完成 xxxms"
* AudioService: "起播耗时 xxxms（open 完成 -> 出声）"
下次再出现"下一首很久"，日志能直接区分是 open 慢还是数据到得慢。
|
2026-10-23 21:55:13 +08:00 |
|
|
lxh2875931338
|
9e58d52678
|
fix(playback): 修复切歌永久假死，并让元数据抓取不再抢播放带宽
问题（后台播一段时间后无法缓冲，点下一首也没反应，只能重启）：
1. _isChangingTrack 是没有超时的锁：_playCurrent() 置 true 后，
只有走完 finally 才会清。mpv 的 open() 在弱网下可能挂很久，
锁就一直不释放，之后 next()/previous() 全被静默拒绝。
2. 元数据用 dio.download 整文件下载，和 mpv 流式播放抢带宽，
20Mbps FRP 下播放流只剩一两百 K/s，缓冲长期为 0。
3. 没有订阅 mpv 的 error/buffering，失败无感知、无法自愈。
改动：
- playback_service: open 20s / 控制命令 5s 超时；失败时 stop 回空闲并上抛异常
- audio_service:
* 去掉「正在切歌就拒绝」的逻辑，改为 latest-wins（epoch 校验，
旧请求自行放弃，只有最新请求解锁）
* 播放失败不再吞掉：记录 lastPlaybackError 并 notifyListeners
* 订阅 stream.error / stream.buffering
* 缓冲超过 30s 自动重连当前歌曲并 seek 回原位置（2 分钟内最多一次）
- file_provider: 元数据改为 Range 只取头部 2MB，流式写入并在切歌时取消上一请求
- home_page: 去掉重复的 PlaybackService().play()（同一首歌会被 open 两次），
登录校验提前
验证：dart analyze 无 error；gradlew assembleDebug BUILD SUCCESSFUL。
真机验证待设备重新连接后进行。
|
2026-10-23 21:04:45 +08:00 |
|
|
lxh2875931338
|
56c26e2fd5
|
snapshot: 存档 flutter create 模板覆盖后的现场，作为多实例修复前的基线
|
2026-10-22 21:59:09 +08:00 |
|
|
lxh2875931338
|
89c4ba8191
|
现阶段通知中心播放暂停切换功能已实现，但是上下一曲功能暂时消失，需要后续优化，这个commit是snapshot
|
2026-08-21 22:58:44 +08:00 |
|
|
lxh2875931338
|
c05398d76f
|
部分界面调整，把底部的播放控件完整前置
|
2026-08-18 22:57:29 +08:00 |
|
|
lxh2875931338
|
725116760a
|
还在尝试跑通播放状态
|
2026-08-17 23:00:30 +08:00 |
|
|
lxh2875931338
|
699ab7ce86
|
暂时把bug先处理掉了，准备尝试实现最小播放目标
|
2026-08-15 23:20:54 +08:00 |
|
|
lxh2875931338
|
902788c736
|
目前调通了120全局，准备开始介入播放层，在修bug
|
2026-08-15 23:06:55 +08:00 |
|