Open Source Projects Europe

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf

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

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.

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.

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.

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.

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

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

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.

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!