I agree, Mosiac works fine for me and I have Minimserver installed on my Melco server.
Cheers, Mike.
As it happens, I have a Roon on order but until it arrives I still have to deal with the problem. In particular, why would one piece of music play back at the wrong frequency and speed!
Hmm – no router involved - all my wired devices inside the house are connected together using high end Trend-Micro 1Gb Switches.
If there was a problem with those switches (say), then this stuff (and other uPNP devices) would be failing all the time – but trying again this morning, the Bartok connected to my Synology with no problem - continues to work fine.
In any case, I’m far more concerned about the problem where the Bartok started playing one stream (and only one stream (from Tidal) with the old “chipmonk” effect
Some years ago I did have some similar sounding issues using a PC and Qobuz. It turned out to be some weird quirk with 24/192 files playing within a WASAPI session. Switched to ASIO and the problem disappeared. Not that this would necessarily have any direct relationship to your particular problem but I am giving it as an example to indicate that the problem may have occurred at some point well away from your dCS product.
Could be - except that power-cycling the dCS fixed the problem.
I’m suspecting that the issue is related to the dCS not properly handling different sample rates.
I’m deeply aware of this kind of problem as we see a similar issue with people who use our software (plugin host for performing musicians) at the same time as another product where one is configured at 44.1k and the other is at 48k. In that scenario, the pitch is off by about 1 semitone.
The Tidal sources were at 44.1k with MQA but the Qobuz source (same piece of music) was at 96k and it was after I switched back to the Tidal source that the problem occurred. The 96k is just a bit over double that of the 44.1k and misinterpreting the sample rate would absolutely cause this issue.
I had similar problems for a while, David:
Haven’t had them for some time though. Not sure whether it was a network change I made (link below) or something else.
1 Like
Given the history of dCS as well as their contribution to the protocols for the distribution of hi-res music data I think that this is unlikely. Ben’s linked history of his similar problem supports my expectation that this will turn out be some kind of network problem. Maybe @Anupc ( see Ben’s second link) will contribute to this thread when the time in his zone is suitable.
I had a similar situation and the music was playing twice as fast. Resetting Bartók with the switch on the back helped. I use Minimserver on Qnap NAS and Mosaic to select music. I was not able to repeat this problem. I wonder if this has nothing to do with the upsampling mode. The problem occurred after switching from DSD to DXD upsampling.
FYI, similar to your issue, I once had an issue with Qobuz music playing too fast on a non-dCS DAC through Roon and USB. Just restarted everything and problem solved. I’ve only seen this issue the one time.
Between the two incidents, my assumption is that it’s a streaming issue, or a hiccup with the services/app chain (and possibly devices).
Hmm, I read through it - it doesn’t really support that theory.
I’m not aware of any network mechanism that would explain how just one piece of music can play at twice the rate and an octave (or so) higher while everything else plays properly whereas I can easily imagine how a cached stream of data could get interpreted wrong if the system doesn’t have the correct sample rate for that cached stream. (I’m not saying that’s the issue, just noting a more likely possibiity — Occam’s Razor and all that!)
If same the piece continued to be played wrong after resetting everything then I would suspect that wrong meta data was being received (therefore an issue with the provider) but it played perfectly fine after a reset.
Yeah, I have 40 years of software experience as well but somehow bugs still manage to get into my software!
I know exactly what you’re referring to, and as others have said, it’s highly likely to be network-related. I had several UPNP players before my dCS and they all eventually encountered an issue like you describe, requiring a reboot of the player. Rest assured, it’s not you or your Bartok.
If rebooting the player fixes the problem, why exactly is the problem not the player?
The player will perform a new network discovery upon reboot, something it doesn’t routinely perform once established.
I must apologize, I completely glossed over your second bullet point. I don’t see how that can be network related. But the 1st one can and almost always is.
Though I did not have exactly this kind of problem but had different kind of network issues in my setup and then I found somewhere that disabling IPV6 in Internet would help. I did that and since then my setup runs smooth.
Yes, I understand that, but if you request uPNP and there’s nothing there (although not clear why something wasn’t there!), it should retry network discovery at that point. Hence I view this as, if not a bug, then a missing “feature” 
My fault - I should have reported these separately.
No idea but probably shouldn’t be too concerned unless it is a recurring problem. Once you get Roon you’ll most likely be so happy you’ll forget any of this ever happened.
David, almost universally, problems associated with UPnP Server/Client visibility has do with the home network not properly passing Multicast traffic. Even when the Bartok is working properly, if your network occasionally gobbles-up multicast packets, things won’t work properly, so, you might want to double check your Ethernet Switch configuration to be sure it’s not filtering out multicast packets (usually based on IGMP Snooping or Proxying).
Agreed. Your double-speed playback problem is highly unlikely to be (home) network associated. A quick Google search seems to show others with non-dCS DACs having the exact same problem. Tidal seems to be a common factor in most cases, even via Roon, here’s an example;
A Bartok reboot “solving” the problem doesn’t automatically point to a problem with Bartok (especially considering some of us have had the Bartok for over 2 years without ever encountering this problem ).
2 Likes
Hmm, I’m using TrendNet 24-Port Gigabit switches but IGMP is disabled. I have quite a few zero-conf devices on my LAN. I’ll keep an eye on this though. On the other hand, it would be nice if the Bartok would let me manually define the IP address for a media server so that it doesn’t have to rely on uPnP to find it.
It doesn’t definitely prove it — but presumably the Bartok (and other streamers) have to know how to decode incoming data from Tidal. If the problem was due to a faulty Tidal stream, then I would not expect rebooting the Bartok to fix the problem as the incoming data stream would presumably still be faulty.
Obviously I don’t know why it happened - nor is it my responsibility to debug the problem - I simply don’t want to experience it!
Which model if I may ask? (By the way, TRENDNet is not Trend Micro - two very separate companies 
).
Generally I would say you’re right. That said, there’s a significant amount of “chatter” that goes on between the Streaming services and the DAC, it’s very easy for things to go haywire occasionally.
ps: I just noticed you used the plural;
Are your Bartok and UPnP Server on different LAN segments?