lxh2875931338/QingTing-Player
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
143 Commits 3 Branches 0 Tags
main
Commit Graph
119 Commits
Author SHA1 Message Date
lxh2875931338 937bcdd63d fix(playback): 缓冲抖动下看门狗失效 + 元数据改到播放稳定后再抓 
实测（公网链路，自然播完 -> 自动下一首）暴露两个新问题：

1. 看门狗在 buffering 抖动时永远不触发
   原实现每次 buffering=true 都重置 30s 计时器，而弱网下它会 true/false
   每 2~5s 抖一次，于是计时器一直被重置，卡死 60s+ 也不会自愈。
   改为记录"最近一次缓冲时间"，用「进度 30s 未推进 + 20s 内发生过缓冲」
   两个条件判定，暂停时不会误触发。

2. 元数据抓取在起播瞬间抢带宽
   新歌 open 后 mpv 还在持续填缓冲，此时插入 2MB 标签下载会把缓冲打回 0。
   实测下一首因此要等 60s+。
   改为等播放真正稳定（进度 >= 5s 且连续 2s 不在 buffering，最多等 30s）
   再抓元数据；等不到就跳过本次（下次播放再试），优先保证出声。

验证：公网 + 移动数据下切歌，next 发起后 2ms 即 open；
未稳定时日志出现"播放未稳定，跳过本次元数据抓取"，不再有 2MB 下载与播放抢带宽。
 2026-10-23 21:35:40 +08:00
lxh2875931338 2b33c17aab fix(playback): 增加进度看门狗，兜住不产生 buffering 事件的半开连接 
公网链路实测（清远->华为云->香港CN2->openresty->OpenList HTTPS）中
出现过 tcp: ffurl_read 错误但未触发 buffering=true 的情况，
仅靠缓冲事件无法覆盖这类"连接半死"的卡顿。

- 每 10s 检查一次播放进度；播放中且 30s 未推进 → 触发自愈（重开 + seek 回原位）
- 切歌中/暂停时重置基准，避免误触发
- 与 buffering 看门狗共用 2 分钟节流

验证：公网路径连续播放 65s，无 false positive，进度正常推进。
 2026-10-23 21:18:02 +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 46a9add5cb build+fix: debug 包独立为 .dev，并修复元数据缓存永远查不到 
包名：
- debug 使用 com.lxh.qingting_player.dev（应用名"清听 Dev"），可与 release 并存
- release 保持 com.lxh.qingting_player
- Android 包名每一段必须以字母开头，因此用 .dev 而非 _dev
- AGP 9 需显式开启 buildFeatures.resValues；移除 manifest 中已废弃的 package 属性

元数据（两个独立原因叠加）：
1. song_key 之前用 String.hashCode / 本地临时文件 mtime，都不稳定；
2. songs.remote_path 存的是完整 URL，而所有查询都用相对路径（song.id），
   getSongByPath 永远 miss，UI 只能回退到文件名。

- 新增 utils/song_key.dart：songKeyFor(url,size)=md5(url|size)，跨进程稳定
- metadata_service: remote_path 改存 fileId（相对路径），并改用稳定 song_key
- audio_service / file_provider: 同步使用稳定键
- 数据库升级 v5：清空 songs / metadata_cache（可再生缓存；歌单与收藏按路径存储，不受影响）
- device-check.ps1: 支持 -Package，默认校验 dev 包，启动组件改为向 PackageManager 解析

验证：两次独立 dart 进程 song_key 输出一致；真机 debug/release 并存安装，单实例自检通过。
 2026-10-22 23:47:32 +08:00
lxh2875931338 6445ee94bf fix(playback): 播放中不再向系统上报 idle，修复播放设备页显示未在播放 
audio_service 把 idle 映射成 PlaybackState.STATE_NONE，之前用 duration>0 判断，
时长尚未解析出来时会一直上报 NONE。改为 playing || duration>0 即视为 ready。

