MusicPlayer2 icon indicating copy to clipboard operation
MusicPlayer2 copied to clipboard

更换song data map的键

Open lrisora opened this issue 2 years ago • 7 comments

注意

  • 由于数据版本提升使用此分支代码出现问题后将无法直接回退,请先备份song_data.dat文件再测试

媒体库CArchive中length改为start_time+end_time,添加存储is_cue cue可存储关联歌词路径,相关更改 cue可存储ID,相关更改 cue、osu分级仅保存到媒体库,即不从文件读取也不写入文件 新增对osu文件禁用内嵌歌词功能 修正int CPlayer::MoveItems(std::vector indexes, int dest)重新查找当前播放没有兼容cue 修正之前我对IsWindowsPath的误用 GetCueTracks重构,改为仅当媒体库内不存在时获取并且只负责时长与标签(可通过refresh_info强制刷新) 媒体库及其标签页改动以支持cue 播放列表初始化线程及媒体库更新线程的更新 设置CPlayer播放内容的接口更新 媒体库接口更新(这里有其他问题,↓) 各种窗口类在媒体库可存储cue后的支持 以及其他琐碎更改修复

根据实测,媒体库使用的m_song_data在多线程访问(写入,读取不清楚)下出现了问题 表现为出现了多个歌曲信息是混合的 我把媒体库接口改了,把读写分开了,并且不再能够获取引用 不过还没有加锁,不清楚用读写锁还是互斥锁(主要问题是我不会)

观察到有许多旧代码依赖播放实例,没有考虑到歌曲放完后自动下一曲的问题 之前在pr重构歌词代码里修了封面下载与歌词下载窗口的此问题,不过其他地方可能仍然存在(没有确认)

已知问题(以前的和新增的) ~之前的添加封面文件夹设置后属性窗口仍然不会搜索封面文件夹路径(接下来改这个) 多处代码使用osu歌曲的实际文件名导致重名问题,这里应当和cue一致,全部使用“艺术家 - 标题”~ 还有一些没写下来忘了,以后再说

lrisora avatar Aug 14 '22 11:08 lrisora

需要测试,改动后的代码可能存在错误 建议优先测试媒体库窗口的各项功能(以及其中的右键菜单)是否如常(这里应该是出现问题较少的部分,已经修了一些) 另外需要测试的还有 从各种位置打开的属性窗口、查找窗口、下载窗口,以及右键菜单功能 我自己改着改着就忘了原本的功能是什么样了,难以对比

lrisora avatar Aug 14 '22 11:08 lrisora

目前发现的问题:

  1. 添加cue到播放列表后,退出播放器后再启动,双击任何一首曲目播放的都是第一首,右键选择“重新载入播放列表”后正常,重新启动播放器问题仍旧
  2. 在媒体库“文件类型”对话框左侧列表中选择“cue”,再在右侧列表中选择一个cue文件双击播放后会将所有的cue文件展开后添加到“临时的播放列表”,而且总是从第一首开始播放(原来的效果是只将当前选中的cue文件展开并添加到“临时的播放列表”)

zhongyang219 avatar Aug 17 '22 07:08 zhongyang219

现在的媒体库应该是无法加入cue原始文件的,如果是新加入的cue文件属于bug,要修 另外,由于媒体库使用音频路径做键,没能找到音频文件的cue音轨会被彻底忽略(原来是以时长0加入)

以后需要一个清理媒体库cue文件(及其关联音频文件)的功能 还有清理时长小于一定值的文件(之前不小心加了Songs文件夹至今还没删掉)

lrisora avatar Aug 17 '22 09:08 lrisora

以前由于展开后的cue音轨无法保存到媒体库中,因此我将cue音轨的信息保存到了playlist文件中,现在应该不需要再将它们保存到playlist文件中了。

zhongyang219 avatar Aug 17 '22 09:08 zhongyang219

以前由于展开后的cue音轨无法保存到媒体库中,因此我将cue音轨的信息保存到了playlist文件中,现在应该不需要再将它们保存到playlist文件中了。

不行,只靠音频路径与音轨号无法逆向找到cue文件,一旦清理媒体库playlist中的内容就是重新打开必要的了 更新: 因为无法逆向找到原始cue文件所以现在的播放列表模式的的重新载入播放列表对cue标签/时长是无效的(不算大问题)

lrisora avatar Aug 17 '22 10:08 lrisora

以前由于展开后的cue音轨无法保存到媒体库中,因此我将cue音轨的信息保存到了playlist文件中,现在应该不需要再将它们保存到playlist文件中了。

不行,只靠音频路径与音轨号无法逆向找到cue文件,一旦清理媒体库playlist中的内容就是重新打开必要的了 更新: 因为无法逆向找到原始cue文件所以现在的播放列表模式的的重新载入播放列表对cue标签/时长是无效的(不算大问题)

将cue文件展开成音轨后原始的cue文件就没什么作用了吧,有什么需要找到原始cue文件的情况吗?

zhongyang219 avatar Aug 17 '22 10:08 zhongyang219

没有,仅有“重新载入播放列表”这个操作需要 比如上面问题中的右键选择“重新载入播放列表”后正常如果这是播放列表模式那么重新载入也是无效的 而在文件夹模式GetCueTracks就能够拿到原始cue从而正常重新载入 playlist中cue的项目仅比特率一项是可以移除的,还是不要改了

初始化播放列表线程的更改主要集中在尽量不去读取音频文件,如果要读就一次到位,

lrisora avatar Aug 17 '22 11:08 lrisora

建议先合并 #412 到master,之后我拉取master做冲突合并 这个pr牵扯到太多文件了继续改会引起难以解决的合并冲突

目前媒体库读写仍然不是线程安全的,如果假设媒体库更新瞬间完成的话没问题 通过一个低速的存储或大量新歌曲可以构造出出错的情况 现在这个错误的影响已经从意外混合歌曲信息降低到可能意外放弃某些修改操作 彻底修好这一点我水平有限无能为力

多歌词文件夹我想不到如何做UI,另外可能涉及合并冲突,以后再说

lrisora avatar Nov 28 '22 12:11 lrisora

@lrisora 刚刚我修正了一个问题,就是从播放列表中读取cue文件后,SongInfo中的start_pos全部变成0了,导致播放列表中所有cue音轨全部只能从头播放。问题出在player.cpp的236行:

// 将媒体库内信息更新到播放列表
CSongDataManager::GetInstance().LoadSongInfo(song);

本来song中的start_pos是正常的,从媒体库中更新一下就变成0了。 我目前并不清楚为什么媒体库中cue的start_pos会变成0。 这个问题暂时解决了,由于从文件中加载的cue的信息是完整的,因此不再从媒体库中更新,通过song.info_acquired判断一下。

// 将媒体库内信息更新到播放列表
if (!song.info_acquired)
    CSongDataManager::GetInstance().LoadSongInfo(song);

zhongyang219 avatar Nov 30 '22 11:11 zhongyang219