Print

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

[mattlovell]

Don't know whether posting here or in the Remotes section would be better...

I've noticed recently that, after selecting an album (either via a long-press in album view and selecting "Play All" or by going into the track view with "Play All Now" as the selection mechanism and picking the first track), MC only plays a single track to the DLNA renderer.

Sitting in front of MC this morning, with that renderer's Playing Now list on-screen, I can see the whole album (multiple tracks) get populated, and then the list shrink to just the currently-playing first track.  Upon repeating the selection action in JRemote, the whole album finally "sticks" in the Playing Now list.

I've noticed this behavior for the past few 23.0.x MC releases; I just haven't reported it previously.

Thanks for any suggestions or help,
  Matt

[bob]

What is the renderer?

[mattlovell]

What is the renderer?

An ODroid C2 running LibreELEC 8.2.0 (Kodi 17).

That's a recent upgrade.  I'm pretty sure I also saw it with a CuBox running earlier LibreELEC releases (likely still Kodi 17).

[mattlovell]

The hiccup could be related to changing renderers (i.e., having just picked the ODroid for playing in JRemote).  Once normal play has been established, picking new albums seems to be working as one would expect.

I'll try to pay more attention over the next couple of days.

[bob]

At least that's something we could try here if you see that it can be consistently reproduced.

[mattlovell]

The hiccup could be related to changing renderers ...

Well, so much for that idea!  Trying to stress test that scenario didn't yield anything.

I did note that JRemote's two views of the playlist (I suppose one is the Playlist Editor and the other is a Now Playing view) easily get out of sync with what's actually going to play next.  That's just with using JRemote alone, without bringing some other controller into play (e.g., selecting something for Kodi to play via its interface).

The next time the single-track playlist behavior crops up, I'll post another update.

[mattlovell]

The next time the single-track playlist behavior crops up, I'll post another update.

The problem occurred again this morning.  Here were the actions I took that led up to it...

