Help Trouble Shooting Skip-to-next-track problem in my Streaming setup

[rodrigaj]

1 hour ago, Cebolla said:

Wow, so the Sonicorbiter OS's upmpdcli OpenHome renderer setting is switched on - I'd assumed if Sonicorbiter was using upmpdcli, OpenHome would have been disabled, precisely to avoid having two OpenHome renderers when using the BubbleUPnP Server!

This is what you've got:

and this 

@nbpf Thank you for helping me understand this.

[Cebolla]

34 minutes ago, davide256 said:

I can safely say that I never enabled Bubble UPNP the entire time I had a MR.

 

BubbleUPnP Server would have still been required for Qobuz and TIDAL access to appear on the OpenHome controller app, so perhaps you didn't try those streaming services.

 

 

35 minutes ago, davide256 said:

One question... if the MPD/DLNA mode + Bubble UPNP server isn't working, can the OP alternatively try the Squeezelite mode also indicated as supported by Sonore?

 

Yes, but remember the OP is using Qobuz, which in Squeezelite mode requires the Logitech Media Server plus appropriate LMS plugin to provide Qobuz access. Havung said that there is a built-in LMS provided by Sonore, so similar to the BubbleUPnP Server. It would also mean having to use a Squeezebox type controller, instead of a standard UPnP/DLNA or OpenHome controller.

[davide256]

1 hour ago, Cebolla said:

 

BubbleUPnP Server would have still been required for Qobuz and TIDAL access to appear on the OpenHome controller app, so perhaps you didn't try those streaming services.

 

 

 

Yes, but remember the OP is using Qobuz, which in Squeezelite mode requires the Logitech Media Server plus appropriate LMS plugin to provide Qobuz access. Havung said that there is a built-in LMS provided by Sonore, so similar to the BubbleUPnP Server. It would also mean having to use a Squeezebox type controller, instead of a standard UPnP/DLNA or OpenHome controller.

So far what I see in this thread

1. Qobuz/Tidal use is a "hack" by Sonore  vs native support, using MPD/DLNA on top of a local instance of Bubble UPNP server

2. system resource use is dramatically increased by this hack

 

Any possibilities within the OS of Sonicorbiter to free up additional system resources?

[sockpit]

4 minutes ago, davide256 said:

So far what I see in this thread

1. Qobuz/Tidal use is a "hack" by Sonore  vs native support, using MPD/DLNA on top of a local instance of Bubble UPNP server

2. system resource use is dramatically increased by this hack

 

Any possibilities within the OS of Sonicorbiter to free up additional system resources?

 

I think the suggestion that I kill the bubbleupnp server on my mR and install and use the same on my MacBook might have been an attempt at freeing up resources.  I tipries that and the skip returned.

 

I’ve  been listening for a couple days to pop music via Lumin with no skips.  It’s when I turn to a 15 minute classical movement tha chances a good it will skip.

 

How far would this thread go if under the Sonore forum?  It seems we have some intelligent and civil exchanges here going about a problem seeking a solution.

 

@vortecjr ?

[rickca]

19 minutes ago, davide256 said:

2. system resource use is dramatically increased by this hack

How did you come to this conclusion?  I'm not saying you're wrong, I just want to understand what you looked at.

[Cebolla]

Indeed - the possibility of a resource issue caused by using the built-in BubbleUPnP Server was of the first things that was thought of and discounted with the use of an external BubbleUPnP Server and the same problem occuring, as mentioned (again!) by the OP.

 

BTW, the suggestion was also the only (albeit indirect) contributation Sonore have made to the discussion in this thread thus far.

[davide256]

Just now, Cebolla said:

Indeed - the possibility of a resource issue caused by using the built-in BubbleUPnP Server was the first things that was thought of and discounted with the use of an external BubbleUPnP Server and the same problem occuring, as mentioned (again!) by the OP.

 

BTW, the suggestion was also the only (indirect) contributation Sonore have made to the discssion in this thread thus far.

If it's not a resource contention issue, the only other time I've seen like problem is with a memory leak...

[nbpf]

3 hours ago, davide256 said:

If it's not a resource contention issue, the only other time I've seen like problem is with a memory leak...

Just to make sure that we are not overseeing something trivial:  could those of us who are experiencing track skips please check that the time (date) on the replay device is properly set? upmpdcli seems to be quite sensitive to time settings errors. Thanks, nbpf 

[sockpit]

3 hours ago, nbpf said:

Just to make sure that we are not overseeing something trivial:  could those of us who are experiencing track skips please check that the time (date) on the replay device is properly set? upmpdcli seems to be quite sensitive to time settings errors. Thanks, nbpf 

