#11 upmpdcli-qobuz: random jumps to the next track

None
closed
nobody
random skip jump track (1)
2018-10-06
2018-05-07
nbpf
No

Description: During Qobuz streaming via the upmpdcli-qobuz interface, random jumps to the next track.

More details: The jumps are apparently random, not easy to reproduce but not rare. In average, I observe one jump ever album, sometimes more. Typically, restarting replay from the track at which the jump has occurred does not yield another jump. The jumps are observed with different control points (Linn Kazoo iOS and Android, BubbleUPnP) and seem to affect also the Tidal interface. Some microRendu users have also experienced the same problem, see https://www.computeraudiophile.com/forums/topic/38113-help-trouble-shooting-skip-to-next-track-problem-in-my-streaming-setup/.

Important: Qobuz streaming to upmpdcli using the Qobuz interface of the BubbleUPnP control point (instead of upmpdcli-qobuz) works flawlessly on the same system. This strongly suggests that the jumps are caused by the upmpdcli-qobuz interface.

System: Linux rpi5 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux

upmpdcli: Upmpdcli 1.2.16 libupnpp 0.16.1

Discussion

  • nbpf
    nbpf
    2018-05-13

    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.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-05-15

    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.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-05-16

    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.

     
    Reply
    Link Attach

  • Anonymous
    Anonymous
    2018-05-16

    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!

     
    Reply
    Link Edit
    Delete


    Attach

  • nbpf
    nbpf
    2018-05-18

    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.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-05-18

    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.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-05-19

    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 ...

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-05-22

    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.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-05-22

    Thanks! I have played a little bit around with curl options (no-keepalive, ignore-content-length) via .curlrc but I doubt that .curlrc is accounted for for when curl is called from within MPD. Given that it is very difficult to reproduce the same sequence of failures, I would normally think that these are network or Qobuz problems. The truth, however, is that the four albums that make a lot of troubles stream perfectly fine via the Qobuz app or even via the BubbleUPnP app when the selected renderer is the app's local renderer. It is only when the files are fetched by MPD (no matter whether upon requests from upmpdcli or from BubbleUPnP) that the failures occur. I think that the relevant code in MPD is in src/lib/curl/Request.cxx but I would have to invest some time to be able to do some meaningful hacking.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-05-23

    Perhaps two more pieces of information: the failures occur no matter whether I stream mp3 files or flac files from the same albums. I have streamed the 4 Mahler's albums from Adam Fischer and the Düsseldorfer Symphoniker in a loop and what I can say at the end of the day is that MPD 0.20.19 has less failures than MPD 0.19.21. The two versions were running on different machines, though: a fitpc3 and a Raspberry Pi 3B+.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-05-25

    I have started some tests on the Mahler albums (using a non-mpd curl fetcher).

    One thing I thought of which could explain the difference would be if the apps which never fail actually retry the transfer when it is interrupted. Given the buffer sizes, there are several seconds available for reconnecting and seeking to the point of failure, this should be quite feasible.

    This should be visible in wireshark if it happens.

     
    Last edit: medoc 2018-05-25
    Reply
    Link Attach

  • medoc
    medoc
    2018-05-26

    I had 1 failure in 4 hours yesterday while transferring the Mahler albums.

    My feeling at this point is that the Qobuz servers do have some relatively rare transfer issues, and that the players which do not fail probably retry the transfers internally.

    I am going to implement a retry in the test program to see how it goes.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-05-26

    I never see such a failure rate. I also feel that there is something variable on the Qobuz side, maybe what cache server you are connected to (they most probably use a cdn).

    It's very difficult to draw conclusions on a process with low occurrence and unknown random varying factors.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-05-26

    I agree but while sometimes the Mahler's albums (I usually test them in the order 5th, 4th, 7th, 1st and then 5th again) go through with perhaps only three failures, I can clearly see failure patterns in my setup: I very rarely observe failures on the 7th and on the 1th. On the other hand, the 5th and the 4th almost always make troubles.

    What is really strange is that the issue doe not seem to affect the Qobuz app. Also, notice that the BubbleUPnP control point streams perfectly fine all Mahler's albums through the local renderer.

    But the same BubbleUPnP control point yields failures when the selected renderer is upmpdcli and hence MPD. This again supports your conjecture that the Qobuz app renderer and the BubbleUPnP renderer are using different fetching approaches than MPD.

     
    Last edit: nbpf 2018-05-26
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-06-10

    It seems to be primarily a problem with long tracks: no way to stream the first track of Bruckner's 9th, no matter whether by Abbado or by Mazeel, from the beginning to the end with upmpdcli/MPD.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-07-03

    Ok, at some point, I was quite certain that at least Google music detected fast transfers and shut them off (which is more logical than timing out on transfers close to play speed).

    Maybe I was wrong, or Qobuz/Tidal work differently, and maybe Max had information from one of the services (I think that the implementation they are working on is more or less official), so let's hope...

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-09-24

    I have installed Upmpdcli 1.3.2 (libupnpp 0.16.1) and it is an improvement. There are still jumps but they are less frequent.

    Thus, it seems that between 1.2.16 and 1.3.2 something has happened that has helped reducing the frequency of curl failures.

    Whether this is due to changes in Upmpdcli, in MPD, at the OS level or in the Qobuz servers I do not know.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-09-25

    There should be no significant change on the upmpdcli side, except if you set

    plgproxymethod = proxy

    in the configuration file. Then you may see messages like the following in the log file (at level 3):

    Reader: retrying at xxxx

    This would confirm that the proxy is retrying the fetches. Actually you could try to set this to see if it gets rid of the last jumps.

    Without this parameter, upmpdcli is redirecting MPD directly to the Qobuz server, and any change could only come from MPD itself.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-09-27

    I have set the 'plgproxymethod = proxy' flag in the configuration file and could stream for more than 12 hours from Qobuz without any problem. Thanks for this improvement, now Qobuz becomes really usable!

    I have set level 3 logging in upmpdcli.conf but I do not see any retry message in the log files so far. In this latest experiment I have only streamed for about two hours, albeit two of the problematic Mahler symphonies.

    I will run some more tests but for the time being everything seems to be fine. Perhaps it is worth mentioning that 'plgproxymethod = proxy' should probably not be used if the selected library is already a "mediaserver [proxy]" as generated by Bubble UPnP.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-09-29

    I was perhaps a little bit too optimistic with my previous post. Upmpdcli 1.3.2 libupnpp 0.16.1 (but also the Qobuz interface of the Bubble UPnP control app) gets stuck at the end of tracks 4 and 5 of https://www.qobuz.com/de-de/album/bernstein-symphonies-nos-1-3-prelude-fugue-riffs-antonio-pappano/j5y25ahdwr2tc. The error does not always occur but almost always for these tracks. The upmpdcli log file contains a bunch of lines like

    :2:src/mediaserver/cdplugins/curlfetch.cpp:443::CurlFetch::curlWorkerFunc: curl_easy_perform(): Failed sending data to the peer

    and

    :3:src/upmpd.cxx:159::checkContentFormat: format check disabled

    The Qobuz app does not appear to have any problem with the tracks.

     
    Last edit: nbpf 2018-09-30
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-09-30

    I can confirm that the above tracks stream flawlessly if plgproxymethod is set to redirect as per default.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-09-30

    I can confirm that the above tracks stream flawlessly if plgproxymethod is set to redirect as per default.

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-10-02

    Hi,
    I've been streaming the 2 tracks above for hours, in proxy mode, with no issue. I am streaming high quality, not lossless.

    I have added the send error to the retryable errors in the current git code.
    I really feel that the errors depend on what server in the content distribution network you are connected to. Unfortunately, mine seems quite reliable, so I have trouble reproducing the issues and finding a fix.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-02

    Yes, I have upgraded to Upmpdcli 1.3.4 libupnpp 0.16.1 today and the issues appear to have disappeared. I am going to stream some of the problematic albums overnight and report tomorrow. Thanks for your support!

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-02

    Yes, I have upgraded to Upmpdcli 1.3.4 libupnpp 0.16.1 today and the issues appear to have disappeared. I am going to stream some of the problematic albums overnight and report tomorrow. Thanks for your support!

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-02

    Yes, I have upgraded to Upmpdcli 1.3.4 today and the issues appear to have disappeared. I am going to stream some of the problematic albums overnight and report tomorrow. Thanks for your support!

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-02

    Yes, I have upgraded to Upmpdcli 1.3.4 today and the issues appear to have disappeared. I am going to stream some of the problematic albums overnight and report tomorrow. Thanks for your support.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-02

    Yes, I have upgraded to Upmpdcli 1.3.4 today and the issues appear to have disappeared. I am going to stream some of the problematic albums overnight and report tomorrow. Thanks for your support.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-02

    Sorry for posting multiple messages, this portal is nearly unusable with Chrome and I do not seem to be able to even log in through Firefox!

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-04

    Here are my findings: Using the standard UpMPD-mediaserver there are no track skips anymore but replay eventually gets stuck at the beginning of a track. It does not happen very often and it is not obviously reproducible but it happens. If I put, say, 10 hours of music on the queue, it might get stuck after 10 minutes or after 2 hours. But it get stuck well before 10 hours.

    If I use BubbleUPnP Server (running on a RPi wired to the router, the UpMpd-mediaserver runs on a RPi connected to the LAN via wireless) to create a UpMPD-mediaserver proxy and I fill in the queue using the proxy, then replay is flawless. I have tested it for about 15 hours uninterrupted.

    I can live with this, running BubbleUPnP Server is not a problem. Thus, this is just to provide you with some more feedback. From my point of view the original issue (random jumps to the next track) has been solved and the ticket can be closed. Thanks for your support!

     
    Reply
    Link Attach

  • medoc
    medoc
    2018-10-05

    Thank you for the feedback.

    I've been playing from qobuz in proxy mode for quite a few hours without a problem as far as I can see. I'll keep testing until tomorrow (it's not a big effort :) ), but at this point I don't see much more I can do, so I agree, and I'll close the issue, but keep the possible problem in mind. Probably I'd need a flaky Qobuz distribution server to reproduce it, and mine seems flawless, so no luck.

     
    Reply
    Link Attach

  • nbpf
    nbpf
    2018-10-05

    Ok, in my network, examples of albums for which it happens most often that replay gets stuck at the beginning of a track are

    https://www.qobuz.com/de-de/album/bernstein-symphonies-nos-1-3-prelude-fugue-riffs-antonio-pappano/j5y25ahdwr2tc

    and

    https://www.qobuz.com/de-de/album/solo-emmanuel-pahud/a85hhlh3si7cc

    The interruptions typically happens after a short track, for instance track 5 of the Pappano album. The "Now playing" screen then jumps to track 6 but replay does not start. In the playlist the cursor indicates that track 6 is being played but in the "Now playing" screen the time is fixed at zero. Attempts at resuming replay on track 6 (both from the "Now playing" screen and from the playlist fail. But tapping another track of the playlist starts replay of that track without problems.

     
    Reply
    Link Attach

    • medoc
      medoc
      2018-10-06

      I've been playing the pahud album for around 24 hours, with no luck, so closing this, I'll reopen if the issue manifests itself again (I am convinced that there is an issue, but I can't fix it if I can't reproduce it).

       
      Reply
      Link Attach

  • medoc
    medoc
    2018-10-06

    • status: open --> closed
    • milestone: -->
     
    Reply
    Link Attach

Anonymous
Anonymous

Preview Formatting Help

Cancel   Add attachment