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

[sockpit]

I’m still not riding.  Just did a lumin vs. A+ comparison on a familiar Allison Krauss song.  The difference is real, and the lumin is a bit flat and boring.  I’m surprised, and I don’t think I’m hearing merely something new.  It’s better.  

 

Have you moved to something else or are you an A+ guy.  Looks like your Innuos might be the streamer substitute.  Am thinking of buying Exogal’s streamer when it comes out soon. . . . Nevermind, I see above your using LMS.

[rickca]

Just now, sockpit said:

Have you moved to something else or are you an A+ guy.

LOL, sorry to have killed your bike ride.  I am now using an Innuos Zenith SE so I'm not using A+.  I do, however, still have an ultraRendu that I may use in my other system.  I'm not at all familiar with Exogal's product line.

 

If you send an album or a playlist to your play queue, does the beginning of track problem happen on every track?  Or does it only happen on the first track added to the play queue?  

 

I think I'm done with CA for the day.  I need to listen to some music, and you need to get some fresh air and exercise.

[sockpit]

Good plan, thanks.  (And I thought it was as good as it could get.)

[sockpit]

19 hours ago, rickca said:

If you send an album or a playlist to your play queue, does the beginning of track problem happen on every track?  Or does it only happen on the first track added to the play queue?  

It happens about 50% of the time when I simply tap on a track to play it.  It does not happen when the app is moving "naturally" through an album or playlist.  Strikes me as a buffering issue when it is asked suddenly to call up something new, but I know nothing about how computers actually work   Perhaps there is a setting within the program I could tweak?

 

In any case, it's not a deal breaker since it's far better than the music breaking off in the midst of a sublime movement and willy nilly skipping to the next track.  So far I have not had that experience with A+, but need to give it the full trial period.

 

[rickca]

2 minutes ago, sockpit said:

It does not happen when the app is moving "naturally" through an album or playlist.

OK that's what I expected.  So good, give it a workout and see whether you reliably get no skipping in the middle of a track.  If so, the problem has to be those other control points like Lumin and Kazoo.  That has been my experience.

[sockpit]

1 hour ago, rickca said:

OK that's what I expected.  So good, give it a workout and see whether you reliably get no skipping in the middle of a track.  If so, the problem has to be those other control points like Lumin and Kazoo.  That has been my experience.

Thanks much.  Will do.

 

 

[sockpit]

21 hours ago, rickca said:

OK that's what I expected.  So good, give it a workout and see whether you reliably get no skipping in the middle of a track.  If so, the problem has to be those other control points like Lumin and Kazoo.  That has been my experience.

 

Stuttering problem seems to have resolved itself.  I’ve experienced a few bugs and oddities, but A+ 3 has most of the kinks out.

 

So far, it hasn’t once skipped to next track.  But what has shocked me about this troubleshooting experiment is just how much richer the SQ is compared to the uRendu doing the rendering with Lumin or Kazoo as controller.  The change is as much as adding the LPS1 or another excellent LPS.  This tells me if I move to a streamer, it will really matter and I could end up losing SQ.  I assumed wrongly when I got networked with the uRendu I could move to lumin and leave A+ and my computer behind.

 

Currently:  small Topaz to JS-2 to LPS1 to uRendu to Exogal Comet to Exogal Ion to scansonic MB-2.5.  Exogal will soon launch a streamer build for Comet/Ion.  What to do . . .

[rickca]

@sockpit wow great, sounds like you have made a lot of progress with respect to reliability.

 

Let's have a look at your network connections, because they influence sound quality as well.  Is the uRendu just hardwired to your router?  Do you have a separate modem and router, or a combination gateway device?  I assume your Macbook Pro is just using wifi?  Do you have a switch just before the uRendu?  Are you just using the supplied SMPS with your network devices?

 

With Qobuz streaming, the network components are important ... not just bandwidth/reliability but also clean power.

 

 

 

 

[sockpit]

10 hours ago, rickca said:

@sockpit wow great, sounds like you have made a lot of progress with respect to reliability.

 

Let's have a look at your network connections, because they influence sound quality as well.  Is the uRendu just hardwired to your router?  Do you have a separate modem and router, or a combination gateway device?  I assume your Macbook Pro is just using wifi?  Do you have a switch just before the uRendu?  Are you just using the supplied SMPS with your network devices?

 

With Qobuz streaming, the network components are important ... not just bandwidth/reliability but also clean power.

 

 

 

 

@rickca, you are a real gentleman.  Thanks for all the help.  This is CA at its best.  

 

The uR is wired with a Blue Jeans cat6 that runs about 100 feet to the source of all my internet, a Google Fiber box that looks like this: https://support.google.com/fiber/answer/2667456?hl=en  Since Google provides my internet for free (because I'm in a guinea pig neighborhood in Calif.), I do not have the option of, say, upgrading the Fiber box.  It's part of their experiment on me.

 

It serves as my router and the digital hub for my wired LAN.  It uses a cheap SMPS, but it is on the other side of my condo far away from my listening room (and besides I thought the whole point of the uR using ethernet was to galvanically isolate my DAC from all the nasties).  Do I really need an LPS for that free black box? 

 

The google network box also feeds a computer next to it, my smart TV upstairs, and an older Apple Time Capsule (which also provides wifi throughout the condo)--all of them are wired by internal cat 5 wiring I had the electrician run in 2008 when I remodeled the place.  Glad I did.

 

Any things you can spot I need to attend to?  (Still no skipping going on!)

 

[rickca]

6 hours ago, sockpit said:

Any things you can spot I need to attend to?

You could introduce a Netgear GS105NA switch ($35) between your Google fiber network box and your uR, and ground the negative output of its SMPS.  This technique is called JSGT (John Swenson Grounding Technique) here on CA and is documented in John's posts in this thread https://www.computeraudiophile.com/forums/topic/37034-smps-and-grounding

 

This will block (shunt to ground) the high-impedance noise from the switch SMPS and the SMPS of all upstream network devices.  So you need JSGT only on the GS105NA switch.

 

Ethernet transformers do not block the high impedance components of leakage.  They are effective at blocking only the low impedance components.

 

 

 

[sockpit]

17 hours ago, rickca said:

You could introduce a Netgear GS105NA switch ($35) between your Google fiber network box and your uR, and ground the negative output of its SMPS.  This technique is called JSGT (John Swenson Grounding Technique) here on CA and is documented in John's posts in this thread https://www.computeraudiophile.com/forums/topic/37034-smps-and-grounding

 

This will block (shunt to ground) the high-impedance noise from the switch SMPS and the SMPS of all upstream network devices.  So you need JSGT only on the GS105NA switch.

 

Ethernet transformers do not block the high impedance components of leakage.  They are effective at blocking only the low impedance components.

 

 

 

Thanks much.  I could try this at three points: 1) just before the uR, but that puts the shunted switch on same circuit as my system; 2) just after the google fiber box on the other side of my condo; and 3) midway along the 100 foot long run of cable connecting uR and modem.  I’m able to do that because the cat 6 leaving the  uR is actually plugged into a wall socket halfway to the modem that, in turn is wired internally in the wall back to the goggle fiber box hub.

 

Any theoretical preference here?

[rickca]

22 minutes ago, sockpit said:

Any theoretical preference here?

John Swenson's answer below.  Note the Netgear GS105NA is one of the few switches John actually tested to confirm it works.  Don't just buy any old switch even if you have another brand you usually prefer.

 

Note also use ports 1 and 5.  Do not use adjacent ports.

 

This also means that if you use one of the above switches, there is no leakage current going through the "output" Ethernet Cable so there can be no radiation from the leakage, because there isn't any leakage going through the cable.

 

This also means that if you do use one of these switches to block leakage it should probably be somewhat far away from the audio system. If the switch is right in the rack with your audio stuff the cable going to the rest of the network can be radiating noise into your audio equipment. If the switch is further away, the only Ethernet cable near the audio equipment is the one without leakage.

 

[nbpf]

On 1/5/2018 at 12:59 AM, sockpit said:

My streaming setup frequently skips to the next track unexpectedly while playing, especially long symphonic movements.  I've little understanding of how any of this magic works, so let me describe my setup and perhaps someone will be kind enough to advise me about where the problem might lie.  It occurs often enough, once and hour perhaps, to just ignore. It's annoying to sit down to listen seriously to a 4 movement piece, and have it skip in the middle of mvmt. II on to mvmt. III  And it always skips to the next track, never over a track. Ah, it just did it again, this time listening to Keith Jarrett, so it's not a musical taste issue

 