@nbpf can you put that in lay terms for me.  What is my reply device?  Thx.

[nbpf]

3 hours ago, sockpit said:

@nbpf can you put that in lay terms for me.  What is my reply device?  Thx.

In your case it is the ultraRendu, in my case it is the Raspberry Pi that runs upmpdcli. I have realized that, if the time of the Pi is not set properly and, therefore, likely very different from the time of Qobuz servers, then streaming is inconsistent. Time errors or time adjustments might have nothing to do with the track skipping problem, of course. But since we anyway are in the dark, it would be worth checking. I typically check (and set) the time on my Pi from the command line with the "date" command. Your ultraRendu likely uses internet time servers to adjust its internal hardware clock. You should be able to check and set the time of the ultraRendu's internal clock via its web interface, I would expect. 

[sockpit]

Thanks.  Sonicorbitor, the software on my uR provides simple "localization" function where I can select the correct timezone.  Beyond that I'm unaware of a place to insert a date command, and I wouldn't trust myself to do that anyway   I'm set in the right time zone.  

 

[nbpf]

6 hours ago, sockpit said:

Thanks.  Sonicorbitor, the software on my uR provides simple "localization" function where I can select the correct timezone.  Beyond that I'm unaware of a place to insert a date command, and I wouldn't trust myself to do that anyway   I'm set in the right time zone.  

 

Doesn't the web interface of th euR show its current time? If not, just forget it? Otherwise, please check that the time is more or less correct. Best, nbpf 

[sockpit]

No, it doesn't show such.

 

Thanks for all your efforts.  I think at this point we’re taking blind stabs in the dark.

 

Sonore isn’t unaware of our fumbling and speculation  . . . 

[nbpf]

First track skip while using the Qobuz interface of the BubbleUPnP control point after many, many hours of listening! Thus, also in my system, this is not only a problem of the upmpdcli interface to Qobuz.  

[nbpf]

So far I have not been able to stream Mahler's 5th symphony by Adam Fischer and the Düsseldorfer Symphoniker without track jumps, no matter whether I use the Qobuz interface of the BubbleUPnP app or the one provided by upmpdcli. The album seems to be particularly critical for my setup.

 

I have come across a thread on a DS specific track skipping issue on the Linn forum, see https://forums.linn.co.uk/bb/archive/index.php?thread-36476-4.html. At page 4, one contributor (mlee) reports an issue very similar to the one discussed here. His solution, after months of track jumps, was to set his router to use the Google's public DNSs instead of the default domain name servers suggested by his IP. In his case, the default DNSs turned out to yield latency issues that causes the occasional track skips.

 

I am now trying this approach and will report back.

[davide256]

1 hour ago, nbpf said:

So far I have not been able to stream Mahler's 5th symphony by Adam Fischer and the Düsseldorfer Symphoniker without track jumps, no matter whether I use the Qobuz interface of the BubbleUPnP app or the one provided by upmpdcli. The album seems to be particularly critical for my setup.

 

I have come across a thread on a DS specific track skipping issue on the Linn forum, see https://forums.linn.co.uk/bb/archive/index.php?thread-36476-4.html. At page 4, one contributor (mlee) reports an issue very similar to the one discussed here. His solution, after months of track jumps, was to set his router to use the Google's public DNSs instead of the default domain name servers suggested by his IP. In his case, the default DNSs turned out to yield latency issues that causes the occasional track skips.

 

I am now trying this approach and will report back.

DNS is used for initial lookups... shouldn't affect an uninterrupted session. This sounds more like a session timeout/reset with the Qobuz servers

[nbpf]

11 minutes ago, davide256 said:

DNS is used for initial lookups... shouldn't affect an uninterrupted session. This sounds more like a session timeout/reset with the Qobuz servers

I agree:

 

May 13 19:48 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572577"
May 13 20:01 : curl: curl failed: transfer closed with 6255341 bytes remaining to read
May 13 20:01 : flac: FLAC__STREAM_DECODER_ABORTED
May 13 20:02 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572578"

[davide256]

47 minutes ago, nbpf said:

I agree:

 

May 13 19:48 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572577"
May 13 20:01 : curl: curl failed: transfer closed with 6255341 bytes remaining to read
May 13 20:01 : flac: FLAC__STREAM_DECODER_ABORTED
May 13 20:02 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572578"

It would be a good experiment to find the different Qobuz servers and see if you could force sessions to the best path server. A congested peering point could cause the issue

