lrisora

哪些曲目被放在无序列表的后面导致其一次播放下播放不到本身是随机的 从数学理论上说，这不影响多次运行中各个曲目播放次数的均衡性 如果你指的是”排序->按播放时长排序“的不均匀 可能是歌曲时长的不同导致的，这里是目前按”歌曲被播放的秒数“排序的 或许将其除以时长换算成次数更好？ 对无序播放持久化无序列表有难度，因为列表是会变动的（这包括直接修改playlist文件） 协调曲目的增减与其随机性很有难度，存储在哪里也是问题 随机播放向”播放次数“较低的曲目倾斜有一点用，不过我推测应该效果不大，很可能不是你想的那样 靠”随机“播放到所有歌曲数学上相当困难 即使修改随机权重 如果列表很长目前的无序播放也有这个倾向，难以触及所有曲目（我想这可能是你关注的问题？） 可能简单的增加一个特殊的列表排序方式 `随机打乱排序` 再搭配循环模式 `列表循环` 可以实现？

> 希望一段时间内每首曲目播放次数的方差降低 这一点其实是做不到的，除非总是在播放一个拥有所有曲目的列表， 否则播放歌曲本身就是在拉大“所有歌曲”播放数的方差 > 早添加进音乐库的曲目更有可能有更长的播放次数 这一点同理也是不成立的，添加歌曲到媒体库并不需要播放，歌曲完全可以在媒体库被晾上几个月再播放 添加时间与播放数并没有关系（或者说这种相关性仅在某种特定的播放习惯下成立） 想要之后的新增播放数在所有歌曲上摊平关键之处在于不要手动介入播放器的“随机”， 包括按下一曲/手动指定播放/拖进度条等等 如果你表达了对歌曲的喜好那么播放不平均也是自然而然的 这个条件下 在 累计播放时长远大于列表总时长 后 随机/无序播放 的均匀性才能体现出来 或者 我上面说的新方案（其实相当于固化无序列表） （暂时可以弄个脚本编辑playlist文件将其行打乱，是等价的） 可以在 累计播放时长比列表总时长稍大 之后体现出均匀的感觉

我感觉差距并不是太大，因为此处累计的是实际播放的秒数（而不是被播放到的次数） 这很受播放影响，不太想听的就更可能播放时长更小，这很正常，比如会关闭播放器 18倍也远不能让“随机”抹平播放数的差距，数学上本就如此 要确实的平均只能是某种列表循环，而且不能指定开始曲目 我的习惯是 以某个现在最想听的开始 + “随机播放” + 按下一曲跳过所有现在不想听的 

虽然不完全一样，可以看看以下用法能否替代 大部分时候播放一个非常全的列表（现在可以用 媒体库的所有曲目） 这能够保证“下一曲播放”总是可用的 之后可以在媒体库窗口以任意方式检索&选择歌曲再“下一曲播放” 搭配下面这点也算是很自由了 > 目前在切换歌单时会切换播放列表，并暂停当前正在播放的歌曲 关于这一点不全是这样，勾选“播放设置->切换列表时继续播放” 能够在切入的播放列表存在当前播放曲目时 稍微卡一下的 维持播放状态 而不是上次播放的曲目 （我正打算修改成不用 稍微卡一下 就能切换列表）（工程量很大，需要时间） 下一曲播放几乎所有位置都有提供，没有明说的是其可用的条件是选择曲目必须全部已存在于当前播放列表 原因是MusicPlayer2从最初开始就没有使用播放队列的概念（类似你描述的行为） 也就是没有默认使用一个自动调整内容的列表作为播放实体（我很喜欢这一点，播放内容总是已知可控的）

快捷键方面加上很简单，我感觉只是因为方便的快捷键是有限的 在UI没有提供全面的快捷键自定义机制前，占满所有空位可能影响之后可能会出现的更重要的功能的快捷键分配 全局快捷键默认注册太多就更坑了，极有可能与其他软件冲突 列表重复加入应该是不会发生的，具体是哪个位置

或许是之前列表总是对齐到某一行，现在能够按像素自由滚动 导致看起来有一点闪烁 这样应该能还原之前的行为 [Patch.patch](https://github.com/user-attachments/files/16604519/Patch.patch)

确实不像这个问题， 可以试试关掉背景降低绘制间隔并缩小窗口，让帧率提高到40+ 看看还会感觉卡吗，延迟大的话我也认为是帧率问题，可以排除一下

是指的“下一曲播放”吗？ 可以选中列表内一些歌曲之后右键下一曲播放

可以使用系统标题栏，自绘的标题栏没有去掉窗口的SizeBox，这样是正常的 视图菜单下的前两项选中状态只是对应当前状态 请将默认播放列表切换为浮动播放列表，这样的话重新启动时浮动播放列表的打开状态才会被还原 否则浮动播放列表被视为不经常使用的“临时”打开，不会还原 

播放列表存储时并没有存储“添加时间”所以这个功能不太可能 播放列表可以“按文件修改时间排序”，如果你的文件属性“修改时间”可靠可以用这个 另外新加入的曲目应该总是在末尾的，不会找不到 在新Action版本，新增了选项控制新加入曲目会插入列表开头还是结尾