Print

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

[mattlovell]

In a different thread (within the MC20 forum), I posted the following:

The Yamaha RX-A1040 and JRiver's DNLA server occasionally get into a mode in which switching to a new track/song has a moment of initial static (or pops) before successful playback begins.  In other threads on this forum, I've seen the static attributed to mis-interpretation of the header/tags for a file.  Why is the problem occurring with L16 (no header), though?  Is there anything I can do to prevent this static?

This static only seems to happen when pushing a track change to the Yamaha.  If the Yamaha itself is just progressing through an established playlist, it doesn't occur.  This also doesn't occur all the time; I haven't figured out what triggers it, but once established it seems fairly persistent (until the next power cycle).

I also noticed that JRemote (and perhaps JRiver, I didn't walk back to the computer to check) can get out-of-sync with the receiver's current position within the playlist.

Any thoughts?  I'm open to trying a few experiments and, if they would be helpful, capturing logs.

Thanks!
  Matt

[mattlovell]

The earlier thread I found referencing static with track changes was for MC18:

  http://yabb.jriver.com/interact/index.php?topic=76494.0

[mattlovell]

It's also, at first impression, similar to this thread:

  http://yabb.jriver.com/interact/index.php?topic=74972.0

The conclusion from that thread, below, is that the noise was being caused by tags.  I swear that I'm already running PCM L16, though.

I'll have to double-check that again, but I was wondering if there were any other possible causes.

In case anyone is interested, a technical note about wav & aif files: such files comprise linear pcm audio data sandwiched between a so called RIFF header at the start, and the ID3v2 tag data / album art at the end. As horse says, the WAV and AIF formats are well and publicly documented.

If you hear a click at the start of a track, it means the player tried to convert the RIFF header into sound, and if you hear white noise at the end, it means the player tried to convert the tags and album art into sound.

If your player outputs such clicks or white noise, this is fundamentally unacceptable from any self respecting manufacturer. It is simply shoddy programming, and shows that the programmers were too lazy to read or implement the most basic of specs. I would guess their test procedure was something like "yeah buddy there's sound coming out; ok that's fine then..." => So you should definitely give WD (and any other player manufacturer) hell for responding in such a patronising way.

PS the good news is that if you set MC to do Always Convert / L16 No header, it strips the RIFF header from the start and the tags & album art from the end, and simply feeds the remaining intervening pcm audio data straight to your player unmolested. (In the case of wav just swapping the byte order).

[mattlovell]

For anyone looking at this thread for reference, Bob suggested the following:

If you right click on the zone and under DLNA controller options, disable SetNext support does it still happen?

My experimentation has been limited (about 10 minutes of switching tracks), but disabling SetNext appears to have resolved the issue!

How should I present this deficiency to Yamaha (as it seems like something a firmware update could resolve, since little of DLNA/UPnP stack should be hardcoded)? 

[mattlovell]

bob writes:

It would be interesting if you downloaded UPnP Tools for Developer and ran the device spy to see if your Yamaha claims to support the SetNextAVTransportURI function.

Here's the device XML for the RX-A1040.  Looks like they do (if seeing service:AVTransport:1 is what I'm looking for).

