Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Problem: Qobuz support
#1
Hi Tim,

Thank you all you do in developing Moode.  One query: am I correct in saying Qobuz and is currently unsupported because of the problem reported here: http://moodeaudio.org/forum/showthread.p...ight=qobuz ?  I ask because if this is the case, I suggest temporarily disabling this in the dialogues in Moode or at least providing a warning.

Just to confirm - I have done the following in v6.4.2:
- UPnP client for MPD is set to on
- I've entered my Qobuz credentials in UPnP config page
- I've created a new UPnP music source in the Library (I can't however see this in Moode, though it does see my other UPnP server - MinimServer when this is defined as a music source - so not sure if I should be doing something else...)
- Using an external UPnP player (Linn Kazoo), I can see Moode but when I see the message Service login or communication failure 

Many thanks.
Reply
#2
Any advice from anyone would be appreciated. Thanks.
Reply
#3
@SoundAdikt

Tim integrated upmpdcli into moOde to provide us UPnP functionality. Baked into upmpdcli is support for a select few commercial streaming services, among them Qobuz. Here's a quote from the upmpdcli site

Quote:2019-10-06

Qobuz access was revoked: If you were using Qobuz and it's not working any more, don't pull your hair, the Qobuz plugin stopped working (either through the Media Server or with OHCredentials). Qobuz revoked the app_id, and also deleted the API documentation on Github. If you are a hardware integrator/manufacturer using upmpdcli to support Qobuz access (I know there are some), I made a modification to the Qobuz plugin so that the app_id/secret can be stored externally instead of being embedded in the source. This means that, if you can convince Qobuz to supply you with the appropriate pair, you can easily restore function, without having to support a modified module. Of course, this supposes that the API itself does not change.


The upmpdcli maintainer has indicated he is not going to press Qobuz for the necessary app_id/secret. I can't speak for Tim but I suspect he has no desire to either. They seem unfriendly to non-commercial developers.

Meanwhile, we can still use moOde's various connectivities---UPnP or Airplay or Bluetooth---to listen to Qobuz via some other app. Not ideal, perhaps, but workable.

And, yes, it probably would be best just to remove the Qobuz option in the UPnP Config panel, but that's Tim's call.

Regards,
Kent

PS - I do not have a Qobuz subscription so this is just "chalk talk".
Reply
#4
Thanks Kent, that's what I had read as well, I just wanted to check. At present, I use Airplay. As a Qobuz customer, I guess I've nothing to lose by asking them for my own App ID, if they oblige, where should this info be stored and how should it be formatted?

Edit:

I found this file:
/usr/share/upmpdcli/cdplugins/qobuz/api/raw.py

In it, it contains two entries:
self.appid = '<hidden>' # XBMC
...
s3b = '<hidden>'

Should these entries be edited?
Reply
#5
(03-02-2020, 08:53 AM)SoundAdikt Wrote: Thanks Kent, that's what I had read as well, I just wanted to check. At present, I use Airplay.  As a Qobuz customer, I guess I've nothing to lose by asking them for my own App ID, if they oblige, where should this info be stored and how should it be formatted?

Edit:

I found this file:
/usr/share/upmpdcli/cdplugins/qobuz/api/raw.py

In it, it contains two entries:
self.appid = '<hidden>'  # XBMC
...
s3b = '<hidden>'

Should these entries be edited?

[Sorry for my now deleted reply. Too late, I realized I had taken two reasonable thoughts and mushed them into one unreasonable answer.]

What you are asking about is moOde's current codebase which includes upmpdli v1.2.16. AFAICT what you suggest is correct.

In this version of upmpdcli, these entries are hidden in raw.py. In the current version (v1.4.7), the Session class definition has been changed in session.py in the following way

Code:
FROM

class Session(object):
   def __init__(self):
       self.api = None
       self.user = None

   def login(self, username, password):

TO

class Session(object):
    def __init__(self):
        self.api = None
        self.user = None

    def login(self, username, password, appid, cfvalue):


So the requisite credentials are passed in from outside the upmpdcli code. I haven't looked at the implication for moOde's use of the new code.

Regards,
Kent

PS - Yes, moOde is behind the current release but apparently it's not a drop-in replacement and will need developer time to make changes mutatis mutandis and test the result.
Reply
#6
Wow Kent, thanks for your quick reply and info. I'm in awe of all the great people that provide help on top of the excellent work by Tim. If I get anywhere, I will let you.
Reply
#7
(03-02-2020, 03:11 PM)TheOldPresbyope Wrote: So the requisite credentials are passed in from outside the upmpdcli code. I haven't looked at the implication for moOde's use of the new code.

I don't have a subscprtion to Qobuz so can't test this, but I guess this approach may have been devised so as allow upmpdcli to function with Qobuz when Linn's Kazoo is being used as the control app, as Kazoo features a login prompt for Qobuz and coincidentally Tidal.

Edit: I've just realised that what I've outlined above was a version 1.3.2 change to upmpdcli, so by the sounds of it this is unlikely to work with the current version of Moode..
Reply
#8
This is exactly what I am doing: I have a Linn System which I control using Kazoo. I use the same control point to control Moode. Kazoo has specific support for Qobuz which is currently not supported by Moode. However, Moode presents Qobuz as a UPnP based folder structure but as Moode can't connect (currently) to Qobuz, the folder structure stops due to the inability to successful login into Qobuz. If you enable UPnP browsing within Moode, you can do the same (as I understand) through the standard Moode web UI.
Reply
#9
(03-03-2020, 11:06 AM)Zigzag Wrote:
(03-02-2020, 03:11 PM)TheOldPresbyope Wrote: So the requisite credentials are passed in from outside the upmpdcli code. I haven't looked at the implication for moOde's use of the new code.

I don't have a subscprtion to Qobuz so can't test this, but I guess this approach may have been devised so as allow upmpdcli to function with Qobuz when Linn's Kazoo is being used as the control app, as Kazoo features a login prompt for Qobuz and coincidentally Tidal.

Edit: I've just realised that what I've outlined above was a version 1.3.2 change to upmpdcli, so by the sounds of it this is unlikely to work with the current version of Moode..

If you look at upmpdcli's release notes you'll see that Kazoo has been an ongoing issue for the dev, but it seems to be in hand now. It was my understanding that the Session class for the Qobuz plugin was changed to add the appid and secret parameters speficially because of Qobuz's change in policy, not because of Kazoo's behavior. But, hey, I've been known to be wrong before so why not now?

Either way, Qobuz is problematic for open-source software developers.

Regards,
Kent
Reply


Forum Jump: