Qobuz browser and player

[sevmonster]

From https://github.com/jcorporation/myMPD/discussions/1276#discussioncomment-9464749:

Now, on a scale of 1/10, how cursed would it be to make navigable menus out of streams, or auto-populating playlists? I can think of things like browsing through streaming services being useful, like how it looks in BubbleUPNP:

My idea is to have multiple playlists get created by a script, each with a script stream that then refreshes the playlist when you play it, for a simple way of lazy-loading each playlist when you want it. And, for pagination, there could be a "next" stream at the end that fetches more results.

Earmarking this thread so I don't forget about it. First on the menu should either be investigating the feasibility of menuing via MPD playlists and myMPD script endpoints, or maybe using Lua to create UIs? @jcorporation

[jcorporation]

Creating playlists is already feasible with current api.

We should first define what functions we need for lua based menus. It involves a custom markup definition (json) and a parser in JavaScript to create the ui elements.

[sevmonster]

s/feasibility/practicality/

Expressly, I want to be able to either:

1. Select the source of tracks from the script invocation UI—so defining UI elements before the script runs, perhaps in the table comment in the head of the script. However this means the menu can only be one level deep.
2. Have a myMPD function to create a modal dialogue, which allows multi-level menuing and prettier output.
3. Create "buttons" through script endpoint stream queue items, that then replace the queue with the desired content when played; the played track can begin playing the first item of the returned playlist, while above tracks are cleared, and below tracks are replaced with the rest of the playlist.

I don't particularly care in what direction things go, and the third option would certainly be the easiest on you to implement, since you won't have to do anything :). It would also mean that any MPD client can navigate the menu instead of just myMPD. That last point is a particular boon but I'm not sure how relevant it will be for most users. Of course, these options need not be exclusive, and a fallback to option 3 would still allow MPD clients that benefit.

[Emilot]

Are you sure qobuz plugin is still working on mpd?

MusicPlayerDaemon/MPD#1209

[antonellocaroli]

I don't think the MPD plugin is needed for this, or at least it is not necessary.
It would be a MyMpd menu that exploits the qobuz API, a bit like the LMS plugin.

[sevmonster]

If the MPD Qobuz plugin isn't working, it can always be done through Lua, though it will surely be difficult. Probably less painful than upstreaming patches to MPD to fix the plugin, however; with the glacial release schedule of MPD, and strict code quality standards Max Kellermann imposes, I am not sure I would want to undertake that. I do not code in C a lot so that would make it extra painful.

[Emilot]

I didn't say to build it. My question was if it is possible, like qobuz.

[sevmonster]

Anything is possible, with enough effort.

Qobuz removed public access for their API in late 2019, and has kept it that way since. If using the API directly as it was originally documented is no longer feasible, then it may be possible to reverse engineer some of the client apps/unofficial API projects to see how they work. And if that isn't feasible either, I will just scrape the webpages for content and pretend I'm Chrome.

It looks like the public Tidal API does not support playing tracks, but unofficial projects like Music Assistant have support for playback, so it's certainly doable in some way. There may be separate docs for implementing clients with a separate client API, I did not look too deep into it.

[Emilot]

There are open source clients with Tidal support(ex. o!mpd). I have no idea how they do it, but they claim they are!

Thank you for the information @sevmonster Very interesting stuff.

[antonellocaroli]

@sevmonster if you need help with the App ID and access keys let me know....
for Qobuz I mean.
I had already tried something with python, but without much result....
This would only serve as a test. Then the best thing would be for myMpd to ask for API access directly, a bit like umpmpdcli did.

To my knowledge, however, TIDAL does not easily release API access. Hqplayer's Sygnalist couldn't get access either, they are very closed in this respect. They have a rather questionable policy anyway.

[sevmonster]

If you have any knowledge to share, it would be very helpful. If you do not wish to share it publicly, you may contact me.

[jcorporation]

I do not like to support commercial projects with closed APIs, but if you develop scripts I will integrate it and enhance the myMPD scripting support as required.

What I like to add:

• option to define script arguments as input, radio button, checkbox and select
• Option to open a modal from running script showing a list to select from.

[jcorporation]

The above features are rather generic and can be used by other scripts also. Pushing more generic functionality to the scripting features is the way I will go. I only do not want to add specialities to the core of myMPD.

[sevmonster]

Of course, I would not ask for such a thing. myMPD should stay generic and scripts can be used to extend the core outside of what MPD already does and the nice features myMPD adds. I was just arguing for why I picked Qobuz and why I think it's good. It's off-topic from the code implementation :)

[jcorporation]

option to define script arguments as input, radio button, checkbox and select

Implemented with jcorporation/myMPD@adb237a

[jcorporation]

Dialogs for scripts are now implemented: https://github.com/jcorporation/myMPD/blob/v16.0.0/docs/scripting/functions/mympd_dialog.md

[sevmonster]

Dialogs for scripts are now implemented: https://github.com/jcorporation/myMPD/blob/v16.0.0/docs/scripting/functions/mympd_dialog.md

Awesome, can't wait to play with this. Will probably poke at it tomorrow.