mpv
mpv copied to clipboard
mpv-player
Limit watch-history depth
Expected behavior of the wanted feature
There should be an option to limit the number of files that can be stored in watch-history, when the limit is hit for number of files, all entries for the file that it has been longest since viewing should be deleted to make way for the next file.
Alternative behavior of the wanted feature
No response
Log File
No response
Sample Files
No response
That would slow down opening new files since the history file would have to be read everytime instead of appending.
That would slow down opening new files since the history file would have to be read everytime instead of appending.
That's true... Could it not be done asynchronously? This doesn't have to happen before a file is loaded.
I suppose alternatively, instead of doing it when opening a file, the watch-history menu could just limit the number of visible entries, and then the watch historry file itself could be trimmed of duplicate entries and entries beyond that maximum number on shutdown instead of startup? Seems a bit hacky maybe, but it would work...
trim older history entries to speed opening up the history file. Works on mac / linux.
c-x run "bin/bash" "-c" "cd ~/.config/mpv; cat memo-history.log | tail -n 333 > memo.log ; rm memo-history.log; mv memo.log memo-history.log; cat watch_history.jsonl | tail -n 666 > watchistory.jsonl ; rm watch_history.jsonl; mv watchistory.jsonl watch_history.jsonl";show-text "Trimmed ~/.config/mpv/memo-history.log and watch_history.jsonl to 333 & 666 lines to speed up opening History memo" #! [History Chapters Bookmarks] > Trim History log if slow to open
That would slow down opening new files since the history file would have to be read everytime instead of appending.
That's true... Could it not be done asynchronously? This doesn't have to happen before a file is loaded.
I suppose alternatively, instead of doing it when opening a file, the watch-history menu could just limit the number of visible entries, and then the watch historry file itself could be trimmed of duplicate entries and entries beyond that maximum number on shutdown instead of startup? Seems a bit hacky maybe, but it would work...
Even though asynchronous execution does not slow down file opening speed, it may cause a lot of disk I/O because deleting the first line of a file requires overwriting the entire file.
After reaching the maximum line limit, the asynchronous task will delete the first line every time a file is loaded, causing several hundred Kib or even several MiB of disk I/O, I think this is unacceptable.
Even though asynchronous execution does not slow down file opening speed, it may cause a lot of disk I/O because deleting the first line of a file requires overwriting the entire file.
After reaching the maximum line limit, the asynchronous task will delete the first line every time a file is loaded, causing several hundred Kib or even several MiB of disk I/O, I think this is unacceptable.
I suppose working around this would require perhaps a restructuring of how watch history gets saved, for instance if it were formattted like watch-later (files in a directory) we could simply check the number of files in the directory, and delete the one that it's been longest since it was modified to make room for a new one once the cap is reached.
This would also eliminate the issue of duplicate entries for the same file flooding the watch history, as each file could just have it's own corresponding history file which could store one or multiple dates. if someone reopens the same file a lot (although that should already be easily preventable tbh)
I like having duplicate entries as I sometimes open a directory and navigate back and forth and then want to see what was the first opened file.
I like having duplicate entries as I sometimes open a directory and navigate back and forth and then want to see what was the first opened file.
Yeah, but some might not (I personally don't like it, would disable it if it was easy), and the solution of using the multiple file format like in watch-later I suggested allows you to retain that functionality in a very reasonable way where diabling it would be trivial for those that don't want it as well.