Introducing 'MyQobuz'

[upickartz]

Hello, I have written a small extension for the Qobuz plugin. If you think this extension fits in the concept of the Qobuz plugin, I would like to make a pull request. Please have a look at 

https://github.com/upickartz/SqueezeboxQobuz/blob/MyQobuz/README_MyQobuz.md

To show my intensions find here an outline of the first section:

The Qobuz plugin is a great tool searching for new music. What I was missing is access to a defined collection of albums, for hearing my music on Qobuz, not seeing each album of an artist. Therefore, a new section 'MyQobuz' is provided, which contains my selected albums. Additionally, to the selection by genre and/or (alphabetically sorted) artists, a possibility to define tags for ‘MyQobuz’ albums is provided. It is also possible to correct the definition of the genre of an album defined by Qobuz, because often the Qobuz definition doesn't fit for me.

[michaelherger]

Thanks a lot for this suggestion! As I'm neither a Qobuz user, nor a Classical listener, I'm not sure I follow the idea. Isn't this partly duplicating what the "My Favorites" menu provides? There's a TON of database code... will this not be confusing users, between Qobuz Favorites, LMS Favorites, and MyQobuz?

I also believe that as your code is pretty much self contained, would it be possible to provide a plugin hooking in to the Qobuz plugin, rather than including this in the main code?

@SamInPgh, @darrell-k - you know the service much better than I do. What are your thoughts?

[darrell-k]

I think there are a lot of good ideas here. But versions of many of them are available in LMS once you've imported your Qobuz Favorites - view by artist, genre etc. If there are useful views which LMS does not provide at present, or tags we do not hold in the database, we should make them available for the user's entire LMS collection, through enhancements to Additional Browse Modes, for example.

On Qobuz genres, we already have advanced genre replacement in online music library integration settings - of course enhancements to that, too, are possible.

Currently, the "Library Views" feature in LMS allows selection of local files, or all. Probably that could be enhanced easily enough to allow selection of specific online services only.

One feature in this which is definitely Qobuz-specific and would be very useful in the plugin is the ability to show and correct "lost albums" caused when Qobuz changes the URL of an album (or replaces with a remaster, or whatever).

In general, I would steer clear of creating additional databases and enhance the one we've got, as has been done for the recent Classical Music Enhancements.

I think that the way forward here is to itemise the new features, mapping to partial or complete solutions already in LMS, therefore coming up with a list of possible enhancements, and then deciding where they should be implemented - base LMS, another plugin, or Qobuz plugin?

[upickartz]

Hi , Thanks for your review and your feedback. I agree some overlapping functionality, but therefore I made the extension switchable, and also the Integration of Qobuz in the music library is switchable. So the user can decide which approach he preferes. For me the 'MyQobuz' section fits exactly my requirements (and I avoided choosing the term favorite like michaelherger said to be confusing). So I would like to follow the proposal of michaelherger and try to make a plugin hooking. Do you have a hint or an example for me for such a plugin hooking? Kindly Regards Ulrich

[michaelherger]

I think what you'd need for the main plugin is a method to register an additional menu item. In Plugins::Qobuz::Plugin there would be a global variable @additionalMenuItems, a method registerAdditionalMenuItem(). The latter would accept a title and a function reference which would be added to the list. Then handleFeed would call that function ref to create the additional menu. All the rest could remain in your plugin. In your Plugins::MyQobuz::Plugin you'd implement a postinitPlugin method: it's like initPlugin, but would be called once all plugins had been initialized. This would allow you to check for the existence of Plugins::Qobuz::Plugin, and if it existed you would call its registerAdditionalMenuItem().

That said I'd recommend you do re-consider adding your own database, as @darrell-k suggested. I wouldn't even give the user the option to tell where to store it. It's just complexity which will cause trouble, as people will try to store in write protected places etc. Simply store it in the prefs folder and don't ask. That folder is writable (or LMS would not start), and it's not wiped (like the cache folder).

[upickartz]

Thanks for the hints of Michael Herger. I now changed the location of the database to prefs and make the location definition unvisible in the settings by default. (I need the configuration in my own enviroonment.) The check of availability of the 'Qobuz plugin' is done in the postinitPlugin method as proposed. The new separate plugin is now ready and working: https://github.com/upickartz/plugin-MyQobuz I would provide the new plugin to the '3rd party plugin' section. What do I have to do to add my repo description to the 3rd party list?

From my point of view we now can close this issue.

[michaelherger]

You'll have to provide a download url for a repository file which points at the downloadable .zip file. See https://lyrion.org/reference/repository-dev/. As the URL for the downloadable file should be unique with each release I'd recommend you either use the Github release feature (which will create a unique release ID), or you rename the files by release version.

A Github workflow can help with this. See eg. https://github.com/michaelherger/lms-plugin-tidal/blob/main/.github/workflows/release.yml. You'd then only have to do a few mouse clicks on Github to have the plugin versions published.