<root>
 <yamaha:X_device>
  <yamaha:X_URLBase>http://10.0.0.79:80/</yamaha:X_URLBase>
  <yamaha:X_serviceList><yamaha:X_service>
  <yamaha:X_specType>urn:schemas-yamaha-com:service:X_YamahaRemoteControl:1</yamaha:X_specType>
  <yamaha:X_controlURL>/YamahaRemoteControl/ctrl</yamaha:X_controlURL>
  <yamaha:X_unitDescURL>/YamahaRemoteControl/desc.xml</yamaha:X_unitDescURL>
  </yamaha:X_service></yamaha:X_serviceList></yamaha:X_device>
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
<device ms:X_MS_SupportsWMDRM="true">
  <dlna:X_DLNADOC>DMR-1.50</dlna:X_DLNADOC>
  <pnpx:X_compatibleId>MS_DigitalMediaDeviceClass_DMR_V001
  </pnpx:X_compatibleId><pnpx:X_deviceCategory>MediaDevices Multimedia.DMR MediaDevice.DMC
  </pnpx:X_deviceCategory><pnpx:X_hardwareId>VEN_0033&DEV_0006&REV_01
  </pnpx:X_hardwareId><df:X_deviceCategory>Multimedia.DMR
  </df:X_deviceCategory>
    <deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
    <friendlyName>RX-A1040 B536C5</friendlyName>
    <manufacturer>Yamaha Corporation</manufacturer>
    <manufacturerURL>http://www.yamaha.com/</manufacturerURL>
    <modelDescription>AV Receiver</modelDescription>
    <modelName>RX-A1040</modelName>
    <modelNumber>A1040</modelNumber>
    <modelURL>http://www.yamaha.com/</modelURL>
    <serialNumber>00689AA3</serialNumber>
    <UDN>uuid:5f9ec1b3-ed59-1900-4530-00a0deb536c5</UDN>
    <UPC>123810928305</UPC>
   <iconList>
     <icon><mimetype>image/jpeg</mimetype><width>48</width><height>48</height><depth>24</depth><url>/BCO_device_sm_icon.jpg</url></icon>
     <icon><mimetype>image/jpeg</mimetype><width>120</width><height>120</height><depth>24</depth><url>/BCO_device_lrg_icon.jpg</url></icon>
     <icon><mimetype>image/png</mimetype><width>48</width><height>48</height><depth>24</depth><url>/BCO_device_sm_icon.png</url></icon>
    <icon><mimetype>image/png</mimetype><width>120</width><height>120</height><depth>24</depth><url>/BCO_device_lrg_icon.png</url></icon>
  </iconList><serviceList>
  <service>
    <serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
    <serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>
    <SCPDURL>/RenderingControl/desc.xml</SCPDURL>
    <controlURL>/RenderingControl/ctrl</controlURL>
    <eventSubURL>/RenderingControl/evt</eventSubURL>
  </service>
  <service>
    <serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
    <serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
    <SCPDURL>/ConnectionManager/desc.xml</SCPDURL>
    <controlURL>/ConnectionManager/ctrl</controlURL>
    <eventSubURL>/ConnectionManager/evt</eventSubURL>
  </service>
  <service>
    <serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>
    <serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>
    <SCPDURL>/AVTransport/desc.xml</SCPDURL>
    <controlURL>/AVTransport/ctrl</controlURL>
    <eventSubURL>/AVTransport/evt</eventSubURL>
  </service>
  </serviceList>
  <presentationURL>http://10.0.0.79/</presentationURL>
 </device>
</root>

also of likely interest is the excerpt from the service XML:

<action>
  <name>SetNextAVTransportURI</name>
     <argumentList>
        <argument>
            <name>InstanceID</name>
            <direction>in</direction>
            <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
        </argument>
        <argument>
           <name>NextURI</name>
           <direction>in</direction>
           <relatedStateVariable>NextAVTransportURI</relatedStateVariable>
        </argument>
        <argument>
           <name>NextURIMetaData</name>
           <direction>in</direction>
           <relatedStateVariable>NextAVTransportURIMetaData</relatedStateVariable>
       </argument>
   </argumentList>
</action>

[bob]

In UPnP tools, can you just click on the + to expand the device, then click on the + to expand AVTransport:1 then see if the function exists (note that the variable may exist but not the function).

[mattlovell]

In UPnP tools, can you just click on the + to expand the device, then click on the + to expand AVTransport:1 then see if the function exists (note that the variable may exist but not the function).

Yes, expanding the AVTransport:1 scheme, I see the following functions (among others):

• Seek
• SetAVTransportURI
• SetNextAVTransportURI
• SetPlayMode

The SetNextAVTransportURI() function has the arguments listed in the action XML excerpt from my previous post.

[bob]

Yes, expanding the AVTransport:1 scheme, I see the following functions (among others):

• Seek
• SetAVTransportURI
• SetNextAVTransportURI
• SetPlayMode

The SetNextAVTransportURI() function has the arguments listed in the action XML excerpt from my previous post.

Ok, I suspect then there might be a problem with GetMediaInfo.
We use that to determine what the renderer thinks is the NextURI to be played.
This function is required to be supported by the base DLNA spec.

[mattlovell]

Ok, I suspect then there might be a problem with GetMediaInfo.
We use that to determine what the renderer thinks is the NextURI to be played.
This function is required to be supported by the base DLNA spec.

A problem on JRiver's side or on the receiver's side?  (It was unclear to me above.)

There are certainly a lot of parameters for GetMediaInfo(), I'll give it that!

<action>
  <name>GetMediaInfo</name>
  <argumentList>
  <argument><name>InstanceID</name><direction>in</direction><relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable></argument>
  <argument><name>NrTracks</name><direction>out</direction><relatedStateVariable>NumberOfTracks</relatedStateVariable></argument>
  <argument><name>MediaDuration</name><direction>out</direction><relatedStateVariable>CurrentMediaDuration</relatedStateVariable></argument>
  <argument><name>CurrentURI</name><direction>out</direction><relatedStateVariable>AVTransportURI</relatedStateVariable></argument>
  <argument><name>CurrentURIMetaData</name><direction>out</direction><relatedStateVariable>AVTransportURIMetaData</relatedStateVariable></argument>
  <argument><name>NextURI</name><direction>out</direction><relatedStateVariable>NextAVTransportURI</relatedStateVariable></argument>
  <argument><name>NextURIMetaData</name><direction>out</direction><relatedStateVariable>NextAVTransportURIMetaData</relatedStateVariable></argument>
  <argument><name>PlayMedium</name><direction>out</direction><relatedStateVariable>PlaybackStorageMedium</relatedStateVariable></argument>
  <argument><name>RecordMedium</name><direction>out</direction><relatedStateVariable>RecordStorageMedium</relatedStateVariable></argument>
  <argument><name>WriteStatus</name><direction>out</direction><relatedStateVariable>RecordMediumWriteStatus</relatedStateVariable></argument>  
 </argumentList>
