Improves playlist management through IPC

[PCigales]

Currently, playlist management through IPC is a nightmare, because the entries are indexed in two different ways: with playlist_entry_id or by position. Events return the first data, whereas commands allowing to manipulate the playlist request the second one. For example, if you want to delete from the playlist (using playlist-remove) an entry from its id as provided by the start-file event because your code needs this operation, there seems to be no other way that retrieving the playlist content, iterating it until finding the entry with the same id and sending the deletion command with the loop index as argument. If meanwhile the playlist has changed, the result will not be the expected one. So, the suggestion: either use only the playlist_entry_id to identify an entry, as it is unambiguous, in every case, or pair new commands to the existing one to handle the playlist this way. By the way, setting the property access-references to false is supposed to disable the replacement in the playlist of a file loaded with the loadfile command by its content if it happens to be itself a playlist, according to the manual, or am I misunderstanding the description ? Is there another way to prevent this substitution, by disabling some demuxers for example ? Thanks

[mikerodrigues]

Agreed, I want to be able to take a note of where I left off index wise so I can skip to that part of the playlist again after closing and reopening mpv.

I have to take a note of the initial ID, then subtract from the latest ID to get the index today.

[guidocella]

Can't you juse use quit-watch-later?