experienced... i.e. traffic is going to closest server but peering point used to reach that server is congested, vs a more distant server reached by different peering point/path without congestion.

[nbpf]

20 minutes ago, davide256 said:

It would be a good experiment to find the different Qobuz servers and see if you could force sessions to the best path server. A congested peering point could cause the issue

experienced... i.e. traffic is going to closest server but peering point used to reach that server is congested, vs a more distant server reached by different peering point/path without congestion.

Any idea how to find out the current Qobuz server? I am not very comfortable with netstat, watch, etc.

[davide256]

1 hour ago, nbpf said:

Any idea how to find out the current Qobuz server? I am not very comfortable with netstat, watch, etc.

yea, that could be hard given the use of regional CDN's and the way their DNS is constantly updated.

 

This CA thread with some problems discussed last year suggests an alternate path, use Google DNS server IP addresses to get a more complete route set for Quboz.

I couldn't find a way to change the DNS settings in  a microRendu, it looks like you would need to change this in your router.

 

 

[nbpf]

Feedback from the developer of upmpdcli, see https://opensourceprojects.eu/p/upmpdcli/tickets/11/. The bottom line is that this is a MPD problem (as indicated by the log reported above). The suggestion is to set 

 

audio_buffer_size "2048"
buffer_before_play "20%"

 

in mpd.conf. I will not be able to try this until tomorrow evening.

[rodrigaj]

6 hours ago, nbpf said:

Feedback from the developer of upmpdcli, see https://opensourceprojects.eu/p/upmpdcli/tickets/11/. The bottom line is that this is a MPD problem (as indicated by the log reported above). The suggestion is to set 

 

audio_buffer_size "2048"
buffer_before_play "20%"

 

in mpd.conf. I will not be able to try this until tomorrow evening.

 

Unfortunately, for @sockpit those settings are not adjustable in the SonicOrbiter OS. At least not anywhere that I can see.

 

I still am having problems with Tidal skipping tracks so it is not just a Qobuz problem.

[Cebolla]

On 5/13/2018 at 3:04 PM, nbpf said:

First track skip while using the Qobuz interface of the BubbleUPnP control point after many, many hours of listening! Thus, also in my system, this is not only a problem of the upmpdcli interface to Qobuz.  

 

That's more like it. So we now seem to have the same microRendu skipping issue,  occurring with a known upmdpcl setup and it is unlikely to be anything to do with the TIDAL & Qobuz stream proxies, ie, BubbleUPnP Android app, BubbleUPnP Server and UpMpd-mediaserver.

 

 

8 hours ago, nbpf said:

Feedback from the developer of upmpdcli, see https://opensourceprojects.eu/p/upmpdcli/tickets/11/. The bottom line is that this is a MPD problem (as indicated by the log reported above). The suggestion is to set 

 

audio_buffer_size "2048"
buffer_before_play "20%"

 

in mpd.conf. I will not be able to try this until tomorrow evening.

 

Ok, though this mpd buffer issue is likely to be restricted to instances when mpd is decoding compressed audio file streams or may be just FLAC file streams, since the Sonore devices have been reported to behave themselves when playing WAV file streams from Audirvana Plus, which always transcodes the original FLAC file streams from TIDAL to WAV.

 

So may be the buffer problem is what's causing the FLAC decoder that mpd is using to abort:

On 5/13/2018 at 8:33 PM, nbpf said:

I agree:

 

May 13 19:48 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572577"
May 13 20:01 : curl: curl failed: transfer closed with 6255341 bytes remaining to read
May 13 20:01 : flac: FLAC__STREAM_DECODER_ABORTED
May 13 20:02 : player: played "http://192.168.178.31:49149/qobuz/track?version=1&trackId=47572578"

 

[nbpf]

2 hours ago, rodrigaj said:

 

Unfortunately, for @sockpit those settings are not adjustable in the SonicOrbiter OS. At least not anywhere that I can see.

 

I still am having problems with Tidal skipping tracks so it is not just a Qobuz problem.

Let's first try out whether the suggested settings solve or at least alleviate the issue. If opportune, Sonore can easily provide a SonicOrbiter image with new settings. Since the Rendu devices boot from the SD card, users can always make a security copy of their system and play around with new settings, can't they?

[davide256]

2 hours ago, nbpf said:

Let's first try out whether the suggested settings solve or at least alleviate the issue. If opportune, Sonore can easily provide a SonicOrbiter image with new settings. Since the Rendu devices boot from the SD card, users can always make a security copy of their system and play around with new settings, can't they?

Is the 2048 actually 2GB? In which case you would need to make sure  the SD card has at least 2GB free space?