</action>

[bob]

A problem on JRiver's side or on the receiver's side?  (It was unclear to me above.)

There are certainly a lot of parameters for GetMediaInfo(), I'll give it that!

<action>
  <name>GetMediaInfo</name>
  <argumentList>
  <argument><name>InstanceID</name><direction>in</direction><relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable></argument>
  <argument><name>NrTracks</name><direction>out</direction><relatedStateVariable>NumberOfTracks</relatedStateVariable></argument>
  <argument><name>MediaDuration</name><direction>out</direction><relatedStateVariable>CurrentMediaDuration</relatedStateVariable></argument>
  <argument><name>CurrentURI</name><direction>out</direction><relatedStateVariable>AVTransportURI</relatedStateVariable></argument>
  <argument><name>CurrentURIMetaData</name><direction>out</direction><relatedStateVariable>AVTransportURIMetaData</relatedStateVariable></argument>
  <argument><name>NextURI</name><direction>out</direction><relatedStateVariable>NextAVTransportURI</relatedStateVariable></argument>
  <argument><name>NextURIMetaData</name><direction>out</direction><relatedStateVariable>NextAVTransportURIMetaData</relatedStateVariable></argument>
  <argument><name>PlayMedium</name><direction>out</direction><relatedStateVariable>PlaybackStorageMedium</relatedStateVariable></argument>
  <argument><name>RecordMedium</name><direction>out</direction><relatedStateVariable>RecordStorageMedium</relatedStateVariable></argument>
  <argument><name>WriteStatus</name><direction>out</direction><relatedStateVariable>RecordMediumWriteStatus</relatedStateVariable></argument>  
 </argumentList>
</action>

This is just a static list of parameters.
The way to test it is to run device spy and invoke GetMediaInfo while the interactions are occurring.
Even if the renderer supports it properly it's quite possible that it can't actually deal with the timing of the reception of the NextURI.

[mattlovell]

The way to test it is to run device spy and invoke GetMediaInfo while the interactions are occurring.
Even if the renderer supports it properly it's quite possible that it can't actually deal with the timing of the reception of the NextURI.

Ok, I'll try experimenting.

Is it significant at all that the behavior doesn't occur all the time?  Upon first power-on (of both the receiver and JRiver), probably around a dozen track/playlist transitions can be pushed to the receiver fine, with no initial static/popping occurring.  After some point, though, the initial static "crops up" and then persists for all further pushed changes.

[mattlovell]

The way to test it is to run device spy and invoke GetMediaInfo while the interactions are occurring.
Even if the renderer supports it properly it's quite possible that it can't actually deal with the timing of the reception of the NextURI.

Ok, I'll try experimenting.

Random invocations of GetMediaInfo() during playback don't seem to cause any harm.

One other tidbit to note...  This time around, I was using JRiver on the PC directly to push the track changes (making sure that SetNext support was enabled for the RXA1040).  I was unable to induce the static/popping at all, even after many playlist updates.  GetMediaInfo() calls from the Device Spy were also all handled fine.

In all of my previous experimenting, I was sitting out in the living room and using JRemote to change tracks.

What does the addition of JRemote as the control point (not a true DLNA Control Point, I realize) throw into the mix?

[mattlovell]

One other tidbit to note...  This time around, I was using JRiver on the PC directly to push the track changes (making sure that SetNext support was enabled for the RXA1040).  I was unable to induce the static/popping at all, even after many playlist updates.  GetMediaInfo() calls from the Device Spy were also all handled fine.

Ok, I have to revoke the statement above; the popping just took longer to initiate for some reason.  So, I was able to get the static/popping to happen just pushing URI changes directly from JRiver (no JRemote interaction involved).

Nothing odd happened with the GetMediaInfo() calls from the Device Spy.  Those all completed fine, and didn't induce any static/popping themselves.

  Matt

[mattlovell]

After further experimenting, with JRiver's DLNA server setup to always convert to PCM L16, and with SetNext support enabled for the receiver, I found that disabling "DLNAExtra" (under the DLNA server advanced settings) seems to have done the trick.  Gapless playback is working, so I think that means that SetNext is indeed being used, and (thus far) no static/popping has occurred after many, many playlist changes.

