Load metadata for non-playing songs #38

New Issue

danio · 2024-10-30T23:13:28+01:00

danio commented

2024-10-30 23:13:28 +01:00

I would like to see what songs will play, or be able to jump to a specific song, and for reordering

![image](/attachments/ebe65f48-9c9c-4481-afcd-8023eff5b38f) I would like to see what songs will play, or be able to jump to a specific song, and for reordering

image.png

40 KiB

pederbs commented

2024-10-31 14:33:32 +01:00

grzegors-webui had a background thread fetching the meta, maintaining a hashmap from urls to meta blobs. One shortcoming was that the fetch order was static, meaning that if you import a playlist then hit shuffle, the meta would still load in the old order

pederbs commented

2024-10-31 14:35:23 +01:00

i also think it was that thread that marked items red when it was unable to pull the meta

oysteikt commented

2024-11-01 14:06:08 +01:00

Just to make sure I understood correctly, this issue occurs when you add one song after another, right? I've mostly tested with playlists, and they resolve all songs at once

oysteikt commented

2024-11-04 20:50:28 +01:00

mpv internal state is currently the single source of truth. Running the fetching script past the currently playing track has been requested before, in the context of preloading videos https://github.com/mpv-player/mpv/issues/6437#issuecomment-453795638

oysteikt self-assigned this 2024-11-04 20:50:38 +01:00

oysteikt commented

2024-12-11 16:15:07 +01:00

After a bit of more research, I've found that ytdl_hook.lua gets automatically loaded by mpv. At the end of the script, it calls mp.add_hook() a bunch of times, and it hooks into the on-load target which only runs when a single playlist entry is about to play. All of the functions are marked as local, and there is no API for introspecting the list of hooks as far as I'm aware. This means that there is no real way to access the functions used in the hooks from outside the script without making some patches.

Here's a list of possible solutions:

Preferrable solutions, actually fixes the problem for everyone

Upstream another hook target on-add, and have the ytdl hook target that instead (see current hook targets). This would somewhat fix the problem for everyone automatically, but some people might complain that it reduces laziness unnecessarily.
Upstream a resolve command which lets you try to further resolve a playlist entry. This might be the most versatile option, but requires a user to actively resolve the entries either programmatically or through a keybinding. It also calls for a few design decisions, should probably be made by some of the core maintainers:
- do we need to rewrite the ytdl hook into c, to avoid the slippery slope of having a bunch of mpv backend be lua?
- should the resolve command be modular, so the ytdl resolution is not the only implementation available?
- should resolution of multiple songs happen in a parallell manner? What about ratelimiting?

Mediocre solutions, still gets upstream maintenance and no reinventing the wheel

Patch the lua script to use non-local functions before compilation, so maybe we can include it as a lua module and call the functions arbitrarily from our own script.
Make a dynamically generated copy of the lua script without the add_hook calls so we can call the functions arbitrarily from our own script.

Nonpreferred solution, maintainership relies solely on us and we're reinventing the wheel

Create our own thread to sideload the metadata, and overwrite it via setproperty. This was the solution for the old grzegorz backend.

After a bit of more research, I've found that [`ytdl_hook.lua`](https://github.com/mpv-player/mpv/blob/master/player/lua/ytdl_hook.lua) gets automatically loaded by mpv. At the end of the script, [it calls `mp.add_hook()` a bunch of times](https://github.com/mpv-player/mpv/blob/e2014fb3094acf212bf47421278d6dfa84a24917/player/lua/ytdl_hook.lua#L1226-L1248), and it hooks into the `on-load` target which only runs when a single playlist entry is about to play. All of the functions are marked as local, and there is no API for introspecting the list of hooks as far as I'm aware. This means that there is no real way to access the functions used in the hooks from outside the script without making some patches. Here's a list of possible solutions: #### Preferrable solutions, actually fixes the problem for everyone - Upstream another hook target `on-add`, and have the ytdl hook target that instead (see [current hook targets](https://mpv.io/manual/stable/#hooks)). This would somewhat fix the problem for everyone automatically, but some people might complain that it reduces laziness unnecessarily. - Upstream a `resolve` command which lets you try to further resolve a playlist entry. This might be the most versatile option, but requires a user to actively resolve the entries either programmatically or through a keybinding. It also calls for a few design decisions, should probably be made by some of the core maintainers: - do we need to rewrite the ytdl hook into c, to avoid the slippery slope of having a bunch of mpv backend be lua? - should the resolve command be modular, so the ytdl resolution is not the only implementation available? - should resolution of multiple songs happen in a parallell manner? What about ratelimiting? #### Mediocre solutions, still gets upstream maintenance and no reinventing the wheel - Patch the lua script to use non-local functions before compilation, so maybe we can include it as a lua module and call the functions arbitrarily from our own script. - Make a dynamically generated copy of the lua script without the `add_hook` calls so we can call the functions arbitrarily from our own script. #### Nonpreferred solution, maintainership relies solely on us and we're reinventing the wheel - Create our own thread to sideload the metadata, and overwrite it via setproperty. This was the solution for the old grzegorz backend.

oysteikt added the

bug

label 2024-12-13 18:54:23 +01:00

oysteikt added this to the Grzegorz Nextgen project 2024-12-18 23:28:34 +01:00

Sign in to join this conversation.