• Started JRemote (version 3.25) on the iPad (running iOS 11.1).  The desktop on which MC 23.0.84 runs was asleep, so the initial connection timed out.
• Used JRemote to wake the PC.
• Selecting the PC again in JRemote, connection was successfully made.  Navigated my way to a 4 track album (encoded in Ogg Vorbis, although I don't think that's significant).  The Zone within JRemote already had the ODroid selected (running LibreELEC 8.2).
• In the track view, with the selection mode in "Play All Now", selected the first track.  Playback started ...
• Switched apps on the iPad over to the Yamaha control app to adjust volume.
• Closed the cover on the iPad and started making breakfast (I don't think the meal is significant.  )

The first track was about 8 minutes long.  Upon concluding, playback stopped.  I went and opened the cover on the iPad and switched back from the Yamaha control app to JRemote.  JRemote, in its summary at the bottom of the screen, momentarily showed that it was playing track "1 of 4"; in about a second, though, that summary updated itself to say "1 of 1".  My app switch [at the beginning] was not immediate, since playback had managed to get started.

Of the steps I listed above, perhaps switching away from JRemote is significant?  Somewhere, either in JRemote's control communication to MC or within MC itself, the playlist effectively got truncated.

With MC, the ODroid rendered is associated with JRiver DLNA (rather than the Audiophile server).  None of the other DLNA Controller Options is currently checked/enabled.

[Edit: fixed typos and tried to clarify statements]

[mattlovell]

Returning to this behavior...

The problem only appears to occur upon first waking the music server (Windows 7, MC 23.0.91) up from sleep.  It doesn't seem to matter whether I have JRemote wake up the computer or wake it up via a mouse press.

[bob]

Returning to this behavior...

The problem only appears to occur upon first waking the music server (Windows 7, MC 23.0.91) up from sleep.  It doesn't seem to matter whether I have JRemote wake up the computer or wake it up via a mouse press.

It might be that the renderer list in MC  isn't populated yet when you first wake the server.
A way to test this might be to wake the server and wait a minute or so before starting the playback.

Let us know what you find because there might be a related issue that would have a similar solution.

[AndrewFG]

Just a wild guess here..

It might be due to MC and/or the renderers having changed their IP addresses due to their DHCP leases having expired during the sleep phase. It’s possible even that for a while you might have two devices using the same IP address until they ask for a new one via DHCP. If so try reserving different IP addresses on your router for each renderer and for MC.

[mattlovell]

It might be due to MC and/or the renderers having changed their IP addresses due to their DHCP leases having expired during the sleep phase. ...

The MC PC has a statically assigned IP address.  The ODroid (DLNA renderer) is always awake; it uses DHCP but has a reserved IP in the router.

It might be that the renderer list in MC  isn't populated yet when you first wake the server.

There may be something to that... I have noticed that, if the GUI is started on the PC, the renderer/zone list seems to take a variable amount of time to get populated.  JRemote still seems to have the ODroid listed though (perhaps just because it was the last selected?).

When the behavior occurred this time around, I swear that JRemote's playlist was fully populated (i.e., the whole album was set to play).  I then went about making breakfast when I noticed that Track 1 was playing again.  Going back to the iPad and returning to JRemote, the playlist was truncated (playing 1 of 1 tracks).

[bob]

The MC PC has a statically assigned IP address.  The ODroid (DLNA renderer) is always awake; it uses DHCP but has a reserved IP in the router.

There may be something to that... I have noticed that, if the GUI is started on the PC, the renderer/zone list seems to take a variable amount of time to get populated.  JRemote still seems to have the ODroid listed though (perhaps just because it was the last selected?).

JRemote does remember the last selected zone. You could hit the zone refresh button to see if anything has changed.

When the behavior occurred this time around, I swear that JRemote's playlist was fully populated (i.e., the whole album was set to play).  I then went about making breakfast when I noticed that Track 1 was playing again.  Going back to the iPad and returning to JRemote, the playlist was truncated (playing 1 of 1 tracks).

It really sounds like the renderer was dropped out of the tree, the playlist then becomes invalid and when the first track starts playing the query to the device shows just that track.
The odroid itself can't store a playlist since as a renderer it really only stores one track at a time.

[mattlovell]

JRemote does remember the last selected zone. You could hit the zone refresh button to see if anything has changed. ...
 really sounds like the renderer was dropped out of the tree, the playlist then becomes invalid and when the first track starts playing the query to the device shows just that track.

The next time I'm starting with a sleeping PC, I'll try your recommendation -- do a zone refresh on JRemote and wait for the ODroid to reappear.

This sounds like a good root cause explanation.  The main oddity I see about it is that playback nevertheless starts, even if MC hasn't really gotten its zone list "in order". 

Thanks for everyone's suggestions.

[EDIT: fix typos]

[timwtheov]

I get this same behavior most of the time when I first start JRemote and use it to send audio to my Mede8er: the first song on a playlist will play, but then I have to start the playlist again after the song is finished for the rest of the playlist to keep playing.

[mattlovell]

So, this morning I waited after the PC WoL, refreshing the device list on JRemote until all devices appeared (ODroid, Oppo, AVR, and TV -- so many choices!).  I then started an album with 40 tracks (baroque collection with lots of short tracks).  Playback started and JRemote showed that the ODroid was playing 1 of 40.  The device list had refreshed, showing all the devices that had just turned on (and represent a change from the network state when everything went to sleep last night), so I was expecting no hiccup.

Playback still stopped after the first track.  Opening the iPad cover again, JRemote refreshed itself to show the playlist was just 1 track long.  (If it's relevant, it also showed the ODroid as only part-way through playing that first track.)

After that scenario played out, things are now of course working normally. 

Any other thoughts?

[bob]

So, this morning I waited after the PC WoL, refreshing the device list on JRemote until all devices appeared (ODroid, Oppo, AVR, and TV -- so many choices!).  I then started an album with 40 tracks (baroque collection with lots of short tracks).  Playback started and JRemote showed that the ODroid was playing 1 of 40.  The device list had refreshed, showing all the devices that had just turned on (and represent a change from the network state when everything went to sleep last night), so I was expecting no hiccup.

Playback still stopped after the first track.  Opening the iPad cover again, JRemote refreshed itself to show the playlist was just 1 track long.  (If it's relevant, it also showed the ODroid as only part-way through playing that first track.)

After that scenario played out, things are now of course working normally. 

Any other thoughts?

What are all of your optional settings (server follows app, app follows server, autoconnect, sync play count, etc)?
How short are the sort tracks? Any less than 30 seconds?

[mattlovell]

What are all of your optional settings (server follows app, app follows server, autoconnect, sync play count, etc)?

JRemote 3.25
- Autoconnect to last server on launch: on
- Prevent screen from dimming: off
- Server follows app zone changes: off
- App follows server zone changes: off

- Transcode audio: off
- Audio transcode quality: High (320 Kbps)
- Video quality: High
- ChromeCast quality: High
- Sync play count: on

How short are the sort tracks? Any less than 30 seconds?

No, none less than 30 seconds for this scenario/experiment.  The first track for the 40-track album mentioned in my last post is 1m, 16s long.

[AndrewFG]

You mention that you have an Oppo, AVR, TV, and Odroid. Just for the avoidance of doubt, does it work when you push to the other renderers, and only fail when you push to ODroid?

[mattlovell]

You mention that you have an Oppo, AVR, TV, and Odroid. Just for the avoidance of doubt, does it work when you push to the other renderers, and only fail when you push to ODroid?

I'll try a different renderer the next chance I get.

Based on the above discussion with Bob, though, I thought all playlist state was resident on the MC?

[bob]

I'll try a different renderer the next chance I get.

Based on the above discussion with Bob, though, I thought all playlist state was resident on the MC?

It is.
I can't really see how this could happen with your settings unless the renderer is dropping out of the MC tree for some reason. If that was the case, the playlist would clear and only the current track would be seen when it re-appeared.
Can you monitor MC during this to see if that's the case?

[mattlovell]

I'll try a different renderer the next chance I get.

Well, waking the PC up from sleep, waiting for all zones to appear, and then repeating the album play attempt on the Oppo, the problem did not occur.  I'll continue to try out different renderers.

The DLNA options are different for the two.  The Oppo doesn't support gapless playback, so it has Disable SetNext support checked (enabled). 

The ODroid is running LibreELEC 8.2.1 (featuring Kodi 17.6).  I tend to use it since it does have gapless playback... checking options within MC, though, I think it too has Disable SetNext checked.  Guess I have to repeat everything with that turn off.  That option (for both renderers) is the only item that's checked.

[mattlovell]

I can't really see how this could happen with your settings unless the renderer is dropping out of the MC tree for some reason. If that was the case, the playlist would clear and only the current track would be seen when it re-appeared.
Can you monitor MC during this to see if that's the case?

Will do.  (Unfortunately, work calls for this morning...)

[AndrewFG]

I'll try a different renderer the next chance I get.

Based on the above discussion with Bob, though, I thought all playlist state was resident on the MC?

The playlist is on MC. But the reason why MC is clearing the playlist could be caused by the renderer. I am particularly wondering if ODroid reports it state changes differently than other renderers (which might cause MC to see playing error). If the problem is only with ODroid we need to look at that renderer specifically, whereas if it occurs with other renderers then we need to look at your network topology and configuration..

[mattlovell]

I can't really see how this could happen with your settings unless the renderer is dropping out of the MC tree for some reason. If that was the case, the playlist would clear and only the current track would be seen when it re-appeared.
Can you monitor MC during this to see if that's the case?

Sitting in front of the PC this evening, after waking it up, I was able to repeat the scenario (using the first 1m:16s track from the 40-track album I've mentioned previously).

Looking at the Playing Now overview, I never saw the ODroid (Kodi) drop out.  The playlist for the ODroid immediately populated (with all 40 tracks) when the selection was made on JRemote.  Potentially interestingly, when JRemote updated itself to say playing "1 of 1", there was no change to the MC overview playlist. 

The MC playlist continued to show 40 tracks populated, until I directly clicked on the renderer.  At that moment, it then switched to the zone/device view for ODroid and showed a (completed) playlist of just 1 track (effectively matching what JRemote was showing).

So, no obvious drop-out of the renderer, but continued weirdness regarding the population of the playlist.

[AndrewFG]

As I said before please test with another of your renderers.

[mattlovell]

As I said before please test with another of your renderers.

I did try yesterday morning, with the Oppo (see above).  The stop-after-a-single-track problem did not occur, but that experiment was after forcing the PC to enter sleep.  I'm not positive the problem recurs with such a forced sleep.  So, trying again this morning...

After waking, MC didn't immediately see the Oppo, despite waiting for a while.  (Since networking might come up, all of the renderers have wired connections to an Asus switch in the living room, which in turn is hardwired to the switch in the study that the PC uses.)  So, I ended up trying the Yamaha AVR instead.  The problem did not occur.

(The Oppo eventually did appear in MC, after 4 minutes or so.)

Neither the Yamaha nor the Oppo support gapless playback.  Unfortunately, since I don't usually play through them, it has been a while since I examined their DLNA Options in the MC.  The Oppo has Disable SetNext checked, whereas the Yamaha does not.  No other Options are enabled for any of the renderers tried thus far.

As you might tell from the long gaps between my posts on this thread, this hiccup doesn't always manifest itself.  The best I've been able to isolate it to is just after waking the PC.  So, the single Oppo and Yamaha results are interesting, but I'm not sure they are definitive yet.  I'll keep trying, switching renderers, as I get the chance.

The ODroid C2 is running LibreELEC 8.2.1, which uses Kodi 17.6.  It always remains on.  I would think Kodi is a fairly common renderer and, in my limited experience, it has certainly seemed to be more "compliant" than any commercial DLNA renderers (e.g., gapless playback, wide support for varying codecs).  If it is a status reporting hiccup with Kodi, it certainly is a corner case.

The Oppo is a UDP-203.  The Yamaha is an RX-A1040.

[AndrewFG]

The following is a speculation..

There are two ways for MC to discover a renderer — namely 1) MC broadcasts a search command “M-Search” and the renderer replies by a mono cast response message, and 2) the renderer advertises its presence via a broadcast “NOTIFY Alive” message.

My speculation is that your LAN may be configured such that the mono cast response to method 1) is not getting through; so MC has to fallback to method 2) discovery. This takes longer, is more open to error, and more likely to result in dropouts.

