Eisa01 / mpv-scripts

This repository contain scripts I have made for mpv media player...
BSD 2-Clause "Simplified" License
557 stars 37 forks source link

SimpleHistory: Option to Limit Loading Entries #85

Open AdventurerRussia opened 1 year ago

AdventurerRussia commented 1 year ago

I noticed that when the list of files increased to several thousand, the history began to open with a delay and slow down when switching between different sorts, is it possible to configure auto-deletion from the file log? since it gets bigger over time and this affects the script

Eisa01 commented 1 year ago

You're correct, applying a filter on a very large list takes time.

For now, fix this manually by changing the name of mpvHistory.log to avoid loading it, and it will automatically create a new empty one.

Example.: from mpvHistory.log to mpvHistory_2023-04-14.bak which can be found in your mpv default directory (For Linux usually ~/.config/mpv/) / (For Windows %APPDATA%/mpv/)

To fix this, there need to be an option to limit loading entries: e.g: max_load_entries=500

Eisa01 commented 1 year ago

Ah there is a challenge in creating max_load_entries. Because of the way I am reading the log file in the first place, I will need to do TONS of backend changes to implement it. Basically I am using found_sequence which is a backend attribute I created to do CRUD operations since I am not storing any ID. If I set a limiter, then the found_sequence will not be the same as the log file itself. So, all CRUD operations will fail. Unless I store an ID in the log file and replace all found_sequence references in the code with ID for any CRUD, then only a limiter can be created.

It is possible but a lot of work and will make the current log file obselete for all users. I'll think about it, but no promises for now.

Edit: Instead of ID, path+ current time could be count as something unique which is already available with the log file. This could be a replacement for sequence.

AdventurerRussia commented 1 year ago

the problem is not too critical, but sooner or later people will encounter it, so don't pay much attention to it

Eisa01 commented 1 year ago

I have tested changing the backend behavior, however there are some underlying problems with the backend code that will still impact the performance when the log file gets very big.

Some performance improvements could be done that will ensure that filtering the log file is only done through RAM and that the Log file is only loaded once when mpv is launched. However, the problem with that, if there is another mpv session messing with the history then there will be sync issues (one session will overwrite the history of the other).

I could still look at decreasing the need for looping through History and ensure it is only done when it is absolutely necessary, which could improve performance a lot. But as you stated the problem is not too critical, and the log file can be manually renamed.

This will be kept open in case a full code revision is planned.