lifegpc

下一首播放这个vector里的歌就定死顺序播放就好了

> 我没有理解，是如何做到跨播放列表维持下一曲播放的 MusicPlayer2是没办法播放CPlayer::m_playlist之外的歌曲这一点是难以更改的，比换媒体库的键要难得多 我设想的存储下一曲播放的vector会在设置下一曲播放时size+1 播放下一曲时size-1直到size==0（即播放会消耗其中存储），等于size等于0后恢复正常循环模式 那不妨换个想法，存到同一个vector，然后设置个变量来区分当前列表和下一首播放列表（

随机播放的话，只要确保落在当前列表的范围内就可以了

> 感觉没必要跨播放列表维持下一曲播放的 有必要的，比如说从媒体库加下一曲播放（

> > > 这个我比较喜欢PowerAMP的处理方式。 PowerAMP 是直接存一个单独的列表，专门就是存放下一首播放的列表。 如果列表放完了，下次加的时候清零再push_back，它存的应该是位置，所以换播放列表是不会影响下一首播放的。 > > > > > > 以目前的设计，MusicPlayer2是没办法播放CPlayer::m_playlist之外的歌曲的 我没有用过，不过按照这个描述这样做类似网易云音乐UWP的实现 我认为这样做最大的问题是当前播放列表无法确定（或者说是动态生成的），这样的结构无法实现随机播放，只能是无序播放 现在这样的基于明确的播放列表的实现也很好用 只要加一个vector垫在CPlayer::PlayTrack前来实现下一曲播放就好 > > 我的意思就很简单，保存一个单独的vector和vector的播放进度，然后播放下一首的时候检查这个vector的大小和播放进度，小就放vector里的歌，反之就之前的行为。这样不会对现有的播放列表造成影响。 要不就这种 就代码可能得大改（

我的想法是能不能之后只存储key，数据全部存数据库里（考虑引入sqlite3

当前歌曲的信息单独存一份，当前播放列表只存储key，同时还能节省内存占用。 就是搜索感觉麻烦点（需要去调用数据库）

> > 我的想法是能不能之后只存储key，数据全部存数据库里（考虑引入sqlite3 > > `当前歌曲的信息单独存一份，当前播放列表只存储key`，这个以后有打算，不过可能只存时长信息用于维持内核播放就足够 重新初始化播放列表时m_playlist[m_index]会失效，目前是用停止播放的方法度过这段时间 切换播放列表保持播放/播放列表添加歌曲时 不重新打开歌曲都需要这个 ~key也不算小吧~ 媒体库内容的更改不会自动触发各种窗口的更新，还是复制SongInfo安全， 用媒体库独一份的SongInfo可以预见会发生各种不同步的bug key直接使用一个数字id即可，具体的路径全部可以从sqlite数据库查询

同步问题在C++是挺头疼的，sqlite是提供了数据库级别的同步，也许可以在修改元数据后发一个事件，然后通知其他窗口，然后再从数据库取一份就好了，最主要的还是现在每秒都会更改一下SongInfo来实现统计信息，这里肯定是要复制一份的，不然更新数据库太频繁了 ~（Rust倒是无脑Mutex/RwLock 叠Arc就好了，还肯定不会死锁）~

> 有个问题我不太清楚，想讨论一下： 随机播放模式下，如果用户指定了下一首播放，在播放下下一首时点击“上一首”，需要回到用户指定的那一首吗？如果是那就不能简单地 “在CPlayer::PlayTrack的switch前判断有下一曲播放就拿出一曲播放并跳过switch（单曲播放时不进行）”了 我觉得保留当前的逻辑好了，就是播放之前播放的歌曲。