To debug this, it would help if you can inform us about your LAN topology; routers, switches, Ethernet connections, WiFi connections, bridges, firewalls, etc.

[mattlovell]

To debug this, it would help if you can inform us about your LAN topology; routers, switches, Ethernet connections, WiFi connections, bridges, firewalls, etc.

Note that the single-track-play hiccup is quite sporadic.  The slow discovery, OTOH, has long been present.

The PC on which MC runs is connected (wired) to an Asus router.  Another port of that router goes, via CAT5e cable, to an unmanaged 8-port switch in the living room.  The 8-port switch in question is the following (TRENDnet):

   https://www.amazon.com/gp/product/B001QUA6RA/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

The ODroid C2, and all of the other renderers for that matter, are plugged into that 8-port switch.  That's it.

The PC runs Windows 7 Ultimate, with Microsoft Defender (no other anti-virus).  JRMC23 is permitted through the firewall (public & private, per the standard controls that result from searching for "firewall" in the start menu).

Several months ago, when first testing the newly-installed cable from the study to the living room, I had a full distro of Linux running on the ODroid.  It was able to achieve >500 Mbps to the desktop (also running Linux for that test).

[AndrewFG]

^
Hmm. It looks pretty clean to me. How are the IP addresses given out (static, or DHCP), and is there a possibility that you have more than one device sharing the same IP address?