I'm keeping my fingers crossed.  (I noted previously that the behavior seemed "modal".)

What exactly does DLNAExtra provide (i.e., what am I missing) and could its presence/absence explain the behavior observed?

Thanks!
  Matt

[bob]

After further experimenting, with JRiver's DLNA server setup to always convert to PCM L16, and with SetNext support enabled for the receiver, I found that disabling "DLNAExtra" (under the DLNA server advanced settings) seems to have done the trick.  Gapless playback is working, so I think that means that SetNext is indeed being used, and (thus far) no static/popping has occurred after many, many playlist changes.

I'm keeping my fingers crossed.  (I noted previously that the behavior seemed "modal".)

What exactly does DLNAExtra provide (i.e., what am I missing) and could its presence/absence explain the behavior observed?

Thanks!
  Matt

DLNAExtra mostly provides extra information about the stream using the DLNA flags. It also provides coverart via Resource records. It could be that your device doesn't like those extra resource records.

[mattlovell]

After further experimenting, with JRiver's DLNA server setup to always convert to PCM L16, and with SetNext support enabled for the receiver, I found that disabling "DLNAExtra" (under the DLNA server advanced settings) seems to have done the trick.  Gapless playback is working, so I think that means that SetNext is indeed being used, and (thus far) no static/popping has occurred after many, many playlist changes.

I'm keeping my fingers crossed.  (I noted previously that the behavior seemed "modal".)

Arrgg... It took a while, but the static upon track/playlist push eventually cropped up!  So, I guess it's not DLNAExtra after all.

I guess I'm back to disabling SetNext.  Disappointing when playing something like Sgt. Pepper's, but I guess I'll live with it.

[mattlovell]

Arrgg... It took a while, but the static upon track/playlist push eventually cropped up!  So, I guess it's not DLNAExtra after all.

The phenomenon seems to occur more readily when JRiver has to convert Ogg Vorbis tracks.  (The DLNA Server is set to Always Convert to PCM L16, if you recall.)  I'll try to experiment further...
 

[mattlovell]

Arrgg... It took a while, but the static upon track/playlist push eventually cropped up!  So, I guess it's not DLNAExtra after all.

Latest settings:

• Always convert: PCM L16
• DLNAExtra on
• SetNext enabled
• Bitrate field disabled

Lots and lots of track changes thus far, from MP3 to Ogg and back, without the static/pops.   I'm going to let several tracks play through normally and then resume playlist changes after that to see what then happens.

I hate issues that aren't readily reproducible!

[AndrewFG]

I am guessing that your problem is is none of the above..

My guess is that it is caused by a bandwith bottleneck on your LAN when the client starts the download of the track from the server. How fast is your LAN? If you are on wifi, then try using an Ethernet connection instead...

[mattlovell]

My guess is that it is caused by a bandwith bottleneck on your LAN when the client starts the download of the track from the server. How fast is your LAN? If you are on wifi, then try using an Ethernet connection instead...

The two wired segments are running at 1 Gb/s and 100 Mb/s, respectively, with very little traffic (basically just an active iPad with JRemote talking back to MC and the DLNA receiver).  The wireless segment is running 802.11n; the receiver is running on the wired segment "after" the wireless bridge.  A Roku (also wired on that same segment) is able to stream HD movies in 5.1 from Vudu without issue.  Using an Airport Express (with this and the previous receiver), playback has also been fine for years.

My first inclination is to think that there's plenty of BW (and responsiveness) for a 16-bit stereo PCM stream.

Disabling SetNext also definitely had an impact (seemingly eliminating the problem).  I would like to have gapless playback, so thus my various experiments with SetNext re-enabled.  I'm willing to buy into the notion that there is something about the communication between the receiver and JRiver that, only eventually, confuses the receiver.  That seems to be the case since SetNext functionality does appear to work (it's advertised as implemented and does achieve gapless playback when enabled).   I am thoroughly confused why the problem takes a while to manifest, which lends some credence to suspecting network traffic.  It's just hard to believe that the fairly limited communication I've seen for DLNA would stress the network.

I would like to understand the protocol involved in push playlist changes over DLNA better.  Does the DLNA Control Point first pause or stop the renderer, push the new media URIs, and then "push" play? 

[bob]

Lots of renderers implement the bitrate field incorrectly.
That's why it's not enabled by default.

When using the SetNext function there is no stop/pause/play logic used at all. It's all up to the renderer to do that when it wants. That is how the tracks can be played without a gap.

[mattlovell]

Lots of renderers implement the bitrate field incorrectly.
That's why it's not enabled by default.

You can count Yamaha in that camp.  I had enabled it a while ago and just left it enabled, since it didn't seem to be doing anything. 

When using the SetNext function there is no stop/pause/play logic used at all. It's all up to the renderer to do that when it wants. That is how the tracks can be played without a gap.

