Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gulp]

When I put my finger on a track to play it (JRemote on iPad, network cable to DLNA connected streamer and to the JRiver PC), reaction time is partly fast but more often quite slow (a few seconds reaction time).

I tried different DLNA controller settings but none really helped.
Network speed is fine, Wi-Fi connection for the iPad, too, no other network consumers responsible for any network load.

Is there another idea what I can try?

[JimH]

Press or long press?  They're different.

[gulp]

short press, just to play instantly. When I press long and chose play now from the menu it’s the same. Sometimes fast, often slow.

The touch reaction of the iPad is not the problem, it’s the signalprocessing to and in JRiver.

[murray]

Is this the same as what I have had for a very long time. When I go to start a film from theatre view more often than not the film always starts but many times its without audio. If I stop the film and start again I get picture and sound. I bitstream.

[gulp]

I guess it has to do with the renderer and JRiver (I just speak of music), at least with Roon I have no problem at all, very fast all the time, so it can’t be a network problem.

[gulp]

I meanwhile checked if it’s an issue of JRemote to JRiver or JRiver to streamer and it’s the latter. When selecting a song from JRiver it’s as unreliable in reaction time as from JRemote.

As I said, using Roon, there’s never delay, so no network or general streamer topic. Any ideas?

[JimH]

Roon uses a different protocol.  What you're doing may not be supported by DLNA.  Try converting to a different format or lower bitrate. 

[gulp]

It’s the same reaction for CD or highest resolutions, no difference there. Here and there it reacts immediately, more often it takes 2-4 seconds until a song plays. It may be a current bug of the streamer firmware with DLNA, but it’s confusing that the reaction time varies.

[gulp]

It’s the same reaction for CD or highest resolutions, no difference there. Here and there it reacts immediately, more often it takes 2-4 seconds until a song plays. It may be a current bug of the streamer firmware with DLNA, but it’s confusing that the reaction time varies.

Do you possibly have any clue what it could be from this log? I created it while switching between a few 16/44,1 tracks and each switch took 2-3 seconds until the next track played.

[JimH]

Are some files being converted on the server?

[gulp]

Are some files being converted on the server?

No, no on the fly conversion.

[zybex]

Memory Playback enabled?

[gulp]

Can you just help me what you mean by that?

In case I have no other config problems I’ll look into network problems which might just have effect for DLNA related protocol.

[zybex]

Tools -> Audio -> Settings : Memory Playback

If enabled, MC will pre-load an entire track/album in memory (and optionally decode it) before starting playback, potentially causing a delay.

There's also a "prebuffering" setting.
On the DLNA device settings, there's also a list of formats that are converted automatically before playing to that device. Are you sure it's not converting?

[gulp]

Thanks, as I use a DLNA device, my configuration is not under “audio” but in DLNA settings, so I have no memory playback or prebuffering setting and in DLNA settings I have no format conversion activated.

I now changed my iPad wifi setting to “use private wifi address” and “prevent tracking”, which usually makes more problems. Now it speeded things up. I have to check if it stays like this. I fear not, as I recently had the problems even when changing tracks on the JRiver PC…so it will be interesting how it develops. Thanks for the moment for your help.

Edit: it was part of the problem, but I still have a bit of it.

[gulp]

Unfortunately JRiver still doesn't work properly with the Converse streaming module CDM4140. Frequent but variable, on/off delays and hang ups when switching tracks.
Is there any way to properly analyze this?

[JimH]

Could you try a different device?

[gulp]

