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?
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).
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!
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.
<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>
<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>
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):Ok, I suspect then there might be a problem with GetMediaInfo.
- 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.
<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>
A problem on JRiver's side or on the receiver's side? (It was unclear to me above.)This is just a static list of parameters.
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>
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.
QuoteThe 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.
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.
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.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.
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
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.
Arrgg... It took a while, but the static upon track/playlist push eventually cropped up! So, I guess it's not DLNAExtra after all.
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...
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.
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:Well of course if you change the currently playing track!
- 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.
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.
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.
That indeed appears to be the recipe:So you are saying there is only an issue when you modify the active playlist during playback?
- 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?
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).
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 noticed the following tidbit in the changelog for MC 20.0.31:That's why I asked if it worked when not messing with the playlist.
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.
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.
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.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.
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.
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).Leave JRemote out of this for now, your goal is to cut this down to a single variable.
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...
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.
It's fascinating to me that Renderer behavior can be affected so much by what the Control Point is doing!
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.
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??
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 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?)
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.From what I understood there is no issue if he just lets a playlist play.
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...
Bob writes:It doesn't start transcoding until it receives the file request.
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).
^
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.
Any declared victory on this topic, of course, must eventually be qualified or retracted...There's no reason to include a session ID, that option is for old legacy upnp devices.
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.
I'm starting to lose track of the permutations of this testing and can only devote so much time to it.
- 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.
Are you pushing this "2 track playlist" Send To->Play (your device) using the "Play" or "Add (as next to Play)" options?
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.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.
<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..
Would this sort of pause in data be something that a renderer should be able to handle?
I suspect that's likely as well. Perhaps one day I may hear back from Yamaha.I'd think it was the receivers tcp window filling.
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?
You could let Yamaha know that we will provide them licenses and help if we can. Thanks for your patience.
... 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.
....He's using the Oppo as the "renderer" not the "source/server" I assume.
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.