How about when the playlist is changing (i.e., one is pushing a new track and/or playlist to the renderer)?

[mattlovell]

How about when the playlist is changing (i.e., one is pushing a new track and/or playlist to the renderer)?

"Peeking" with Wireshark, it looks like the following communication takes place:

• JRiver checks current status of the renderer
• Renderer replies that it is Playing
• JRiver issues Stop
• Renderer stops
• JRiver re-checks current status
• Render replies that it is Stopped
• JRiver invokes SetAVTransportURI
• Renderer provides SetAVTransportURIResponse
• JRiver issues Play
• Renderer provides PlayResponse
• JRiver invokes GetPositionInfo  (and renderer responds...)
• JRiver invokes GetTransportSettings  (and renderer responds)
• JRiver invokes GetMediaInfo  (and renderer responds)
• JRiver invokes SetNextAVTransportURI
• Renderer provides SetNextAVTransportURIResponse

So, seems like the renderer is directed to stop prior to updating the playlist.

[bob]

"Peeking" with Wireshark, it looks like the following communication takes place:

• JRiver checks current status of the renderer
• Renderer replies that it is Playing
• JRiver issues Stop
• Renderer stops
• JRiver re-checks current status
• Render replies that it is Stopped
• JRiver invokes SetAVTransportURI
• Renderer provides SetAVTransportURIResponse
• JRiver issues Play
• Renderer provides PlayResponse
• JRiver invokes GetPositionInfo  (and renderer responds...)
• JRiver invokes GetTransportSettings  (and renderer responds)
• JRiver invokes GetMediaInfo  (and renderer responds)
• JRiver invokes SetNextAVTransportURI
• Renderer provides SetNextAVTransportURIResponse

So, seems like the renderer is directed to stop prior to updating the playlist.

Well of course if you change the currently playing track!
Otherwise, it doesn't do any stop logic.
If you change the next to play the setNext will be resent.

[mattlovell]

Looking at a network trace with the initial static manifesting, there are a handful of duplicate TCP acks coming from the receiver, resulting in TCP packet re-transmissions from the JRiver server.  The TCP stream in question is the one transferring the .wav file that was just started.  The re-transmission hiccup occurs in several small bursts near the start of the file; looking at the trace, they may well continue to occur...

Perhaps the network is to be suspected after all.

I don't believe I saw that behavior when playback (and track switching) was completely normal.  I'll experiment further.

[mattlovell]

Ok, one further tidbit that may be of interest.

Once the problem has presented itself, initial static/popping occurs at the start of a new track even when the renderer is stopped.  One can have nothing playing, having directly stopped the renderer some time ago.  Upon selecting (via JRemote) and new track (and rest of playlist as well) to play, playback starts with a second or two of static. 

So, perhaps there is an internal buffer management issue within the Yamaha receiver, but there certainly is no competing overlap of old and new PCM streams on the network itself.