设备验证（MEIZU 21 Pro / Android 16）：
  播放 -> state=PLAYING(3)，暂停 -> state=PAUSED(2)，不再出现 NONE(0)。

同时加固 device-check.ps1：确认进程真正退出后再抓冷启动日志，最多重试两次。
 2026-10-22 22:57:34 +08:00
lxh2875931338 56c26e2fd5 snapshot: 存档 flutter create 模板覆盖后的现场，作为多实例修复前的基线 2026-10-22 21:59:09 +08:00
lxh2875931338 40d4af322b 开始进入修复阶段 2026-09-02 21:42:42 +08:00
lxh2875931338 cdf77b308d 开始给原先适配期的状态擦屁股：现在是修复播放页与播放列表页的显示 2026-09-02 20:44:46 +08:00
lxh2875931338 974dee2995 revert 99917bac87 
revert Core Freeze：核心链路功能已经完成设计，后续进入beta功能开发模式，接下来会在UI部分微调后，进入首个Release版本（1.1.0-Release）
 2026-09-02 10:15:54 +08:00
lxh2875931338 b86a5d2b46 准备进入新的测试阶段，先做一个snapshot（此版本下不可用） 2026-08-31 20:51:09 +08:00
lxh2875931338 08ea8a4508 test通道确认功能完整 
libmpv.so（LGPL版本）
SHA256 = E56776A1BA03892C9A037A534A7114BA54F6EE202083A706CF878924BAA9D7AA
 2026-08-30 23:57:24 +08:00
lxh2875931338 02ca590c65 LGPL库引入后导致app整体处于全面重适配状态，将会处于长期不可用状态 2026-08-30 21:51:19 +08:00
lxh2875931338 99917bac87 Core Freeze：核心链路功能已经完成设计，后续进入beta功能开发模式，接下来会在UI部分微调后，进入首个Release版本（1.1.0-Release） 2026-08-28 22:59:04 +08:00
lxh2875931338 86b1d0df42 正在播放的自滑动刹车动画动作优化完成，同时调整播放页进入动作 2026-08-28 22:45:14 +08:00
lxh2875931338 2e55f94df2 优化正在播放的自滑动刹车动画动作中 2026-08-28 22:27:44 +08:00
lxh2875931338 fa396ce681 播放列表持久化设计、播放列表点击显示当前播放歌曲的列表内位置 2026-08-28 22:16:55 +08:00
lxh2875931338 f91846be9a 优化下一曲检测时长，窗口放宽到800ms 2026-08-28 20:52:03 +08:00
lxh2875931338 bb74cd1351 顺序播放跳曲与首次启动跳曲问题的metadata部分修复完成，测试已通过 2026-08-27 23:27:05 +08:00
lxh2875931338 6cb1167a21 顺序播放跳曲与首次启动跳曲问题已部分修复，播放逻辑正确，metadata部分仍需修复 2026-08-27 23:18:40 +08:00
lxh2875931338 9fec9b98c5 现在正在修复首次启动点击跳曲问题与顺序播放的跳曲问题 2026-08-27 22:54:18 +08:00
lxh2875931338 2a29e30940 修复表写入问题，同时增加对读库动作的log可视化 2026-08-27 22:32:38 +08:00
lxh2875931338 e58be9c17f 引入播放列表库，同时引入全新的播放控制器，以控制读库与播放模式的动作，但是功能仍在完善，需要确认部分边界问题 2026-08-27 22:29:20 +08:00
lxh2875931338 ad6617592e 修复webdav重新登录后，userID位置错位与页面跳转逻辑错误的重大bug 2026-08-27 22:04:59 +08:00
lxh2875931338 bca1288bd1 追加webdav重新登录的button，还在测试边界情况 2026-08-27 21:52:45 +08:00
lxh2875931338 90aa7d10e9 现在列表底部的信息显示正常了 2026-08-27 21:42:04 +08:00
lxh2875931338 8f3f827429 优化部分功能逻辑：元数据信息漂移 
优化部分体验问题，包含动画、界面层级等
 2026-08-26 21:13:09 +08:00
