 lxh2875931338
|
18308d9d4e
|
feat(metadata): 元数据分阶段探测（128KB → 512KB）+ song_key 改为纯 URL
渐进探测：
- FileProvider.getFile 增加 maxBytes 参数，WebDAV 按需只取头部
- MetadataService 先取 128KB 读标签；title/artist 都为空时再补到 512KB
- 缓存文件按上限区分（metadata_<hash>_128k.part / _512k.part）
song_key：
- 从 md5(url|size) 改为 md5(url)。分阶段探测的大小不同，
带 size 会让同一首歌产生两个键；URL 在各阶段稳定。
- 代价：同 URL 换内容不自动失效，由清除单曲缓存/forceRefresh 兜底
- 数据库升到 v6，清空 songs / metadata_cache（可再生）
验证（release，真机）：
📦 取头部 128KB（上限 128KB，不再整文件下载）
🧭 状态机: first_seen → pending（validations=1）
📊 pending conf=0.92 evidence={...}
✅ saved: 两生关 - 谢安琪
测试：新增 song_key 3 个用例，累计 19 个全绿。
|
2026-10-24 20:28:50 +08:00 |
|
|
lxh2875931338
|
a5849969d3
|
perf(metadata): 元数据探测从 2MB 降到 512KB
1Panel 访问日志显示：2MB 的探测请求在当前链路上要 10~18 秒，
期间 libmpv 的 206 吞吐被压到 ~1Mbps，直接拖慢起播。
- _maxBytes 2MB -> 512KB：常见标签与封面都在此范围内
- 读不到标签时仍由 80% 重试兜底
- 日志文案同步更新
另：访问日志 CSV 属于本地参考，加入 .gitignore
|
2026-10-23 23:16:07 +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
|
7bd23bfee6
|
metadata读取能力已达成，接下来会顺着路径完成部分缓存指针设计
|
2026-08-25 21:57:04 +08:00 |
|
|
lxh2875931338
|
d593ce05a1
|
现在的问题比较大，因为metadata的引入导致原有的部分播放进度信息推送错误
|
2026-08-23 20:29:31 +08:00 |
|