Is the order of operations that I posted above (Stop, SetAV, Play, SetNextAV) required by the DLNA specification?  I ask since it may be interesting to have both SetAVTransportURI and SetNextAVTransportURI invoked prior to starting Play.  Would such a change be a possible option for the DLNA server?  (I'm also willing to try a one-off, experimental build.)

[mattlovell]

One can have nothing playing, having directly stopped the renderer some time ago.  Upon selecting (via JRemote) a new track (and rest of playlist as well) to play, playback starts with a second or two of static.

Oh, and at no point in time (whether the initial static occurs or not) does SetNextAVTransportURI not "stick".  Playback of the next track always seems to work as intended and Device Spy invocation of GetMediaInfo() always shows the correct information.

In addition to my question above regarding the order of operations, I have one other...  What happens when setting up AVTransport of a file with no artwork and with no tags?  Does info still get sent over to the renderer as empty strings or are the fields omitted entirely?  (A network trace will give me the answer, so perhaps I'll try to answer my own question this evening.)

[AndrewFG]

I still think it is a network bottleneck issue. I don't see anything wrong with the Upnp command sequences you have been posting. And in any case there is nothing in particluar about Upnp command sequences that could cause static to be injected into the stream, since the media stream server and the control point are two quite different animals.

i would try hardwiring your server and your renderer together without any other devices on the LAN segment.
And if that does not work, then I would take your Yamaha in to be checked over..

[JimH]

We've seen problems in the past with devices that didn't like things like cover art or tags in WAV files.

I would expect a network bandwidth problem to cause gaps in playback, but not static.

[bob]

If you are sending PCM L16 there are no tags.
A test would be to do the conversion in your library to PCM L16 then the same conversion by pulling the URL your rendering device is attempting to get (see the status screen) with a browser and binary compare the resulting file with the manual conversion one.

[mattlovell]

i would try hardwiring your server and your renderer together without any other devices on the LAN segment.
And if that does not work, then I would take your Yamaha in to be checked over..

Problem replicated with the server and renderer wired together.

I may have also stumbled upon the "recipe" to reproduce the issue:

• Allow the rendered to play through a track completely, such that it uses the next track that was setup
• After that change the playlist (perhaps preferably to one of my Ogg Vorbis files with no tags and no artwork?)

I'll have to power-cycle everything and see if that is indeed a direct route to reproducing the issue.

[mattlovell]

Problem replicated with the server and renderer wired together.

I may have also stumbled upon the "recipe" to reproduce the issue:

    Allow the rendered to play through a track completely, such that it uses the next track that was setup
    After that change the playlist (perhaps preferably to one of my Ogg Vorbis files with no tags and no artwork?)

I'll have to power-cycle everything and see if that is indeed a direct route to reproducing the issue.

That indeed appears to be the recipe:

• Start with the first track from Sgt. Pepper's Lonely Hearts Club Band
• Allow the renderer to move one to Track 2
• Pick from Bach's English Suites (a set of large-ish Ogg Vorbis with no real tag info and no artwork

This will produce many, many seconds of static/popping for me (at least with a wired connection, I have yet to try the above back on wireless).  At one point, JRiver got thoroughly confused regarding the renderer's state, thinking it was stopped when it was still playing.  Trying to stop the renderer via the Yamaha remote control, it then picked up another track from JRiver.

I tried the DLNA server in foobar 2000, MediaMonkey, and Windows Media Center, but none of them (that I could find) support gapless play back to start with.  (Plus, I would have to buy MediaMonkey Gold in order to stream the Ogg Vorbis file in step 3 above.)

I guess I'll remove my 50ft span of cable and go back to "gappy" playback (or ditch DLNA and resume using Airplay + Airfoil), unless someone has some other suggestion.

[bob]

That indeed appears to be the recipe:

• Start with the first track from Sgt. Pepper's Lonely Hearts Club Band
• Allow the renderer to move one to Track 2
• Pick from Bach's English Suites (a set of large-ish Ogg Vorbis with no real tag info and no artwork

This will produce many, many seconds of static/popping for me (at least with a wired connection, I have yet to try the above back on wireless).  At one point, JRiver got thoroughly confused regarding the renderer's state, thinking it was stopped when it was still playing.  Trying to stop the renderer via the Yamaha remote control, it then picked up another track from JRiver.

I tried the DLNA server in foobar 2000, MediaMonkey, and Windows Media Center, but none of them (that I could find) support gapless play back to start with.  (Plus, I would have to buy MediaMonkey Gold in order to stream the Ogg Vorbis file in step 3 above.)

I guess I'll remove my 50ft span of cable and go back to "gappy" playback (or ditch DLNA and resume using Airplay + Airfoil), unless someone has some other suggestion.

So you are saying there is only an issue when you modify the active playlist during playback?
If you just give it a playlist and don't mess with it there is no issue?

[mattlovell]

So you are saying there is only an issue when you modify the active playlist during playback?
If you just give it a playlist and don't mess with it there is no issue?

Yes, that has been my experience (as noted in the thread's subject).

Of course, I've spent most of my time recently just pushing changes, rather than listening to whole albums!   I'll have to carve out some time to do so, both upon initial power-up and after inducing the issue (now that I have a recipe for reproducing it).

[mattlovell]

Of course, I've spent most of my time recently just pushing changes, rather than listening to whole albums! Smiley  I'll have to carve out some time to do so, both upon initial power-up and after inducing the issue (now that I have a recipe for reproducing it).

I'm 5 tracks into Sgt. Pepper's (after initial power-on for both JRiverMC and the Yamaha), and tracks have been playing fine, transitioning fine as well (and gaplessly).  I'll keep listening a bit more, but we have to head off to work in a bit.

This evening, I'll try triggering the problem and listening again.

[mattlovell]

I noticed the following tidbit in the changelog for MC 20.0.31:

6. Fixed: DLNA, when pushing tracks to a renderer, when the playlist changes the next item to play, resend the SetNextAVTransportURI (for devices that support it) to keep the playlist in sync with the device.

I'm pretty sure I'm using 20.0.30 at the moment.  Think the above update is relevant to this thread?

[bob]

I noticed the following tidbit in the changelog for MC 20.0.31:

I'm pretty sure I'm using 20.0.30 at the moment.  Think the above update is relevant to this thread?

That's why I asked if it worked when not messing with the playlist.
It could be an issue. There however is a possibility that your renderer may not behave properly when receiving a second SetNext.
Only testing will tell.

[AndrewFG]

That's why I asked if it worked when not messing with the playlist.
It could be an issue. There however is a possibility that your renderer may not behave properly when receiving a second SetNext.
Only testing will tell.

Hi bob, It might help if you send a SetNext (nul) to clear the prior playlist url value, and then another SetNext to set the new value. ??

[bob]

Hi bob, It might help if you send a SetNext (nul) to clear the prior playlist url value, and then another SetNext to set the new value. ??

Hi Andrew, I think that could be helpful.
It will be interesting to see if the changes already made affect his issue.

[mattlovell]

It will be interesting to see if the changes already made affect his issue.

MC 20.0.33 seems to have improved the problem somewhat, but it is still present.  Previously, with MC 20.0.30, the "recipe" I have above (allow a playlist change to occur, then push out a new playlist featuring large ogg vorbis files) was serving to trigger the problem immediately.  With 20.0.33, the problem didn't manifest itself upon the first run through that recipe.  (You can imagine my excitement!)  Repeating the recipe with similar files though (switching between mp3/m4a and ogg vorbis after letting a playlist make some progress), the issue did manifest.

Interestingly (perhaps), allowing a newly-established playlist to progress on its own, no inter-track noise occurred at all.  After that normal playlist progress, the issue also then stopped (at least for a while)!  I could push out a new playlist without issue. 

So, the changes made from 20.0.30 to 20.0.33 seem to have had an effect, but didn't entirely eliminate the behavior.

[bob]

MC 20.0.33 seems to have improved the problem somewhat, but it is still present.  Previously, with MC 20.0.30, the "recipe" I have above (allow a playlist change to occur, then push out a new playlist featuring large ogg vorbis files) was serving to trigger the problem immediately.  With 20.0.33, the problem didn't manifest itself upon the first run through that recipe.  (You can imagine my excitement!)  Repeating the recipe with similar files though (switching between mp3/m4a and ogg vorbis after letting a playlist make some progress), the issue did manifest.

Interestingly (perhaps), allowing a newly-established playlist to progress on its own, no inter-track noise occurred at all.  After that normal playlist progress, the issue also then stopped (at least for a while)!  I could push out a new playlist without issue. 

So, the changes made from 20.0.30 to 20.0.33 seem to have had an effect, but didn't entirely eliminate the behavior.

If you alter the playlist in the first 10 seconds or last 10 seconds of a track you are going to run into the track changing and SetNext logic. You should avoid that scenario during testing.
If you can reproduce the issue cutting it down to a single variable there might be more that can be done otherwise I'm inclined to dismiss this as a shortcoming of the renderer that can't be worked around.

[mattlovell]

If you alter the playlist in the first 10 seconds or last 10 seconds of a track you are going to run into the track changing and SetNext logic. You should avoid that scenario during testing.

Good to know.

If you can reproduce the issue cutting it down to a single variable there might be more that can be done otherwise I'm inclined to dismiss this as a shortcoming of the renderer that can't be worked around.

I'll see what else I can discover examining network traces.  The only obvious hiccup I've seen hints at TCP windowing woes with the receiver (which, due to the increased bandwidth, grew worse when I had the receiver wired).  I've forwarded some details to Yamaha's support email, but they've acted as a pretty good black hole in terms of returning any information.

Know of any other Windows or Linux-based DLNA server + control points that support sending SetNextAVTransport?  I'm not interested in switching (JRiver + JRemote is still one of the best user interfaces I've seen), but I would be interested to see if any control point ordered operations differently.  (Looking through the UPnP and DLNA specs, I see they took the route of never, ever providing example flows that put several operations together!)

Finally, I'm curious whether JRiver looked into the ability of AVTransport to convey a playlist (e.g., .m3u) rather than a single track?

[mattlovell]

I've also been curious why JRiver (and JRemote) get "off" regarding the current track being played by the receiver.  In the typical case, the receiver has advanced to the next track (gaplessly), but its own display and JRiver+JRemote still show the last track.  Peeking at the GetPositionInfoResponse, it is also guilty of hanging onto the last track too long!

Note the Track Duration and RelTime values below.  In this particular trace, I observed RelTime get to 20 seconds in a track that is only 6 seconds long.

<s:Envelope
..xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
..s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
.<s:Body>
..<u:GetPositionInfoResponse xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
...<Track>1</Track>
...<TrackDuration>0:00:06</TrackDuration>
...<TrackMetaData>&lt;DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:device-1-0" xmlns:av="urn:schemas-sony-com:av" xmlns:pv="http://www.pv.com/pvns/"&gt;
&lt;item id="F333861" parentID="0" restricted="1"&gt;
&lt;dc:title&gt;The Sex (Intro)&lt;/dc:title&gt;
&lt;upnp:class&gt;object.item.audioItem.musicTrack&lt;/upnp:class&gt;
&lt;upnp:artist&gt;Tove Lo&lt;/upnp:artist&gt;
&lt;upnp:artist role="Performer"&gt;Tove Lo&lt;/upnp:artist&gt;
&lt;upnp:artist role="AlbumArtist"&gt;Tove Lo&lt;/upnp:artist&gt;
&lt;dc:creator&gt;Tove Lo&lt;/dc:creator&gt;
&lt;upnp:album&gt;Queen of the Clouds (Deluxe)&lt;/upnp:album&gt;
&lt;upnp:genre&gt;Spoken Word&lt;/upnp:genre&gt;
&lt;upnp:author role="Composer"&gt;Tove Lo&lt;/upnp:author&gt;
&lt;upnp:originalTrackNumber&gt;1&lt;/upnp:originalTrackNumber&gt;
&lt;upnp:playbackCount&gt;1&lt;/upnp:playbackCount&gt;
&lt;dc:date&gt;2014-09-30T01:00:00&lt;/dc:date&gt;
&lt;pv:playcount&gt;1&lt;/pv:playcount&gt;
&lt;pv:lastPlayedTime&gt;2014-11-05T21:02:44&lt;/pv:lastPlayedTime&gt;
&lt;pv:addedTime&gt;1412134475&lt;/pv:addedTime&gt;
&lt;pv:modificationTime&gt;1412131968&lt;/pv:modificationTime&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_TN"&gt;http://10.0.0.3:52101/AArs/333861.jpg&lt;/upnp:albumArtURI&gt;
&lt;res protocolInfo="http-get:*:audio/L16;rate=44100;channels=2:DLNA.ORG_PN=LPCM;DLNA.ORG_OP=01;DLNA.ORG_CI=0" duration="0:00:06.000" size="1068984" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="16"&gt;http://10.0.0.3:52101/Music/F333861.wav&lt;/res&gt;
&lt;/item&gt;
&lt;/DIDL-Lite&gt;
</TrackMetaData>
...<TrackURI>http://10.0.0.3:52101/Music/F333861.wav</TrackURI>
...<RelTime>0:00:08</RelTime>
...<AbsTime>2:06:14</AbsTime>
...<RelCount>8000</RelCount>
...<AbsCount>7574000</AbsCount>
..</u:GetPositionInfoResponse>
.</s:Body>
</s:Envelope>

[bob]

Don't experiment with 6 second tracks.
The SetNext logic will be unable to deal properly with that. I don't think anything under 20 seconds will work properly. DLNA is simply not that fine grained.

When your renderer proceeds to the next track via the SetNext call the GetMediaInfo should immediately reflect that. If it doesn't it's broken on your renderer.

[mattlovell]

The SetNext logic will be unable to deal properly with that. I don't think anything under 20 seconds will work properly. DLNA is simply not that fine grained.

The 6-second track was convenient since I was taking a trace capture.  I've seen the same behavior (JRiver, JRemote, and receiver's own display still show the previous song) for 3 and 4 minutes tracks (even though the receiver has moved on).

[bob]

The 6-second track was convenient since I was taking a trace capture.  I've seen the same behavior (JRiver, JRemote, and receiver's own display still show the previous song) for 3 and 4 minutes tracks (even though the receiver has moved on).