lxh2875931338 94d37fe263 去掉部分高频刷新的log 2026-08-25 23:14:39 +08:00
lxh2875931338 f2b4d1f46d 通知中心封面图显示 
部分界面的信息更新
缓存系统初步引入
即将进入播放列表更新
 2026-08-25 23:09:17 +08:00
lxh2875931338 0e8921742c 引入部分缓存机制 
引入封面图信息

正在进入测试阶段
 2026-08-25 22:13:36 +08:00
lxh2875931338 7bd23bfee6 metadata读取能力已达成，接下来会顺着路径完成部分缓存指针设计 2026-08-25 21:57:04 +08:00
lxh2875931338 b75ea9e4ce 现在版本下，通知中心的进度条拖动seek能力边界问题已全部修复 2026-08-24 23:49:32 +08:00
lxh2875931338 bb466ca534 修复通知中心暂停后播放进度归0的问题 2026-08-24 23:00:45 +08:00
lxh2875931338 f6eb1b108a 现在播放页的实时效果有了 2026-08-23 21:42:37 +08:00
lxh2875931338 d593ce05a1 现在的问题比较大，因为metadata的引入导致原有的部分播放进度信息推送错误 2026-08-23 20:29:31 +08:00
lxh2875931338 9a60441e04 基础实现代码框架先上，后面慢慢改逻辑 2026-08-23 19:24:16 +08:00
lxh2875931338 d49349f7a7 准备尝试metadata设计 2026-08-23 19:08:08 +08:00
lxh2875931338 c3271b07f1 后台连续播放 + MediaItem + 播放状态 + 实时进度 + 系统 seek + seek 后继续实时更新均已正常达成目标 2026-08-23 19:03:49 +08:00
lxh2875931338 be49823b60 播放进度更新已达成，准备优化通知中心的进度条拖动点击 2026-08-23 18:58:43 +08:00
lxh2875931338 1a07664f62 当前固定audio_service为0.18.19，同时已优化媒体信息推送的部分能力，尚在进行媒体信息-播放进度的更新 2026-08-23 18:21:49 +08:00
lxh2875931338 fe3b7de20a 全部包名与名称确定，后台播放能力已完整，准备进入媒体信息推送部分 2026-08-23 17:55:04 +08:00
lxh2875931338 00e9b52872 部分逻辑抓包到位，button的问题很简单，把映射目录改回去就行了 2026-08-23 17:11:30 +08:00
lxh2875931338 f38cc49f09 先commit，明天测下控制中心 2026-08-22 00:04:01 +08:00
lxh2875931338 6083411055 先commit，测下控制中心 2026-08-21 23:44:58 +08:00
lxh2875931338 2cbd0350a5 通知中心全部控制逻辑已达成，即将进入后台与播放歌曲标题推送的优化 2026-08-21 23:17:10 +08:00
lxh2875931338 89c4ba8191 现阶段通知中心播放暂停切换功能已实现，但是上下一曲功能暂时消失，需要后续优化，这个commit是snapshot 2026-08-21 22:58:44 +08:00
lxh2875931338 94a4906671 换上全新的通知中心控制逻辑，晚上按3commit的方式进行测试 2026-08-21 09:04:35 +08:00
lxh2875931338 9af035429c 更新了部分逻辑 2026-08-21 08:54:11 +08:00
lxh2875931338 8ecca4ac01 目前状态栏控制大部分已生效，剩余暂停到播放的链路还有问题 2026-08-21 00:03:04 +08:00
lxh2875931338 bb8e4caf48 后台播放能力已调通，介入部分细节优化 2026-08-20 22:36:10 +08:00
lxh2875931338 f94cda4234 权限配置暂时到此，后台播放问题并入生命周期管理同步开发 2026-08-20 22:07:59 +08:00