Print

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

[mattlovell]

JRiver MC19 (specifically, 19.0.163) seems much better able to "track" the currently-playing song on the receiver than does MC20.  I have basically the same DLNA server setup (Always convert, LPCM16) on both.

Arrggg... too many options!

The two servers weren't quite identical.  Once I got MC20 setup the same as MC19, the "very delayed track change" from GetMediaInfoResponse, GetPositionInfoResponse, and even the receiver's on screen display went away!  (I had the PS3 compatible option set under MC20, as part of a seemingly never-ending chain of experiments).

It's fascinating to me that Renderer behavior can be affected so much by what the Control Point is doing!

[mattlovell]

It's fascinating to me that Renderer behavior can be affected so much by what the Control Point is doing!

Experimenting further, and avoiding the 10sec window Bob mentioned in an earlier post, the noise/stutter upon pushing a track and playlist change is also gone!  I swear I had tested things all this set of DLNA server options previously, but I guess not.

[mattlovell]

Any declared victory on this topic, of course, must eventually be qualified or retracted...

Here are my current DLNA server settings:

• Specified output format
• PCM L16 No Header
• DLNA
• DLNAExtra
• Include session ID

Eventually, with normal playback of Track 1 from Queen of the Clouds (the 6-second track mentioned earlier in this thread), JRiver and the Yamaha got "off" regarding what was played.  The first time playing through that track and its successor, no problem occurred.  Sometime later, though, it cropped back up.  Noticing that the on-screen display of the playing track was incorrect (but >10 second into the new track), I then tried pushing a new track out.  Sure enough, the initial static/stutter occurred again!

When the next-track info was accurate between JRiver and the Yamaha, everything was working without issue.  Somehow, though, the two got off from one other.

I wonder whether AndrewFG's suggestion, earlier in this thread, to do a SetNext of (nul) at some point (perhaps when Stop is issued) would be appropriate after all.

[mattlovell]

When the next-track info was accurate between JRiver and the Yamaha, everything was working without issue.  Somehow, though, the two got off from one other.

I wonder whether AndrewFG's suggestion, earlier in this thread, to do a SetNext of (nul) at some point (perhaps when Stop is issued) would be appropriate after all.

It's something about transcoding to PCM (at least PCM L16)...

The Yamaha renderer accepts MP3 natively.  If I modify the DLNA server to convert to PCM L16 only when needed, I can play gaplessly with correctly-indicated track transitions, and push new playlists to the renderer, without ever hearing any static or stuttering.  Sending a sequence of MP3s to the receiver in this fashion, SetNext works great!

Pick an m4a file (from recent iTunes purchases) or an ogg vorbis file (or, presumably, anything that requires conversion to PCM), however, and both the next-track indication gets "off" from actual playback and the static/popping makes an appearance.

("Always convert" or "convert when necessary" was one of the differences between how I had MC19 and MC20 setup.  MC19 was setup to only convert when necessary.)

I want to do more experimenting tomorrow, and see if the problem still occurs with PCM 16 with headers.  I'll post what I find out.  (Perhaps the header information within the MP3 files is being used by the Yamaha renderer?)

Does this make sense at all?  More work is required at the DLNA server for transcoding to PCM, of course, but I've never heard any gap or problem during playback, outside of the track transition. 

[AndrewFG]

^

You mention seeing a Stop command in your logs. Normally in the Set / Play / SetNext (repeat) sequence there should not be any Stop commands (nor indeed should there be any Seek commands). Are you doing anything additional that would cause Stops or Seeks to be sent??

[AndrewFG]

^

Bob, I wonder if this could be a caching issue in the renderer? I think MC always provides the exact same url whenever calling Set or SetNext for the same track. So perhaps the renderer tries to satisfy part of its GET from cache, and perhaps it has a bug stitching together the cached results and the new GET results e.g. causing a frame alignment error similar to what you described in your Seek case.

