Open Source Projects Europe

After many, many hours of listening using the Qobuz interface of the BubbleUPnP control point, first skip to the next track! Thus, this is not necessarily a problem specific of upmpdcli-qobuz, although it happens more frequently when upmpdcli-qobuz is used.

Hi,

Once the actual URI is found (a temporary one which points to the actual audio and is only valid for a limited time), the actual download/streaming of the music is performed by mpd, using the libcurl HTTP interface, and upmpdcli is not involved any more. So any fix to this issue should involve mpd, and I am wondering if the fix about buffering, which applied to the Tidal service might be of help:
https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html#_notes_on_the_tidal_interface

Please give it a try and let me know if it improves things.

Also, in my experience, the Qobuz service, which is otherwise very nice, and the only one to which I kept a subscription, does have its periods of flakiness.

Thanks, I see that this is most likely an MPD issue. Unfortunately, setting

audio_buffer_size "2048"
buffer_before_play "20%"

does not have any positive effect in my case. Also, the idea that these settings would "reduce the pre-fetch period from 20 S to 10 S" seems a little bit odd to me given that the default values are 2048 and 10%. Looking at the MPD log

May 15 18:53 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572575"
May 15 18:54 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572576"
May 15 18:55 : zeroconf: No global port, disabling zeroconf
May 15 18:55 : client: [0] opened from [::1]:40212
May 15 19:17 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=34297158"
May 15 19:29 : curl: curl failed: transfer closed with 9939224 bytes remaining to read
May 15 19:29 : flac: FLAC__STREAM_DECODER_ABORTED
May 15 19:29 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=34297160"

my impression is that curl simply gets disconnected. The other strange thing is that most users seem to be unaffected by the problem. I have myself noticed it only very recently.

Actually, the default value for the audio_buffer_size parameter is 4096 (look at DEFAULT_BUFFER_SIZE in mpd Main.cxx).

The time values are wrong though, probably carried over from something else. I'll fix them.

It was worth trying reducing the buffer though, this does have an effect with some sources which do check that you are likely to be playing, not downloading, the audio.

Then for the actual problem, I'm not too sure of what may be happening. This may depend on the actual Qobuz server that you are using, I have no idea how this is selected, but there is probably a random and a geographic element in it.

I have a conjecture: if a Qobuz account has more than 3 registered devices, it automatically starts sending interrupts to a randomly chosen device. I know that this is a crazy idea but this morning I removed one of 4 devices that were associated with my account and could stream the first three tracks of Mahler's 5th without dropouts. This was the first time since I have started to notice the track skipping problems. Later this evening, I will be able to run extensive tests and report back. Thanks for looking into this issue!

As it turns out, my conjecture was wrong. The track skipping issue does not appear to be related to the number of devices that have been associated with a Qobuz account. Apart from the standard MPD settings

audio_buffer_size "4096"
buffer_before_play "10%"

I have tried values of (2048,20%), (1024,40%), (512,80%) and (256,100%) without success. Mahler's 5th by Adam Fischer and the Düsseldorfer Symphoniker is still one of the most troublesome albums in my case: no matter which buffer size values I select, I cannot stream it from the beginning to the end without two to three track jumps.

As it turns out, my conjecture was wrong. The track skipping issue does not appear to be related to the number of devices that have been associated with a Qobuz account. Apart from the standard MPD settings

audio_buffer_size "4096"
buffer_before_play "10%"

I have tried values of (2048,20%), (1024,40%), (512,80%) and (256,100%) without success. Mahler's 5th by Adam Fischer and the Düsseldorfer Symphoniker is still one of the most troublesome albums in my case: no matter which buffer size values I select, I cannot stream it from the beginning to the end without two to three track jumps.

I have reproduced the track skipping errors on a Debian stretch system also running MPD 0.19.21. After upgrading MPD to 0.20.19, the problem persists. Thus, I am not anymore so sure that this is an MPD issue. It might be, of course. But then it would have gone unnoticed for more than one year. I'm keeping on investigating ...

I have now opened an issue on the MPD bug tracking system: https://github.com/MusicPlayerDaemon/MPD/issues/281

Haha, good luck with Max :) I have not been very responsive on this because I was moving around a lot. If I can set a little time aside, I want to experiment fetching these URLs with different tools to see if I can get an idea of what triggers the issues.