I have a parallel CDM210 module that works properly in this regard meanwhile after several JRiver and Converse bug fixes (but this combination partly has bugs with gapless).
Both work absolutely flawless with Roon (different topic, I know, but it means, there's no network problem).

Playing JRiver to an iphone directly also works flawlessly.

So I see the problem described here as a special one with this Converse CDM4140, but also as a special one with JRiver. The question is, how to make progress in analyzing. I tried all various DLNA controller options, option 1 is needed, option 2 improves the reaction topic a bit (not enough), but avoids gapless play, option 3 and 4 make no change.

Using JRemote or selecting tracks directly in JRiver make no difference. The problem lies in the way from JRiver to the Converse module.

[JimH]

Roon doesn't use UPnP / DLNA. 

[zybex]

The question is, how to make progress in analyzing.

Start a Wireshark capture and reproduce the issue. Then someone needs to analyze the capture to see what's happening.
https://www.wireshark.org/

Have you tried disabling/uninstalling any Internet Security product you may have? It may interfere with network functions.

[gulp]

Thanks. I uninstalled everything except Norton 360, but excluded the NAS folders and JRiver there.

Will get into Wireshark. I already attached a JRiver log here previously.

[Awesome Donkey]

My guess it's either software like a firewall, antivirus, etc. or it's on the networking level with the router, etc.

[gulp]

I will check. What speaks against it is, that playing from JRiver to an iPhone works flawlessly in the same configuration. There’s no further Antivirus etc. on router level, just on the PC where JRiver is installed.

[JimH]

Uninstall Norton.

[gulp]

Did it, unfortunately that didn’t solve it. Now I’ll see if I can make a wireshark log without purchasing.

[zybex]

Wireshark is free, click on "Get Started" on their page. Click on Donate if you want

[gulp]

I caught a short, representative moment luckily, switching between a few tracks, so if anyone can help and put an eye on it...?

Airlens IP *.53 is my streamer, SG-Tiny is the PC (JRiver is running on), QNAP IP *.72 is my NAS and JRemote is on my ipad with IP *.26 , Fritz.box is the router.

All components are connected by 20-50 Mbps performing connections.

How can I attach a 63.700 KB file here?

[zybex]

How can I attach a 63.700 KB file here?

Break it in 34 parts and make 34 posts 
You need to use some file sharing service.

[gulp]

Here it is 

https://we.tl/t-G4Ns9n81nj

[gulp]

Are there any secret DLNA controller options to use in special cases?

Not sure if anyone's able to see anything from my log...

[zybex]

I see 2 issues in the log.

1. Your files have an ID3 tag with a 3000x3000 cover. Your player loads the ID3 tag then seems to take about 2 to 3 seconds to process it and apparently runs out of memory (TCP receive window suddenly goes to zero, stopping the audio file download). Then it recovers and resumes downloading the audio file, and likely starts playing at this point.
 - Try playing a few files with no cover image in the tag, or at least with a much smaller cover (ie, 500x500). The startup delay may be proportional to the cover size. Does it even show a cover on the device screen for these files? (if it has one).
 - I see on the log that MC offers URLs to the cover in different resolutions, however that player ignores them and instead loads the ID3 tag which contains the full image. I don't think MC can do anything about that.

2. I see LOTS of TCP retransmissions, often just a few microseconds apart. This can be just a bad Wireshark capture, but it may also point to a networking issue. Run this command in a cmd prompt:
   netstat -s -p TCP
If the number of "Segments Retransmitted" is more than 1% or so of the "Segments Sent", there's definitely a problem. I see about 7% in this log. This would cause some slowness, but should not be noticeable for an audio player I think.

Some possibilities:
- Did you run some network "optimization" script on your PC, or change the default LAN card settings? If so, undo it all
- Is there some network filter/switch/"optimizer" in the path? If so try to bypass them temporarily
- temporarily disconnect as much gear from the network as possible, leave only the PC, NAS and Player (and connecting switch/router). I had some weird issues that went away after rebooting a stupid 5-port switch I wasn't even using...
- replace the LAN cables, connect the player to a different router/switch port
- update the LAN card driver, reset settings to default
- check if there's any QoS or rate-limiting option enabled on the router

My money is on 1. Your player can't handle large covers.

[gulp]

Thanks very much! There’s a lot to try.

What speaks against the cover art and maybe some other theories is, that the delays occur sporadically but frequently, but once the same track with the same cover loads fast, another time it loads slow and hangs.

What should also be considered is, which theories should be dropped due to the fact, that Roon plays always fine and reacts super fast.

[zybex]

I'm not familiar with Roon. Jim says it doesn't do DLNA, and the internet seems to confirm that. So it's playing using a different protocol, so perhaps the player is not loading any cover art with Roon. Does the cover show up with Roon? What about MC? (assuming your player has a display for covers...)

[gulp]

Roon and JRiver just load covers on the iPad, not on my streamer or DAC.

But what’s correct is, that the delay of playing the file is equivalent to the delay showing the cover in JRemote. The only problem…the same track can once play instantly and another time with 3-10 seconds delay or hang. Delay seems to happen more often when using the next button than when clicking on the next file, but I’m not sure about that. Choosing “disable set next“ controller option seems to improve delays temporarily, but then gapless is gone.

Another interesting observation is, that it sometimes seems like a buffer runs full. Several tracks after starting on a certain day play fine, then suddenly delays start and come and go, independent of the album played.

[zybex]

Try a playlist without any covers as I mentioned above. Then check the network issues. Also, reboot the player between test sequences.

It's possible that the player has some internal caching for ID3 tags/covers and it gets either full or corrupt. It's also possible that the internal storage/memory is damaged. From the log, the delay comes immediately after loading the ID3/cover tag, so it seems related - the player suddenly reports it's out of memory. Perhaps when the cover is already in the cache the player can start playing immediately.

Roon is not using the same protocol so it's likely not sending any cover, or sending a much smaller one. With MC/DLNA, it's up to the player to request the cover and handle it.

[gulp]

Thanks very much again! Due to my time zone I have to continue tomorrow and will report back.

[gulp]

Rarely even the old track keeps playing while the newly selected one already started after some delay. Sometimes it’s not possible to select a track of an album that started hanging…then choosing tracks from another album, sample rate or whatever helps to get reaction again.

[gulp]

My first feedback so far in bold (thanks so much again!)

I see 2 issues in the log.

1. Your files have an ID3 tag with a 3000x3000 cover. Your player loads the ID3 tag then seems to take about 2 to 3 seconds to process it and apparently runs out of memory (TCP receive window suddenly goes to zero, stopping the audio file download). Then it recovers and resumes downloading the audio file, and likely starts playing at this point.
 - Try playing a few files with no cover image in the tag, or at least with a much smaller cover (ie, 500x500). The startup delay may be proportional to the cover size. Does it even show a cover on the device screen for these files? (if it has one).

I will try this

 - I see on the log that MC offers URLs to the cover in different resolutions, however that player ignores them and instead loads the ID3 tag which contains the full image. I don't think MC can do anything about that.

2. I see LOTS of TCP retransmissions, often just a few microseconds apart. This can be just a bad Wireshark capture, but it may also point to a networking issue. Run this command in a cmd prompt:
   netstat -s -p TCP
If the number of "Segments Retransmitted" is more than 1% or so of the "Segments Sent", there's definitely a problem. I see about 7% in this log. This would cause some slowness, but should not be noticeable for an audio player I think.

My JRiver PC shows nearly 1% and my other Notebook even 2%. What can I do about that? Transmission rates are good...maybe ping is bad?

Some possibilities:
- Did you run some network "optimization" script on your PC, or change the default LAN card settings? If so, undo it all
No, not that I'd know

- Is there some network filter/switch/"optimizer" in the path? If so try to bypass them temporarily
No

- temporarily disconnect as much gear from the network as possible, leave only the PC, NAS and Player (and connecting switch/router). I had some weird issues that went away after rebooting a stupid 5-port switch I wasn't even using...
- replace the LAN cables, connect the player to a different router/switch port
- update the LAN card driver, reset settings to default
will try all of this

- check if there's any QoS or rate-limiting option enabled on the router
It's not

My money is on 1. Your player can't handle large covers.

[JimH]

I don't know if it was said above, but some devices have size limits for cover art.  Try playing a few files with 1000x1000 art.

[gulp]

- Try playing a few files with no cover image in the tag

I tried this now and up to those first experiences, it seems to be the problem. Files seem to load constantly fast without cover ( I have to verify on the long run).
I will check next up to what size it still works and will contact the manufacturer.

As those problems don't seem to appear with all programs but JRiver...is there any option in JRiver settings to influence cover image behavior? I would otherwise have to change cover images for more than 10.000 albums.

[JimH]

gulp,
To quote a reply, do this:

[ quote ]
Here's your answer.
[ /quote ]
I don't think so.
[ quote ]
Oh yeah?
[ /quote ]
Nope

But remove the spaces in the tags.  It then looks like this:

Here's your answer.

I don't think so.

Oh yeah?

Nope

[gulp]

I’m Sorry, no, it was an accidentally well running moment. I just now had the same delays without cover art as I had them with cover art. I have to keep on searching due to the segments percentage issue possibly.

There seems to be another reason for the delay and after that delay the cover art is loaded, no matter if present or not, big or small.

FYI:

I have a power over powerline network, too besides my normal Ethernet network, both are meshed. The Ethernet network has the high segments loss percentage, the network over powerline has not. Track switching Delays between both when JRiver is connected to either of them Aretha same. This speaks against the relevance of the segments loss topic.

Another thing I recognized is, as soon as I activate the disable setnext support controller option, the delays are gone for a few track switches, but come back later. Weird.

Is there a good documentation of the DLNA controller options anywhere? I didn’t find it so far.

Next thing I could try is to play local files from the JRiver PC instead of NAS…to see if we can exclude the NAS connection from the equation. But again: all those connections have high throughput rates. Not sure what else can play a role in connectivity for those play track reaction topics.

[gulp]

- replace the LAN cables, connect the player to a different router/switch port

I also moved JRiver PC and streamer to different network connections, but the problem traveled with them.

But: playing from JRiver to my iPad works flawlessly. This means, the problem just exists with the streamer and it means, network issues play no role for playing to the iPad. Doesn’t this look like an incompatibility in settings or bugs with this conbination? But how to find out what’s to do?

[zybex]

With DLNA protocol, the player/streamer is mostly in control - MC just gives it an URL and the player is responsible for downloading and playing it. The wireshark capture shows it's most likely an issue with the player.
When playing on the IPad there's no DLNA involved, it's MC/remote playing directly.

Does your streamer have internet access? Try to block it, either by removing its default gateway or blocking it in the router. Maybe it's doing some internet query after parsing the ID3 tag.

PS: not sure how you're removing the cover art from the tags, but make sure it's really removed. Some Tag editors (including MC) don't actually remove the art from the file, it's just marked as removed but it's still there. Make sure the file size decreases by a few hundreds KB when removing the cover art.

[gulp]

I will try blocking internet.

I ensured MP3tag removes the covers (it does).

The delay seems to be something that builds up and changes for the same track. It reacts fast for a few track changes and then gets slow for the same tracks it was fast before. Then when switching tracks further, it suddenly gets fast again inbetween and then slow again. Mostly it’s slow when continuing to switch tracks.

All this seems to exclude many of the assumptions unfortunately.

[gulp]

I blocked internet for the streamer on the router, but it didn’t help.

The one bigger test I still have to make is disconnecting all other network equipment except the music playing devices.

Another strange thing to observe is, that „repeat current track“ gets frequently activated although I don’t do that. It’s mostly active and I have to disable it, but it comes back occasionally. There seems to be something really wrong with compatibility of my JRiver with this Converse module.

[gulp]

zybex, it seems you’re the virtual JRiver employee of the year for me!

I went one recommendation further in your list (cutting all other network connections in the house than music) and bingo….my second NAS, which is working fine otherwise, caused the delays, whysoever.

I‘ll have a beer on your health this evenimg, thanks a lot again!

P.S.: the „repeat track“ function still does what it wants, but that’s a minor point now.

[zybex]

Nice, glad that you found it

I‘ll have a beer on your health this evenimg, thanks a lot again!

Cheers!

[JimH]

I‘ll have a beer on your health this evenimg, thanks a lot again!

I will join you.  Thanks, zybex!

[JimH]

It's possible that the problem NAS is using an IP address that another device is also using.