Here's my setup:  

 

I stream Qobuz via Lumin or Kazoo (as controllers) and a uRendu (renderer) using its DNLA setting and the BubbleUPnP server program on the uRendu (to create an Open Home Renderer).  The DAC is an Exogal Comet for what it's worth.  The uRendu is hardwired by ethernet cable back to my Google Fiber box (plenty of bandwidth there!).

 

Observations:  It seems not to matter if Kazoo or Lumin app is the controller.  It skips to next track from both when it feels like it.  When I use the excellent Qobuz app as the controller and player via Shairport setting on the uRendu, the skipping does not occur.  

 

Some theories (from a guy who understands nothing about how the above work together):

 

1. The problem is at the source: Qobuz is sending a hiccup from its server.  Unlikely if its own app never skips?

2. The problem has to do with BubbleUPnP (doesn't seem widely reported so far as I've google, but I'm not much good at that either)

3. The problem has to do with DNLA uRendu (doesn't seem widely reported on this site)

4. The problem is with my ISP--Google Fiber is hiccuping or cutting out and skipping a track is a manifestation of that?  Just a wild guess.

 

That's about as scientific as I can get about it . . .   Assistance appreciated.  I could just use the Qobuz iOS app, but I'd prefer to avoid Shairport and use DNLA instead for SQ reasons.

 

Thanks!

 

Same problem here! I hadn't  noticed it so far since until now I have not used Qobuz streaming very systematically. But this evening I observed three jumps during about five hours of listening!

 

In my setup, the control points is Bubble UPnP. I think the problem occurs also under Linn Kazoo: my wife uses it under iOS and reported strange track jumps a few days ago. The renderer is upmpdcli running on a Raspberry Pi 3B+. The Pi is connected to a Naim DAC via an Allo DigiOne hat. I have no whatsoever problems with UPnP streaming but, as in your case, internet streaming via Qobuz yields occasional jumps to the next track. I have not tried streaming via Tidal. The jumps seem to occur towards the end of a track. The problem does not appear to be track specific: I cannot reproduce the jump by going back to the track from which the jump has occurred. I do not know which renderer is used in the ultraRendu but it suspect that it could be upmpdcli. This is an MPD front end and is OpenHome compatible. If the ultraRendu also uses upmpdcli, this is likely to be the culprit in my view. 

 

I will make some more tests and then post an issue on https://opensourceprojects.eu/p/upmpdcli/tickets/search/?q=!status%3Awont-fix+%26%26+!status%3Aclosed. I have used upmpdcli for about three years. The developer is very competent and supportive. He has solved the problems that I have reported very readily. Admittedly, these were not many: I have found upmpdcli to be very lightweight and reliable.

 

Let's hope to get the problem sorted out because I really do not want to rely on other solutions than upmpdcli for internet streaming. Thanks for finding out and reporting the problem in the very beginning! 

 

   

[rodrigaj]

@nbpf

It happens using Tidal as well. I am using an ultraRendu in MPD/DLNA setup that is streamed with a dedicated mac mini on the network.

 

Thanks for the posting.

[rodrigaj]

@nbpf

I should also note that I am using A+ 3.2.7 and not OpenHome.

[sockpit]

So I don’t understand this stuff at all, but I can report that my Qobuz streaming to mRendu using Lumin as controller skips quit regularly usually in long tracks. This is so regardless of whether the open home renderer is the bubbleupnp program on the mR or the one on my laptop.

 

But when I use A+ 3.latest and send it to mR’s DNLA output from there, it does not skip ever. 

 

This and @rodrigaj observation above, suggests that the problem isn’t Qobuz specific.  @nbpf appears to be an android user, which suggests that it’s not a controller issue, so I’d like to invite @vortecjr to take yet another look at the issue dscussed in this thread.  

 

The skips are annoying and I wonder if the software in the mR and uR is able to keep up with the demands.  But again: I haven’t any technical expertise so forgive me if the logic is leading me astray.

[Cebolla]

11 hours ago, nbpf said:

 

Same problem here! I hadn't  noticed it so far since until now I have not used Qobuz streaming very systematically. But this evening I observed three jumps during about five hours of listening!

 

In my setup, the control points is Bubble UPnP. I think the problem occurs also under Linn Kazoo: my wife uses it under iOS and reported strange track jumps a few days ago. The renderer is upmpdcli running on a Raspberry Pi 3B+. The Pi is connected to a Naim DAC via an Allo DigiOne hat. I have no whatsoever problems with UPnP streaming but, as in your case, internet streaming via Qobuz yields occasional jumps to the next track. I have not tried streaming via Tidal. The jumps seem to occur towards the end of a track. The problem does not appear to be track specific: I cannot reproduce the jump by going back to the track from which the jump has occurred. I do not know which renderer is used in the ultraRendu but it suspect that it could be upmpdcli. This is an MPD front end and is OpenHome compatible. If the ultraRendu also uses upmpdcli, this is likely to be the culprit in my view. 

 

I will make some more tests and then post an issue on https://opensourceprojects.eu/p/upmpdcli/tickets/search/?q=!status%3Awont-fix+%26%26+!status%3Aclosed. I have used upmpdcli for about three years. The developer is very competent and supportive. He has solved the problems that I have reported very readily. Admittedly, these were not many: I have found upmpdcli to be very lightweight and reliable.

 

Let's hope to get the problem sorted out because I really do not want to rely on other solutions than upmpdcli for internet streaming. Thanks for finding out and reporting the problem in the very beginning! 

 

   

It's possible that the Sonore 'Rendu devices are using upmpdcli  to provide the UPnP renderer, as they are mpd based. However, upmpdcli would presumably be set in standard UPnP mode only, so not in its recommended OpenHome mode. This is because Sonore have always recommended the use of the BubbleUPnP Server helper application to provide the OpenHome renderer for their devices, even including an optional internal BubbleUPnP Server app for this purpose.

 

Therefore connection to the online music streaming services would be different:

- the BubbleUPnP Server OpenHome renderer connects to TIDAL & Qobuz using OpenHome Streaming Services. OpenHome Streaming Services is also supported by most OpenHome control points (eg Lumin, Linn Kazoo, BubbleDS Next, BubbleUPnP Android app, etc) and access to TIDAL & Qobuz is provided via dedicated sections of the user interface;

- upmpdcli uses its own method for accessing TIDAL, Qobuz & Google Music, supplying UPnP media servers for that purpose. These 'special' TIDAL, Qobuz & Google Music UPnP media servers can be accessed by any UPnP renderer on the network, not just the upmpdcli renderer. It also means they can be used by standard UPnP control points, as well OpenHome control points, appearing as a normal UPnP media server.

 

It's quite likely that the BubbleUPnP Android app uses a very similar method of staging the online music service streams that the BubbleUPnP Server uses (both are developed by Bubbleguuum), so would be another thing to consider as to why the upmpdcli renderer skipping.

How were you accessing Qobuz on the BubbleUPnP Android app,  ie, via BubbleUPnP's dedicated Qobuz section or via the upmpdcli Qobuz UPnP media server?

 

Are you certain the skipping issue with the upmpdcli renderer was also occuring with the Linn Kazoo app?

Are you using upmdpcli's Qobuz UPnP media server with the Linn Kazoo app?

 

 

[nbpf]

@rodrigaj, @sockpit Thanks for the clarifications. I am using both android and iOS control points but mainly BubbleUPnP and therefore android. The other control point is Linn Kazoo that I use both under android and under iOS. According to what has been reported so far, I suspect that in my case the culprit could be upmpdcli. I am running more extensive tests before opening a ticket. This morning I have tried Qobuz streaming to upmpdcli using the Qobuz interface built into BubbleUPnP (instead of using the Qobuz interface of upmpdcli): no skips so fat but I have been listening for only about one hour. On another track: are you running instances of BubbleUPnP Server (not the BubbleUPnP control app) in your LAN? Is so, could you please stop them and check if the problem persists? Thanks, nbpf

[Cebolla]

So, are you saying  that all skipping by the upmpdcli renderer thus far have been via it accessing the upmpdcl-qobuz UPnP media server?

 

This would imply that BubbleUPnP is unlikely to be the culprit, so I would agree with your suspicion of upmpdcli.

[nbpf]

13 minutes ago, Cebolla said:

...

How were you accessing Qobuz on the BubbleUPnP Android app,  ie, via BubbleUPnP's dedicated Qobuz section or via the upmpdcli Qobuz UPnP media server?

 

Are you certain the skipping issue with the upmpdcli renderer was also occuring with the Linn Kazoo app?

 

Are you using upmdpcli's Qobuz UPnP media server with the Linn Kazoo app?

So far I have only be using the upmpdcli Qobuz UPnP media server. I am not a frequent Qobuz user but I was checking that the upmpdcli Qobuz UPnP media server supports gapless replay for another user and I ended up in a long Qobuz streaming session. This is how I ran into the track skip problem.

 

I am not certain to have already experienced the skipping issue while controlling the upmpdcli Qobuz UPnP media server via Linn Kazoo myself. But my wife has reported random track jumps. She uses Linn Kazoo in iOS to control the same upmpdcli Qobuz UPnP media server.

 

This morning I have tried using the Qobuz interface built into the BubbleUPnP control point app (instead of the upmpdcli Qobuz UPnP media server) to stream Qobuz contents to the same upmpdcli instance. So far I have experienced no track skipping after more than one hour of listening. I will run more tests and report back but for the time being I suspect an issue in the upmpdcli Qobuz UPnP media server.

 

I have an instance of BubbleUPnP Server running on a LAN device. This is only used to make a Chromecast Audio device accessible as an OpenHome renderer for Linn Kazoo control points. I will try to check whether this instance of BubbleUPnP Server has any influence on the track skipping problem.

 

 

[nbpf]

5 minutes ago, Cebolla said:

So, are you saying  that all skipping by the upmpdcli renderer thus far have been via it accessing the upmpdcl-qobuz UPnP media server?

Yes, I can confirm this. Best, nbpf

[Cebolla]

Then it would be very useful for Sonore to confirm if they are using upmpdcli or not.

 

Looks like you might have cleared up the mystery!

[nbpf]

4 minutes ago, Cebolla said:

Then it would be very useful for Sonore to confirm if they are using upmpdcli or not.

 

Looks like you might have cleared up the mystery!

Agree, I will run some more tests over the weekend and, if nothing new shows up, post an issue report on https://opensourceprojects.eu/p/upmpdcli/tickets/. Perhaps users of Sonore devices could try to clarify with Sonore whether their OS relies on upmpdcli or on some other renderer.

 

Streaming Qobuz through the Qobuz interface of the BubbleUPnP control app (to upmpdcli instances) seems to work flawlessly. Thus, a workaround for users of Android mobile devices is to use BubbleUPnP as a control point instead of Lumin, Linn Kazoo, etc. This obviously does not work on iOS devices.

 

I hope that we will be able to sort out the problem and have it fixed very soon. Best, nbpf 

[sockpit]

@nbpf  Thanks for putting time into this, esp. since it's not your preferred route to streaming.

 

"Perhaps users of Sonore devices could try to clarify with Sonore whether their OS relies on upmpdcli or on some other renderer."  

 

I'm going to ask @vortecjr to revisit the developments you opened up above, since I haven't a clue how this magic works.  I just know to work it.

 

For what it's worth, I want to repeat that using BubbleUpnP as the Open Home renderer installed on my networked MacBook Pro resulted in skipping (alway to the next track, never elsewhere) just as it does when using the BubbleUPnP Open Home app that comes with Sonicorbitor, the mR and uR's software.

 

So far, A+ streamed to mR's MPD/DNLA output does not skip, and it sounds sometimes slightly better.  But there are time one just wants to leave one's computer out of it, out of the room, out of one's life.

[nbpf]

Could all those who have experienced track skipping problems confirm that they are not running any BubbleUPnP Server process in their LAN or try to stop those processes? Since I have stopped the only BubbleUPnP Server that was running on my LAN, I have been steaming from Qobuz using the upmpdcli Qobuz UPnP media server running on a Raspberry Pi 3B+ for about 6 hours without any glitches. I will run more tests tomorrow and report back but, for the time being, it is not completely clear that this is  a problem of the upmpdcli UPnP media server. It could be caused by a BubbleUPnP Server process. Best, nbpf