Closed orontee closed 1 year ago
There were no problem with previous playlist exposition. At that time it did more sense to me to change as suggested. However I can add an option to let user decide how it may be exposed.
There were no problem with previous playlist exposition. At that time it did more sense to me to change as suggested. However I can add an option to let user decide how it may be exposed.
Would be appreciated on my side. Thanks for your prompt reply.
I'll start my work with a version pre #10
I have now a better understanding of what directories are for in Mopidy model; I'll try to adapt Argos to provide a complete "library browser", not only an "album browser". If successful, exposing SomaFM tracks through a playlist would then not be necessary. (I still don't understand what are the albums for in case of SomaFM tracks but nevermind...).
I confirm that there's no need for Argos. Support for Mopidy-SomaFM will land on main branch soon, can be tested right now with https://github.com/orontee/argos/issues/110 branch.
Thanks!
Glad to ear about your progress. I will give it a try !
Current implementation exposes one track per channel; They're accessible under URIs like
somafm:channel:/beatblender
, etc. and discoverable through a call tocore.library.lookup
to URIsomafm:root
. Fine. I see in #10 that they used to be exposed through a playlist provider.Are Frontends now supposed to consume the exposed library through
core.library.lookup
only? What was the problem with the exposed playlist?I am maintaining Argos and would like to add support for your extension. Argos expose playlists and albums; I am currently blocked if I want to write a generic integration of your extension...
(Each track refers to an album. The album contains the same information as the track, and is not exposed in any way. Can you explain the rationale for this album?)