In my DMRA I provide always a different url each time I call Set or SetNext even for the same track, in order to prevent any such caching; I prepend a fixed length prefix of random characters in the url, and chop off that prefix when the GET comes in. That way the renderer always thinks it is downloading a new track, even when MC is actually serving the same track again. And just to make sure, I set the no-cache HTTP header in the GET response too.

[mattlovell]

AndrewFG asked:

You mention seeing a Stop command in your logs. Normally in the Set / Play / SetNext (repeat) sequence there should not be any Stop commands (nor indeed should there be any Seek commands). Are you doing anything additional that would cause Stops or Seeks to be sent??

JRiver MC always seems to issue a Stop, SetAVTransport, Play sequence whenever one changes the playlist.  I believe Bob mentioned in an earlier post that they never issue Stop for "normal" track changes. 

I have never observed a Seek (and am never directly specifying that playback start anywhere but at the start of a new track).

Just to repeat one tidbit, I've never heard the static/stutter when the renderer is just progressing from track to track (independent of whether files are being streamed natively or a forced conversion to PCM L16 is occurring).  The only time the static/stutter happens is when establishing a new (albeit 2-entry long) playlist via SetAVTransport and SetNextAVTransport.  Oddly, the static/stutter happens even if the renderer is currently Stopped.

Bob, I wonder if this could be a caching issue in the renderer? I think MC always provides the exact same url whenever calling Set or SetNext for the same track. So perhaps the renderer tries to satisfy part of its GET from cache, and perhaps it has a bug stitching together the cached results and the new GET results e.g. causing a frame alignment error similar to what you described in your Seek case.

I think it is accurate to say that the same URL is always used in reference to the same track.

[mattlovell]

I want to do more experimenting tomorrow, and see if the problem still occurs with PCM 16 with headers.  I'll post what I find out.  (Perhaps the header information within the MP3 files is being used by the Yamaha renderer?)

With PCM 16 (Header present) and m4a files, the problem still occurs.

I cannot use PCM 16 conversion for Ogg Vorbis, for then I run into my other problem, namely

   Streaming ogg vorbis files using audiophile DAC DLNA server
   http://yabb.jriver.com/interact/index.php?topic=92655.0

The initial static/stutter also occurs with conversion to MP3 High Quality, so at least that part of my latest hypothesis is consistent.

[bob]

I am not sure how Seek would be involved in a SetNext scenario. However assuming that is the case, you need to keep in mind that if MC sends a time based seek, and the renderer converts it to a byte range seek, it will need to have either the bitRate or the file size and track duration. If MC provides a bitRate then byte seek offset = (time seek offset x bitRate). If MC provides a duration and filesize then byte seek offset = (file size x time seek offset / duration). Where, in both cases the renderer must round down to the nearest frame boundary. In either case, its hard to see how MC might be to blame for the renderer seeking to the wrong position.

Perhaps one thing that MC could do though, is in the case that it receives a seek that is not aligned to a frame boundary, it could perhaps force a frame alignment anyway. But there is perhaps then a risk of breaking interoperability with renderers who intentionally send non aligned seeks and have the smarts to align things internally. In that case both MC and the renderer would be being too smart for each other...

From what I understood there is no issue if he just lets a playlist play.

I'm starting to lose track of the permutations of this testing and can only devote so much time to it.
Andrew, I agree with your assessment of the seek situation. Since I believe he has the bitrate on by default the renderer is getting all three pieces of information you mentioned.
I can't see why it would be terribly important if the seek wasn't 100% perfect as long as it was on a sample boundry which it appears to be in my testing case anyway.
That's why I thought it might be more likely to have to do with the "missing" wave header for the seeked part of the wave file.

[bob]

Bob writes:
That is an interesting difference but, like AndrewFG, I'm not sure how a Seek command would be involved.  I haven't seen one while examining network traces from the playlist change; all I've seen is Stop, SetAVTransport, Play, then one invocation of your [ GetPositionInfo, GetMediaInfo, GetVolume, GetMute] loop, then SetNextAVTransport.

It may not be fruitful, but I was wondering about the timing of the Play command when JRiver has transcoding to perform.  When does the transcoding get started, when JRiver "knows" about the push+play it's about to issue or only after the HTTP GET from the renderer?  Just curious if there was a race condition there.

