history-bookmark脚本在mpv的autocreate_playlist启用时失效

[zhongfly]

早在autocreate_playlist刚合并时就尝试使用过，发现history-bookmark不起作用了。
为了探究原因，我在mp.register_event('file-loaded', function()以及mp.add_hook("on_unload"后面都增加了msg.info来打印不同的内容

不使用autocreate-playlist时：
只会触发file-loaded事件

启用autocreate-playlist=same时：
先触发了on_unload，记录了书签，然后再file-loaded，打开书签记录文件。这样一来，书签肯定始终是当前打开的文件，脚本的书签功能失效了

这样的区别可能是在于autocreate-playlist实现方式？
或者是只在我这里出现？

[dyphire]

我试了下可以复现，只要启用了 autocreate-playlist 就会先触发 on_unload，太抽象了
虽然可以尝试修改脚本实现，但这个隐藏特性其实破坏了所有依赖 on_unload 的第三方脚本。我选择回归使用自动加载脚本

[dyphire]

试了下，end-file 事件一样会被触发，所以其实没有脚本适配这一特性的方法。这完全算是 bug 了

[dyphire]

看你之前去掉 autoload 脚本，还以为我可能是个例，或者 autocreate-playlist 实现变了呢……

测试的不充分，只是测了下自然排序方面的表现，觉得能用。没想到还有这种惊喜

[dyphire]

考虑去提个 issue 反馈下吧，看会不会改

[verygoodlee]

这个问题我是一直清楚的，它把单文件重定向为播放列表
start-file -> end-file 触发重定向(https://mpv.io/manual/master/#command-interface-redirect) -> start-file
start-file触发两次，如果文件记录了watch later file，可在控制台观测到打印两次这个信息

跟ytdl_hook.lua的流程是类似的，如果yt-dlp输出的是一个播放列表，也是用end-file重定向的方式

考虑去提个 issue 反馈下吧，看会不会改

搜了一下好像有人提过了 mpv-player/mpv#14675 看来不会改，
所有自动创建的播放列表都是这个流程，打开文件夹、打开 m3u8，都会触发一次end-file重定向

[dyphire]

搜了一下好像有人提过了 mpv-player/mpv#14675 看来不会改，
所有自动创建的播放列表都是这个流程，打开文件夹、打开 m3u8，都会触发一次end-file重定向

令人无语的特性，所有使用相关事件和钩子的脚本和客户端都会受到影响。绝大多数第三方开发者应该都不清楚有这么个特性，mpv 总是喜欢整一些花活和破坏性更新

[zhongfly]

我先想了一个临时的解决方法，思路是file-loaded过后才允许执行书签写入
具体实施：
设置一个变量做标志/指示灯，一开始是false，file-loaded后设为true，在on_unload时只有变量为true时才记录书签。另外，总是将变量在on_unload时复位成false。

不过我觉得还是mpv方面把自动创建播放列表的实现改成像脚本那样的插入更好

[dyphire]

我本地已经这样写了，只是还没推送

[dyphire]

所有自动创建的播放列表都是这个流程，打开文件夹、打开 m3u8，都会触发一次 end-file 重定向

鉴于 mpv 自动创建播放列表时始终执行重定向，脚本还是有必要针对这一行为进行适配。在提交 b634d73 中修复

[dyphire]

在提交 8bdd459 中回归使用自动加载脚本，一是为了潜在的其他脚本兼容性，二是因为脚本在 Windows 上实现的原生排序体验更好