Question regarding a "universal playlist"

[mrzealot]

Hello!

I've long been planning to combine and streamline my music sources into some kind of a universal library/playlist where each song could have many sources (e.g., a youtube link, and if that's taken down for some reason, there's a backup soundcloud link) but nothing like this exists yet as far as I've seen... In fact, tizonia comes probably the closest with the OSS multi-source playback (which is very nice work btw!), so I'm currently thinking about building on top of this ifrastructure.

So I guess my question is: how hard does implementing this sound (for someone more familiar with the project)? My initial intuition would be adding options to the specific source handlers (like youtube and soundcloud) to play just one song by URL or source-specific identifier, and then implement the playlist as a wrapper layer controlling tizonia. But that's just the easiest/probably fastest way, and depending on how generally appealing such a feature would be, a schema definition and built-in support could be even better...

I'd love to hear your thoughts! Thanks!

[tizonia]

Hi!, first of all, thanks very much for taking the time to suggest new features. Always appreciated.

The 'universal playlist' or the general idea of combining multiple music sources to produce a 'merged' playlist that would provide some new and interesting ways of listening to music is something that has always been at the back of my head, although I have never got to the point of trying to formulate it properly.

I think, Tizonia currently as a project has several aims, e.g.

• Tizona is at its core a multimedia framework based on OpenMAX IL 1.2, and as such, it is a demonstrator for this technology.
• In addition to that, Tizonia (the cmdline player built on top of the OMX IL 1.2 framework) is a multi-service music player, and the aim there is always to keep adding as many online sources as possible.
• There are also plans to decouple Tizonia from the command line. I.e. to add the ability to spawn one or more Tizonia services (each of them talking to a specific online source) that could be driven remotely with an RPC mechanism (see https://github.com/tizonia/tizonia-openmax-il#roadmap)

So I think the 'universal playlist' in any of its many possible incarnations is something that fits very well with the current philosophy of the project.

So I guess my question is: how hard does implementing this sound

It depends I suppose. E.g. the Tizonia cmdline process is currently architected around the idea of having a single OpenMAX IL 'service' graph active at any time, i.e. a pipeline that realizes the following picture:

local or online media source -> demuxers -> decoders -> audio renderer

The current implementation handles only one of such graphs or pipelines because that is what makes sense as a cmdline application, but it does not prevent having multiple instantiated simultaneously. In fact, there are quite a few places in the code where this option is contemplated and allowed.

So one can think of various ways of realizing the 'multi-service' graph/pipeline picture that would be necessary to implement the 'universal playlist' feature, e.g.:
1- By having more than one service pipeline instantiated simultaneously in a single Tizonia process
2- By having separate Tizonia processes that talk with a coordinating process via the yet unimplemented RPC mechanism (e.g. a micro-service architecture).

The first option is probably easier right now. Tizonia does not prevent it at all and in fact, it makes it possible. Perhaps I tend to favor the second option, as it seems to me the more powerful and flexible solution. But in any case, I would be more than happy to provide assistance if anyone wanted to contribute towards any of these paths.

Please feel free to continue asking questions here if you are interested in contributing. There is also a Gitter chat that could be used to continue the conversation.
https://gitter.im/tizonia/Lobby

[mrzealot]

Thanks a lot for the detailed info! Glad to hear we agree that this is something very relevant (and potentially important) to this project.

Regarding the approaches proposed, I'd also lean more towards 2) for the decreased coupling and added flexibility. So to sum up, making it work like that would require:

1. a source-specific way to skip the "searching" approach and directly play songs by ID. Famous last words, but this sounds easy...
2. a minimal RCP connection for at least the playback controls (as changing songs could be killing the existing process and starting a new one with the next song's args). But once that's in place, in-process switching should be fairly easy too, I would guess...
3. a small controller program to deal with the playlist format and issue the commands to the underlying tizonia process. Again, shouldn't be too complicated, as the core functionality is just sending a few playback commands through unmodified + reading the library/playlist (probably in JSON) and parameterizing the spawned processes accordingly.

If this checks out, then I'd very much welcome the above-mentioned "assistance" on where to start with the first two. I think I can likely put aside some time during the next few weeks to look into this.

[tizonia]

@mrzealot Sorry for the delayed reply:

Thanks a lot for the detailed info! Glad to hear we agree that this is something very relevant (and potentially important) to this project.

Absolutely, this would be a feature that would make Tizonia really stand out!

Regarding the approaches proposed, I'd also lean more towards 2)

Happy to hear that you agree with that as well!

a source-specific way to skip the "searching" approach and directly play songs by ID.

Regarding this, Tizonia can play individual streams with some of the services that allow it, e.g.:

$ tizonia --spotify-track-id 'spotify:track:37ZJ0p5Jm13JPevGcx4SkF' 
$ tizonia --youtube-audio-stream https://www.youtube.com/watch\?v\=AKBJ-WKQlEg

SoundCloud could probably be added to the above list easily see #561.

With Google Music I believe there is no API in gmusicapi (see https://unofficial-google-music-api.readthedocs.io/en/latest/) to achieve that. Perhaps something could be done to 'simulate' that behaviour. Same story with Plex I think (see https://python-plexapi.readthedocs.io/en/latest/).

a minimal RCP connection for at least the playback controls (as changing songs could be killing the existing process and starting a new one with the next song's args).

Tizonia implements a minimal MPRIS2 interface (basically, play, pause, stop, song skip and volume). But it is missing other MPRIS features, see #509, #105 #104. I have not invested more time on MPRIS because it depends on the orphan dbus-cplusplus library, which has no maintainer nowadays (as far as I know). So I had to embed it into the project some time ago to be able to apply some critical fixes (see https://github.com/tizonia/tizonia-openmax-il/tree/master/3rdparty/dbus-cplusplus). Also back in the day, I ended up hitting some walls with dbus-cplusplus which persuaded me to stop developing the MPRIS functionality any further.

Because of all that, I started entertaining the idea of adding a more fully featured RPC mechanism (e.g. something based on JSON-RPC, see #488). I think my preference is still to create a tizonia-specific JSON-RPC interface. I could be persuaded to go back to MPRIS if someone could do the heavy lifting of replacing dbus-cplusplus for something that is actually maintained (difficult) or fixing it to get the rest of the MPRIS2 functionality implemented in Tizonia (I think also difficult).

Let me know your thoughts.

[nikhiljha]

Tomahawk was a music player that separated metadata from the actual audio files and did exactly what you mentioned...

(e.g., a youtube link, and if that's taken down for some reason, there's a backup soundcloud link)

... except fully automatically. Unfortunately it's dead now but some backends still work. :)