FWIW, Yamaha did recently release firmware 1.60 for their Aventage series receivers (bumping up from version 1.44).  I've upgraded, but noticed no difference in behavior as a DLNA renderer.  Sound continues to be excellent, and normal track-to-track progression happens without issue (other than GetPositionInfoResponse and GetMediaInfoResponse taking a while to "catch up" to what's currently being played).

It doesn't start transcoding until it receives the file request.

[bob]

^

Bob, I wonder if this could be a caching issue in the renderer? I think MC always provides the exact same url whenever calling Set or SetNext for the same track. So perhaps the renderer tries to satisfy part of its GET from cache, and perhaps it has a bug stitching together the cached results and the new GET results e.g. causing a frame alignment error similar to what you described in your Seek case.

In my DMRA I provide always a different url each time I call Set or SetNext even for the same track, in order to prevent any such caching; I prepend a fixed length prefix of random characters in the url, and chop off that prefix when the GET comes in. That way the renderer always thinks it is downloading a new track, even when MC is actually serving the same track again. And just to make sure, I set the no-cache HTTP header in the GET response too.

That it could be a caching issue is an interesting idea.
I'll play around with that a bit with the Raumfeld.

[bob]

Any declared victory on this topic, of course, must eventually be qualified or retracted...

Here are my current DLNA server settings:

• Specified output format
• PCM L16 No Header
• DLNA
• DLNAExtra
• Include session ID

Eventually, with normal playback of Track 1 from Queen of the Clouds (the 6-second track mentioned earlier in this thread), JRiver and the Yamaha got "off" regarding what was played.  The first time playing through that track and its successor, no problem occurred.  Sometime later, though, it cropped back up.  Noticing that the on-screen display of the playing track was incorrect (but >10 second into the new track), I then tried pushing a new track out.  Sure enough, the initial static/stutter occurred again!

When the next-track info was accurate between JRiver and the Yamaha, everything was working without issue.  Somehow, though, the two got off from one other.

I wonder whether AndrewFG's suggestion, earlier in this thread, to do a SetNext of (nul) at some point (perhaps when Stop is issued) would be appropriate after all.

There's no reason to include a session ID, that option is for old legacy upnp devices.
The only other option you might want to use is the bitrate. This depends on proper support of that by the renderer and there are a lot of buggy implementations out there that scale this value improperly.

[mattlovell]

I'm starting to lose track of the permutations of this testing and can only devote so much time to it.

Perfectly understandable!

I'll try to provide a quick summary, eliminating my various false starts and avoiding discussion of my other Ogg Vorbis issue:

• SetNext does nominally to work, as the player can progress from track to track without a gap, however...
• Initial static/stuttering occurs when pushing a new playlist (well, 2-entry list) to the renderer.  This initial static occurs only for the new, just-selected track starting the playlist and lasts a varying amount of time (fraction of a second to roughly 2 seconds).
• The initial static does not occur if JRiver is serving up native mp3 files (with no conversion/transcoding).  Those play gaplessly and I can push playlist changes till I'm blue in the face without any audible hiccup of any sort.
• Instead, the initial static occurs when JRiver's DLNA controller is setup to convert to PCM L16 or PCM 16 or MP3.  Perhaps interestingly, even MP3 files converted to high-resolution MP3 (with the Server set to "always convert") then display the initial static woe.  Thus my declaration in a recent post that the problem seems related to transcoding.
• The initial static can occur even if the rendered is Stopped when the new playlist is pushed out.

Of course, no issue ever crops up if SetNext is disabled altogether.  So, it's definitely a required part of the recipe for the problem.

Using a wired ethernet connection didn't help the problem at all.  Windows does show a jump in network traffic when a playlist push is occurring, jumping from nominally 2 Mbps during normal playback to a spike of about 10 Mbps.  Once normal playback gets re-established, network traffic goes back down to about 2 Mbps.  (For stereo 16-bit PCM at 44.1kHz, I would expect network bandwidth of 1.41 Mbps plus TCP/IP framing overheads, so 2 Mbps seems about right.)