[mattlovell]

Hmm. It looks pretty clean to me. How are the IP addresses given out (static, or DHCP), and is there a possibility that you have more than one device sharing the same IP address?

I think Bob asked about that earlier...

The PC has a static IP address.  All other devices get their IP via DHCP, but I think they all have reservations.  (Only the DHCP server on the router to which the PC is attached is active; the DHCP range excludes the PC's static IP.) 

What should the the M-search broadcast look like on the network?  I have wireshark, so I should be able to peek and see what's going on if I know what to look for.

Tried the single-track experiment again this morning with the Oppo.  Playback got to Track 2 without any issue.

[mattlovell]

In case it's useful, here's what WhiteBear has to say about the Kodi installation on the ODroid:


Device Description Url   http://10.0.0.172:1834/
HTTP Server Header   UPnP/1.0 DLNADOC/1.50 Platinum/1.0.5.13
Description   Kodi - Media Renderer
Friendly Name   Kodi (ODroid)
Manufacturer Name   XBMC Foundation
Manufacturer Url   http://kodi.tv/
Model Name   Kodi
Model Number   17.6 Git:a9a7a20
Model Url   http://kodi.tv/
Presentation Url   http://10.0.0.172:8080/
UPnP Device Type   urn:schemas-upnp-org:device:MediaRenderer:1
UPnP Media Renderer version   1
Unique Device Name   uuid:084dcfa9-a863-17ed-a9b0-e234af304564
X_DLNADOC Element   DMR-1.50
Service Url for AVTransport   http://10.0.0.172:1834/AVTransport/084dcfa9-a863-17ed-a9b0-e234af304564/scpd.xml
Service Url for ConnectionManager   http://10.0.0.172:1834/ConnectionManager/084dcfa9-a863-17ed-a9b0-e234af304564/scpd.xml
Service Url for RenderingControl   http://10.0.0.172:1834/RenderingControl/084dcfa9-a863-17ed-a9b0-e234af304564/scpd.xml
AVT:GetDeviceCapabilities action   Supported
AVT:GetMediaInfo action   Supported
AVT:GetPositionInfo action   Supported
AVT:GetTransportInfo action   Supported
AVT:GetTransportSettings action   Supported
AVT:SetNextAVTransportURI (gapless play)   Supported
AVT:SyncPlay (synchronous play)   NOT Supported
RC:GetVolume action   Supported
RC:SetVolume action   Supported
AVT:Event Subscription   Succeeded
RC:Event Subscription   Succeeded
HTTP User Agent (client)   Microsoft-Windows-XP/2002, UPnP/1.1, JRiver Internet Reader/2.0 (compatible; Windows-Media-Player/10)
Play test file result   Play success => Start Ok / Stop Ok

[AndrewFG]

I think Bob asked about that earlier...

The PC has a static IP address.  All other devices get their IP via DHCP, but I think they all have reservations.  (Only the DHCP server on the router to which the PC is attached is active; the DHCP range excludes the PC's static IP.) 

What should the the M-search broadcast look like on the network?  I have wireshark, so I should be able to peek and see what's going on if I know what to look for.

Tried the single-track experiment again this morning with the Oppo.  Playback got to Track 2 without any issue.

I would check the one with the static IP address, some routers don’t route traffic from devices they don’t “own”. So instead of setting it static, try using DHCP instead with a reservation on the router..

(The M-Search traffic looks similar to an HTTP call with the word M-Search as the method. And the responses look similar with the word NOTIFY as the method.)

PS the DMRA report looks clean.

[mattlovell]

I would check the one with the static IP address, some routers don’t route traffic from devices they don’t “own”. So instead of setting it static, try using DHCP instead with a reservation on the router..

I wasn't aware of that.  I've switched to a DHCP reservation, and DNLA discovery does seem to be occurring faster!  I wonder if the router was the source of this hiccup all along (updating or not updating its routing appropriately when the PC first woke back up from sleep).

Seems like a good excuse to just stay home and listen to more music... er, I mean try more experiments! 

[mattlovell]

I wasn't aware of that.  I've switched to a DHCP reservation, and DNLA discovery does seem to be occurring faster!

I was having some issues with the PC truly going to sleep... thus, there was a delay in trying the scenario again.

This morning, waking the PC via JRemote, and picking a whole album for the ODroid/Kodi to play, playback stopped after the 5m52s first track.

The AVR had not yet appeared as a zone in JRemote.  The responsive/appearance of a different renderer shouldn't affect the playlist for an existing one, though, should it?

Events from the JRiver audiophile DLNA server are below.  Those seem normal:
24174   6:16 am   Finished   127.0.0.1   GET: http://127.0.0.1:52100/DeviceDescription.xml   3.1 KB   0:00.004
24175   6:16 am   Finished   127.0.0.1   GET: http://127.0.0.1:52100/ContentDirectory/scpd.xml   11.1 KB   0:00.001
24176   6:16 am   Finished   127.0.0.1   GET: http://127.0.0.1:52100/ConnectionManager/scpd.xml   3.6 KB   0:00.000
24292   6:16 am   Finished   10.0.0.174   GET: http://10.0.0.3:52100/DeviceDescription.xml   3.1 KB   0:00.002
24316   6:16 am   Finished   10.0.0.174   GET: http://10.0.0.3:52100/ContentDirectory/scpd.xml   11.1 KB   0:00.000
24317   6:16 am   Finished   10.0.0.172   GET: http://10.0.0.3:52100/DeviceDescription.xml   3.1 KB   0:00.002
24323   6:16 am   Finished   10.0.0.174   GET: http://10.0.0.3:52100/ConnectionManager/scpd.xml   3.6 KB   0:00.000
24325   6:16 am   Finished   10.0.0.172   GET: http://10.0.0.3:52100/ContentDirectory/scpd.xml   11.1 KB   0:00.001
24326   6:16 am   Finished   10.0.0.172   GET: http://10.0.0.3:52100/ConnectionManager/scpd.xml   3.6 KB   0:00.000
24327   6:16 am   Finished   10.0.0.172   SUBSCRIBE: http://10.0.0.3:52100/ContentDirectory/event   0 bytes   0:00.000
24328   6:16 am   Finished   10.0.0.172   SUBSCRIBE: http://10.0.0.3:52100/ConnectionManager/event   0 bytes   0:00.000
24359   6:17 am   Finished   10.0.0.174   POST: http://10.0.0.3:52100/ContentDirectory/control   553 bytes   0:00.000
24363   6:17 am   Finished   10.0.0.174   POST: http://10.0.0.3:52100/ContentDirectory/control   438 bytes   0:00.000
24421   6:17 am   Finished   10.0.0.3   GET: http://10.0.0.3:52100/DeviceDescription.xml   947 bytes   0:00.002
24434   6:17 am   Finished   10.0.0.172   HEAD: http://10.0.0.3:52100/Music/F1229351.m4a   0 bytes   0:00.078
24435   6:17 am   Finished   10.0.0.172   GET: http://10.0.0.3:52100/Music/F1229351.m4a   128 KB   0:00.001
24436   6:17 am   Finished   10.0.0.172   GET: http://10.0.0.3:52100/Music/F1229351.m4a   29.3 MB   1:50.772
24442   6:17 am   Finished   10.0.0.172   HEAD: http://10.0.0.3:52100/Music/F1229351.m4a   0 bytes   0:00.000
24443   6:17 am   Finished   10.0.0.172   HEAD: http://10.0.0.3:52100/Music/F1229351.m4a   0 bytes   0:00.000
25462   6:26 am   Finished   127.0.0.1   GET: http://10.0.0.3:52100/DeviceDescription.xml   3.1 KB   0:00.005
25464   6:26 am   Finished   10.0.0.3   GET: http://10.0.0.3:52100/Icon/5   4.2 KB   0:00.006
25867   6:30 am   Finished   127.0.0.1   GET: http://192.168.56.1:52100/DeviceDescription.xml   3.1 KB   0:00.005
25868   6:30 am   Finished   192.168.56.1   GET: http://192.168.56.1:52100/Icon/5   4.2 KB   0:00.003
26033   6:32 am   Finished   127.0.0.1   GET: http://192.168.56.1:52100/DeviceDescription.xml   3.1 KB   0:00.005
26034   6:32 am   Finished   192.168.56.1   GET: http://192.168.56.1:52100/Icon/5   4.2 KB   0:00.006
26456   6:36 am   Finished   127.0.0.1   GET: http://192.168.56.1:52100/DeviceDescription.xml   3.1 KB   0:00.006
26457   6:36 am   Finished   192.168.56.1   GET: http://192.168.56.1:52100/Icon/5   4.2 KB   0:00.004
26459   6:36 am   Finished   10.0.0.79   GET: http://10.0.0.3:52100/DeviceDescription.xml   3.1 KB   0:00.002
26468   6:36 am   Finished   10.0.0.79   SUBSCRIBE: http://10.0.0.3:52100/ContentDirectory/event   0 bytes   0:00.000
26471   6:36 am   Finished   10.0.0.79   POST: http://10.0.0.3:52100/ContentDirectory/control   553 bytes   0:00.001
26472   6:36 am   Finished   10.0.0.79   POST: http://10.0.0.3:52100/ContentDirectory/control   438 bytes   0:00.001

[mattlovell]

This morning, waking the PC via JRemote, and picking a whole album for the ODroid/Kodi to play, playback stopped after the 5m52s first track.

So, I was able to repeat the experiment this morning with a bit more patience.  Don't know if the symptoms below help point to anything or not, but I'll describe them nevertheless...

After waking the PC with JRemote, I kept hitting refresh on the device list, waiting for the (just turned-on) AVR to appear.  For one of these refreshes, the ODroid/Kodi box did drop out (leaving just "This Device" and "Player" in JRemote's list).

When this happened, ODroid was still the selected device within JRemote.  It had previously been showing (down in the lower corner) the Mozart album that was indeed the last item played on that renderer.  When the ODroid/Kodi dropped out of JRemote's shown device list, that album cover disappeared, to be replaced with the typical "blank, no cover" display.

Shortly after that, the ODroid and the AVR both appeared in the device list.  So, I thought I would start playing (back to the Bach album of piano inventions that has that 1 minute+ first track).

Playback started.  The first track finished and the second track started playing.  Looking at JRemote, though, the playback status during this second track was quite odd!  It showed playing "0 of 1", with an accurate time for that second track, but all of the remaining info still reflecting the first track.

Going over to JRiver on the PC, it's overview of the ODroid/Kodi renderer was pretty similar -- playing 0 of 1.  The playlist for that renderer was somewhat "broken" in the GUI as well, with the name of the first track appearing at the bottom of a short list of repeated text. 

Following the conclusion of that second track, playback then went back to the first track.  Now, both JRemote and the JRiver GUI showed playing "1 of 1".  Playback stopped after this repeat of the album's first track.

Hopefully, the above might give some clue what's going on regarding both JRiver & JRemote's joint state regarding that renderer. 

There's definitely something to be said for waiting for "network stability" after waking the PC.  I thought I did that this morning, though, and ended up with even weirder results than before! 

[mattlovell]

Playback started.  The first track finished and the second track started playing.  Looking at JRemote, though, the playback status during this second track was quite odd!  It showed playing "0 of 1", with an accurate time for that second track, but all of the remaining info still reflecting the first track.

Oh, I should also remind you that SetNext support was turned back on for the ODroid/Kodi renderer.  It had inadvertently been disabled sometime earlier, back when this thread was first started.

It looks like SetNext had been sent at some point, given the behavior I observed.  Not sure why the first track then repeated (unless it was a consequence of JRiver being able to increment the now-playing Track 0 to 1 and thinking, "why I indeed have another track to play").

[botte]

Just adding my two cents,

I have the same issue, I’m using the bel canto ex dac and a moode Audio renderer and they both suffer from this issue. It was not a problem a few revs ago.

Thanks,

[JimH]

In MC, right click on the DLNA Renderer, and try toggling SetNextAVTransport.

AndrewFG is the expert on this.  He's posted above.

[mattlovell]

In MC, right click on the DLNA Renderer, and try toggling SetNextAVTransport.

AndrewFG is the expert on this.  He's posted above.

The thread is getting somewhat long, but the problem occurs with either state of "Disable SetNextAVTransport".  Since Kodi does support SetNextAVTransport, the behavior of the hiccup changes depending upon whether or not JRiver sends that message.
 

[JimH]

Without re-reading this thread, did you try AndrewFG's DMRA tool against Kodi?

[mattlovell]

Without re-reading this thread, did you try AndrewFG's DMRA tool against Kodi?

Yes.

On January 19, 2018, AndrewFG wrote:

PS the DMRA report looks clean.

[botte]

Not sure if this is related but another thing that showed up at the same time is that the repeat playlist some times just stops at the last track rather than looping back to the top of the playlist.

[bob]

Just adding my two cents,

I have the same issue, I’m using the bel canto ex dac and a moode Audio renderer and they both suffer from this issue. It was not a problem a few revs ago.

Thanks,

The DLNA controller code was completely rewritten around version 23.0.82.
Would you try an earlier build and see if the problem still exists?

[mattlovell]

The DLNA controller code was completely rewritten around version 23.0.82.
Would you try an earlier build and see if the problem still exists?

Where does one find older MC releases?  Also, is there a full version history available.  (I should have noted the JRiver version when I started this thread back in December; the release history would illuminate what version I was likely running at the time.)

I feel like I've seen this problem for a while.  Certainly, I think my previous Windows firewall settings were serving to prevent the M-Search broadcasts, likely leading to hiccups such as that discussed in this earlier thread, on MC 22:

https://yabb.jriver.com/interact/index.php/topic,107509.msg747171.html#msg747171

[bob]

Where does one find older MC releases?  Also, is there a full version history available.  (I should have noted the JRiver version when I started this thread back in December; the release history would illuminate what version I was likely running at the time.)

I feel like I've seen this problem for a while.  Certainly, I think my previous Windows firewall settings were serving to prevent the M-Search broadcasts, likely leading to hiccups such as that discussed in this earlier thread, on MC 22:

https://yabb.jriver.com/interact/index.php/topic,107509.msg747171.html#msg747171

I don't think the link points to the same issue.
What I'm wondering is if the DLNA controller changes make any difference to the behavior you are seeing.
There are a lot of variables here with the sleep mode and renderer and controller code. It'd be useful to try and eliminate one of them.
https://yabb.jriver.com/interact/index.php/topic,113043.0.html
is a link to 23.0.80 the closest publically available build. You can just page back in the forum to find these.

[mattlovell]

Thanks for the pointer to the old release announcement.

Yes, I was able to reproduce the issue with 23.0.80.

After installing the older version, I cleared all playlists and let the server sleep for 2 hours.  Upon waking it via JRemote and starting an album, playback stopped after 1 track (and the playlists on both JRemote and the JRiver GUI updated to reflect just that single track).

So, the hiccup appears present even in the older version of the DLNA server.  Both the Yamaha AVR and ODroid/Kodi were left on while the server was in sleep.  Also, the windows firewall change (discussed earlier in this tread) is still in-effect (permitting M-Search broadcasts to be successful).  It must either be something unique about JRiver's resumption following sleep -or- some interaction between the PC and the router to which it is attached (Asus RT-AC1750, up-to-date firmware).

[bob]

Thanks for the pointer to the old release announcement.

Yes, I was able to reproduce the issue with 23.0.80.

After installing the older version, I cleared all playlists and let the server sleep for 2 hours.  Upon waking it via JRemote and starting an album, playback stopped after 1 track (and the playlists on both JRemote and the JRiver GUI updated to reflect just that single track).

So, the hiccup appears present even in the older version of the DLNA server.  Both the Yamaha AVR and ODroid/Kodi were left on while the server was in sleep.  Also, the windows firewall change (discussed earlier in this tread) is still in-effect (permitting M-Search broadcasts to be successful).  It must either be something unique about JRiver's resumption following sleep -or- some interaction between the PC and the router to which it is attached (Asus RT-AC1750, up-to-date firmware).

Thanks for testing it.
I'm guessing this will need something like a sticky DLNA renderer zone so that the zone doesn't become inactive on sleep. I'm thinking part of the issue is that MC is subscribed to receive events from the renderer but that doesn't happen when the PC is happening and I suppose the render thinks the server is dead then.