I posted on this issue in the firmware beta testing thread initially thinking it was related to a firmware update - i recreate the topic here as apparently it has nothing to do with the firmware.
The issue: after some playing time the streamer has buffering issues with high resolution files; the issue appears erratically (it may be hours or days before it kicks in) but once it does then it is persistent: music plays for a few secs, then buffers (i measured systematically 15 secs for 96kHz and 25 secs for 192kHz files)
the setup:
- VDSL modem wired to AirportExpress(1) with WiFi router duties.
- Another AE(2) 5 meters away in wireless receiver mode, wired to TP Link GB switch via 24AWG no name cable
- NAS (Seagate Central running twonky 7.2.8) wired via CAT6 24AWG no name cable to switch
- NDX wired to switch via CAT6a Furutech LAN 10-G Ethernet cable
already tried: the buffering problem is suggestive of the data stream "travelling" from the NAS to the router (and thus going wireless between the two AEs) and back rather than going the "local" (NAS --> switch --> NDX) route. I have already experimented with: restarting the NAS, restarting the switch (helped a lot, 12 hrs uninterrupted play but eventually we are back with the issue), replacing the switch (I have a same one in the study) - i am finally now replacing the ethernet cable btw NAS and switch, test in progress)
If anyone has had a similar issue it would be great to share how it was resolved, otherwise ideas are most welcome!
Posted on: 07 January 2016 by IanG
Please let us know how you get on. I have the same issue.
I usually use Minimserver transcoding FLAC to WAV. When I get the issue (which is far from all the time) I switch to Twonky streaming FLAC.
Ive always thought the issue is a network one and reducing the bit rate relieves the issue but I would be interested to see if Naim think its a firmware or hardware issue.
Posted on: 07 January 2016 by DrPo
Well I am relieved someone else has seen it too. It's not a NW issue as it persists when the n/w connection to the switch is stopped (posts above in this thread). Simon's explanation seems plausible, I have raised the topic to NAIM support today. No idea how to make the NW trace though, as my switch is unmanaged a trace route command I tried showed only one "leg" which was not helpful...
Posted on: 08 January 2016 by Simon-in-Suffolk
DrPo, you would need to use a network hub if you don't have a switch capable of port mirroring and a tool such as WireShark to capture the data packets and their timing running on a PC or Mac.. If this all sounds double Dutch then I wouldn't worry about it. Traceroute is not relevant.
Simon
Posted on: 29 February 2016 by DrPo
short update (no, it ain't over yet...): NAIM has very patiently tried to help find the root cause over the past weeks, we are using Wireshark to analyze the traffic after NAIM shipped me a network hub... still work in (slow) progress. Irrespective of the resolution I am already grateful for the attention and support by NAIM.
Posted on: 29 February 2016 by Simon-in-Suffolk
Do you find with the hub installed your buffering increases? If yes I suspect the issue is your with media server or network.. If not I suspect the issue is with your streamer. You see hubs slow speed of the network down in both directions..WireShark will also show the timing of the TCP so you can see if the receive window is getting starved.. or server resends due to delayed responses.. Again suggesting media server or Network
Have you have tried a different media server on a different platform and temporarily using wifi?
if it's timing related I am afraid hubs being used to share the data for sniffing can distort the layer 2 behaviour and timing.. but Naim will be aware of this as it could mask the issue... The alternative is to use a managed switch that can support port mirroring/spanning... It's what I use here for TCP diagnostics and timing measurements on my Naim streamer... Perhaps Naim can ship one of those to you if still no success.
Simon
Posted on: 29 February 2016 by Mike-B
Further to Simon's note & going back our exchange today on the other thread on your NAS file/folder problems ............ & also going back in this thread where you played from a USB for a long period without buffering issues, but get buffering when playing from your Seagate NAS. So to repeat what I said a while back ...... It handles HD (24/192kHz) data from a USB stick so that proves its not the NDX & leaves the problem firmly somewhere in the network. You've replaced the switch to no effect, ditto the ethernet patch leads, now you've installed the Naim network hub, so my logic brings it back (again) to the NAS. You need to do something with that Seagate.
Posted on: 29 February 2016 by DrPo
@Simon, the incident is much rarer now with both the n/w hub and the switch on the network; that added to me being most of the week away on business trips has made the progress very low. I don't have any spare "alternate" NAS at hand to try the obvious. You are spot on re. the findings of the wire shark. I cannot make any sense out of them but NAIM support have indeed noticed a peculiar behaviour with the window timing which we are now comparing between firmware versions.
@Mike, you have a good memory:-) yes, I have decided to do something about the NAS. Debating between QNAP ts-251 or Melco N1A. However at this point both NAIM support and I are keen on understanding whether there is indeed any firmware dependence here which would be good to know.
Posted on: 01 March 2016 by Arnk
For what this is worth, I can consistently create dropouts by placing my network cable immediately next to one of my large AC adapter bricks. Whether it is the uniti-server or my firewall or roku AC brick. When the network cable is on the brick or very close proximity I get dropouts. When I move the network cable away from the brick the dropouts go away. This would,be consistent with electrical interference disrupting the packet flow.
Also, in a different instance I ran simple ping tests against every device on a friends network and discovered a bad wifi access point was reaulting in amazingly high latency numbers. Replacing that wifi access point eliminated the dropouts.