FWIW, the manual for the Yamaha RX-A1040 explicitly claims support for gapless playback from WAV, FLAC, and ALAC files.

Edit: fixed typos, added details from Yamaha manual, and add PCM 16 (with headers) to list of transcodings with woe.

[mattlovell]

Adding to my last post...

   ... the initial static occurs when JRiver's DLNA controller is setup to convert to PCM L16 or PCM 16 or PCM 24 or MP3 (High bandwidth).

I should likely also add that no other audio hiccups occurs, once the static/stuttering ends.

[mattlovell]

• The initial static does not occur if JRiver is serving up native mp3 files (with no conversion/transcoding).  Those play gaplessly and I can push playlist changes till I'm blue in the face without any audible hiccup of any sort.

<sigh>...Yet another statement I'll have to retract.  The static can eventually occur even when handling MP3 files natively, with no transcoding.

At this point, lacking any other information, I am definitely inclined to call this a problem with the Yamaha DLNA renderer implementation.  SetNext works, but has an issue.  I've been whining at, er.... communicating with Yamaha as well, but I'm not optimistic.

So, to re-recap the problem:
 

• No audio problem ever occurs with SetNext disabled in JRiver for the Yamaha renderer.
• SetNext does nominally work, as the player can progress from track to track without a gap, however...
• Initial static/stuttering can be triggered to occur when pushing a new playlist (well, 2-entry list) to the renderer.  This initial static occurs only for the new, just-selected track starting the playlist and lasts a varying amount of time (fraction of a second to roughly 2 seconds).
• The phenomenon only seems to happen if the renderer has processed an earlier SetNext.
• The initial static can occur even if the rendered is Stopped when the new playlist is pushed out.

[bob]

Are you pushing this "2 track playlist" Send To->Play (your device) using the "Play" or "Add (as next to Play)" options?

[mattlovell]

Bob writes:

Are you pushing this "2 track playlist" Send To->Play (your device) using the "Play" or "Add (as next to Play)" options?