Leave JRemote out of this for now, your goal is to cut this down to a single variable.

Since you are said the display doesn't match what's playing, it means GetMediaInfo is broken on your renderer. You can verify this by invoking it from the UPnP tools suite while the second track of a playlist is playing. The results should match what you see on the Media Center display (and what is actually playing).

[bob]

I found an interesting difference between my 2 renderers that will play 24 bit wave which seems to lead me to a reasonable conclusion about your static issue.

If I start playing a file with the Audiophile DAC specified output format 24 bit PCM (the preset) and seek in the file on the Raumfeld, it often gets static or some other weirdness.
If I do the same to the WDTV it plays fine.

My hunch is the following:
The Raumfeld (and your Yamaha) gets the seek command, then does a range request for the file from the point of the seek (we send it a time seek, it calls for a byte range seek).

One problem could simply be that the range request wasn't on a sample boundary (6 bytes in this case). This would cause all sorts of grief. As it turned out for the Raumfeld this wasn't the case.

The other possibility is that the renderer could be (wrongly) trying to interpret the first 44 bytes of the file from the range request as a wave header. I'm very suspicious that this is the case because of the seeming random behavior after the seek. This would also explain why the L16 setting works. It's headerless, it's 16 bits which is bound to be the assumed default and in any case the bit depth is returned in the DLNA flags upon the receipt of the range request. Also, even if there is no explicit seek, the renderer doesn't necessarily open a file and read it's contents in one chunk. Some do multiple range requests during playback.

[AndrewFG]

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...

[mattlovell]

Bob writes:

I found an interesting difference between my 2 renderers that will play 24 bit wave which seems to lead me to a reasonable conclusion about your static issue...

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).

[mattlovell]

It's a little bit of a diversion from the static/stuttering issue, but ...

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).

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.