I call it a "2 track playlist" since JRiver only has SetAVTransportURI and SetNextAVTRansportURI available.  Since (I don't think) JRiver pushes whole playlists out to renderers, it's a "2-entry playlist".

Anyway, via "Play".

[mattlovell]

Some further clarifications:

• No audio problem ever occurs with SetNext disabled in JRiver for the Yamaha renderer.
• SetNext does nominally work, as the player can progress from track to track without a gap, however...
• Initial static/stuttering can be triggered to occur when pushing a new playlist (well, 2-entry list) to the renderer.  This initial static occurs only for the new, just-selected track starting the playlist and lasts a varying amount of time (fraction of a second to roughly 2 seconds).  The new playlist is pushed out via the default "Play (RX-A1040)" when that renderer's zone is the current one.
• The phenomenon only seems to happen if the renderer has made use of an earlier SetNext.
• What I mean by "made use of" is that the renderer moved from Track 1 to Track 2 automatically, thus "using" the URI that JRiver provided it via the SetNextAVTransportURI
• The initial static can occur even if the rendered is Stopped when the new playlist is pushed out.

Yes, it's a strange thing to have noticed  It's the sort of activity one would engage in only if one had just gotten, say, a new DLNA-capable receiver for the first time and was playing around!

[mattlovell]

BTW, issuing a Seek 0 on the same track that just experienced the static/stuttering (past the 10sec window mentioned earlier), causes a boatload of static with the Yamaha.

<s:Body>
<u:Seek xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<Unit>REL_TIME</Unit>
<Target>0:00:00</Target>
</u:Seek>
</s:Body>
</s:Envelope>


The TCP activity around this time shows one connection getting RST from the Yamaha, and a fair number of subsequently retried packets. 

[bob]

BTW, issuing a Seek 0 on the same track that just experienced the static/stuttering (past the 10sec window mentioned earlier), causes a boatload of static with the Yamaha.

<s:Body>
<u:Seek xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<Unit>REL_TIME</Unit>
<Target>0:00:00</Target>
</u:Seek>
</s:Body>
</s:Envelope>


The TCP activity around this time shows one connection getting RST from the Yamaha, and a fair number of subsequently retried packets. 

Since this works perfectly with MC as the renderer (which means there is noting wrong with the data) it could possibly be a stale cache.
We are however telling it not to cache when we serve the content.
There is Andrews random prefix approach however that will interfere with another way we handle a  different situation so while it might be an interesting test, it's not a fix for us.
It really does come down to bugs in the renderer firmware..

[mattlovell]

Since this works perfectly with MC as the renderer (which means there is noting wrong with the data) it could possibly be a stale cache.
We are however telling it not to cache when we serve the content.
There is Andrews random prefix approach however that will interfere with another way we handle a  different situation so while it might be an interesting test, it's not a fix for us.
It really does come down to bugs in the renderer firmware..

I suspect that's likely as well.  Perhaps one day I may hear back from Yamaha.

In my previous post, I mentioned that the static/stuttering also occurs with a Seek back to the start of the in-progress track.  Looking at the new TCP stream that gets started following the seek, there's definitely a gap in the progression of data flowing back from JRiver; see the attached screenshot.  Would this sort of pause in data be something that a renderer should be able to handle?

[mattlovell]

Would this sort of pause in data be something that a renderer should be able to handle?

I ask just because, in addition to DLNA SetNext support, the Yamaha's handling of its network interface might be something worthwhile to point Yamaha to.

I wanted to thank you, Bob, for your patience and help with this topic.  I know I had lots of false starts as I familiarized myself with DLNA/UPnP and tried taking stabs at root causes.  In an effort to find another DLNA server + control point to contrast with JRiver, I also have to say that nothing has come close!

[bob]

I suspect that's likely as well.  Perhaps one day I may hear back from Yamaha.

In my previous post, I mentioned that the static/stuttering also occurs with a Seek back to the start of the in-progress track.  Looking at the new TCP stream that gets started following the seek, there's definitely a gap in the progression of data flowing back from JRiver; see the attached screenshot.  Would this sort of pause in data be something that a renderer should be able to handle?

I'd think it was the receivers tcp window filling.
You might try the same test but pulling the url for the served file with curl to a local file (or /dev/null on a linux box) to see if you get the same curve.

[JimH]

You could let Yamaha know that we will provide them licenses and help if we can.  Thanks for your patience.

[mattlovell]

You could let Yamaha know that we will provide them licenses and help if we can.  Thanks for your patience.

I will do that.

FWIW, I ran across the following review for the Yamaha RX-A1040 that mentions JRiver and a problem that sounds similar.  The workaround the review describes doesn't really work for me, but then I don't get the static with every track change:

http://www.hometheaterhifi.com/receivers/receivers-reviews/yamaha-rx-a1040-audio-video-receiver-review/page-3-in-use.html

... When switching from one song to another in JRiver, the Yamaha had trouble getting an immediate lock on the bitstream. Switching from one song to another on the fly caused a 1.5 second gap of soft static, and then the Yamaha would pick up the music. This was a disappointment, but there is a workaround; by ending the music stream (pressing the “stop” button on JRiver to end a song), waiting a second, and then starting another song, the Yamaha picked up the new song immediately. Also, I’ve experienced this same behavior with other brands of AV equipment including Denon, HK, Emotiva, and Onkyo, so it may be an artifact of the DAC.

Just to make sure it wasn’t my server or network causing the problem, I switched JRiver to use my Oppo BDP-105 as a source. The Oppo was connected to the Yamaha via HDMI. With this configuration, there was never a skip.

[bob]

....

Just to make sure it wasn’t my server or network causing the problem, I switched JRiver to use my Oppo BDP-105 as a source. The Oppo was connected to the Yamaha via HDMI. With this configuration, there was never a skip.

He's using the Oppo as the "renderer" not the "source/server" I assume.
The Oppo doesn't support SetNext IIRC so that's not a good test anyway.