Print

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

[markf2748]

Long delays for MC to find Chromecast Audio DLNA zones created by BubbleUPnP have been aggravating me for at least a year.  I describe reproducible conditions in detail, hoping these delays can be eliminated.

System:  MC 28.0.66 (64-bit) running on an Intel NUC 8i5BEH, Windows 10 Pro up to date.  Media Center 28 Service runs as a Win10 service (Startup automatic).  The NUC uses its built-in Intel Wireless-AC 9560 160MHz set up for WiFi WOL.  Two original Google Chromecast Audio pucks (CAs).

Router:  NETGEAR R6220 WiFi dual band router.  CAs installed on 2.4GHz band (for strongest signal) and NUC on 5GHz band Mode 802.11ac (for highest speed).  Same problem if all are installed on 5GHz band.  All network devices of interest - computers, CAs, phones, printer - are assigned static IP addresses.  Router UPnP Advertisement Period = 1 minute (previously 30m).  Advertisement Time to Live (in hops) = 6 (previously 4).  UPnP Port Map is empty.  Since I do not access my home network from the internet,there is no need to add custom port forwarding.  NETGEAR AC1200 Dual Band WiFi Range Extender is present, but not used by any of the audio computers or CAs.

Sleep Settings:  Windows > Power & Sleep > Change when the computer sleeps > Change advanced power settings > Sleep > …
…Allow hybrid sleep > Setting:  Off
…Hibernate after > Setting:  Never

BubbleUPnP Server:  Version 0.9 Update 41 runs on the NUC, enabling MC to play to the CA (DLNA) devices.
BubbleUPnP is up 100% of the time, always seeing both CAs and maintaining their CA (DLNA) versions on the network.  A Google Chrome web browser by itself always sees CAs in its Cast window.

Android BubbleUPnP App:  The phone app always sees Chromecast CAs and CA (DLNA) when the NUC is awake, whether visible in MC zones or not.  This app can always play to the CAs and CA (DLNA), and can always select media from the MC Library, even when CA (DLNA) zones are absent from MC server.   
 
The Issue:  The system works really well, except when it doesn’t.  That is, if the MC Server PC goes to sleep for an extended time, then when it wakes up MC takes approximately 15-18 minutes to find the CA (DLNA) zones. 

Android JRemote2 App:  JRemote2 has nothing to do with this problem, but it needs CA (DLNA) zones to be visible on the server to play.  I connect using the JRemote2 Device selection menu (JRemote2’s Cast icon is totally buggy). 

JRiver MC:  Small library of 5,100 audio tracks, nearly all 16/44.1 flac.

I tried four sets of MC’s DLNA Controller Options out of the 2^4 = 16 possible combinations:
1) Ignore Transport Events (use polling mode)
2) Disable SetNext Support (for broken renderers)
3) Ignore Get Position Failure (for broken renderers)
4) Disable Other Controller Detection (for broken renderers)

Tested sets:  2;  2+4;  2+3+4;  1+2+3+4.  None of these solved the problem.

A Win10 command window lists the process IDs using Port 1900 (needed for UPnP).  Typical:

C:\WINDOWS\system32>netstat -ano | find ":1900"
  UDP    0.0.0.0:1900                                 *:*     14428   [Media Center 28.exe]
  UDP    0.0.0.0:1900                                 *:*       4076   [BubbleUPnPServer.exe]
  UDP    127.0.0.1:1900                             *:*       4696   [svchost.exe SSDPSRV (SSDP Discovery)]
  UDP    192.168.1.8:1900                          *:*      4696   [svchost.exe SSDPSRV (SSDP Discovery)]
  UDP    [::1]:1900                                     *:*      4696   [svchost.exe SSDPSRV (SSDP Discovery)]
  UDP    [fe80::xxx:xxxx:xxx:xxxxx]:1900  *:*      4696   [svchost.exe SSDPSRV (SSDP Discovery)]

PIDs live for days, from running, to sleep, to wake up, logout/login, except Media Center 28.exe PID renews after logout/login. 

MC Services & Plug-Ins > Media Network, reports “4 (or 5) servers (all running normally)”, but generally having different uptimes:

Uptime always restarts after wake up from sleep and logout/login cycle for:
Device Discovery server (SSDP)
DLNA Subscription server (may be delayed, but does not seem to impact CA (DLNA) zones)

Uptime is continuous through multiple days, including through sleep/wakeup cycles.  Uptime is reset after logout/login cycle:
DLNA Media renderer
DLNA Media server
DLNA Library server

Root Cause?  Is MC’s Device Discovery server (SSDP) responsible for MC’s CA (DLNA) zone discovery delay after wakeup?  CA (DLNA) zones appear in MC when this server has been up for 14-18 minutes after wake up from a “long sleep” or after a logout/login cycle.  (I don’t know the minimum “long sleep”, but long delay is certainly there if sleep exceeds 1 hour.  There is little to no delay for a few minutes sleep.)

Since the issue appears when the other MC servers’ uptimes are not reset, I tend to believe they do not play a role.

Can MC’s Device Discovery server (SSDP) be modified so it stays up while the PC sleeps, just like the other three primary MC servers?
Other ideas? A network issue? 

References:
https://yabb.jriver.com/interact/index.php?topic=95540.0
https://yabb.jriver.com/interact/index.php?topic=109481.0
https://yabb.jriver.com/interact/index.php?topic=117626.0

[JimH]

JRiver MC doesn't support Chromecast.  You're using Bubble as a shim to get around that.  It isn't working for you.  If MC isn't finding a DLNA zone, it isn't there.

You might try using an SSDP utility to see what happens.

[markf2748]

Thanks Jim.  Whitebear's DMR Analyzer normally finds the CA (DLNA) renderers.  However I have not run DMRA when MC has not yet found them.  Will try that the next time I encounter the delay issue.

foobar2000 also plays to the CA (DLNA) renderers.  So I will also check with it the next time I encounter the delay issue.

I don't know of any other high level Win10 SSDP utilities.

[markf2748]

I think today’s test definitively points to an issue with MC’s DLNA discovery, at least in my environment.

Test:  PC slept overnight for 8h 47m.  I wake it up and start MC.

MC takes 15 minutes before it shows two CA (DLNA) zones, as described in OP, and the same as I have seen repeatedly before. 

After starting MC, I start Whitebear DMRA which finds the two CA (DLNA) devices after its normal 20 second search time. 

I close Whitebear, and then fire up foobar2000 which plays normally to one of the CA (DLNA) devices, while MC still shows no CA (DLNA) zones for the next ~12 minutes.

Additional observations:
MC’s Media Network window always reports all five servers running normally.  Consistent with OP, four of MC’s five servers show an uptime of 24.4h. 

MC Device Discovery Server uptime has restarted and displays minutes since MC was opened.  The server always shows a stream of activity with normal looking NOTIFY: and M-SEARCH: in the Resource column.

Examination of Win10 Event Manager shows nothing unusual in the last 24 hours.  Zero Critical Errors.  Only 3 Error Events, all of them hours before the sleep period.  The only Warnings are the usual DistributedCOM 10016 which generally are safe to ignore.

Although I have not rebooted the NUC today, 100% of the time MC finds the CA (DLNA) immediately, with no delay, after a reboot.

Comments:  The NUC serves double duty – it is both my main office desktop PC as well as a music server.  It has more than enough horsepower to do both simultaneously since I play mainly 16/44.1 flacs and do little to no DSP.  I have never noticed any degradation in music quality, including through my desktop USB DAC / powered speakers while doing typical desktop work.  I prefer to let the NUC sleep when not in use, and then wake it up over WiFi WOL if I need to play music anywhere.

I have come very close to investing in Raspberry Pi technology to replace the Chromecast Audio dongles, as I have long suspected they were the issue.  Now I am left wondering if I would experience the very same wake up issues with a R Pi DLNA renderer that does not depend on BubbleUPnP.

[AndrewFG]

^
mark, FWIW I too find that on occasion MC is slow discovering UPNP devices.. I have been seeing this issue for literally years, but have never been able to accurately put my finger on the reasons why. AFAICT MC does both execute SSDP M-SEARCH and respond to SSDP NOTIFY, but sometimes it seems to miss the UDP responses to one or the other. It is very ephemeral and to track it down I would probably have to run MC in a debugger (which ain’t gonna happen). My only advice is to use reserved IP addresses on all devices, which seems to ameliorate things, but again I don’t know why..

[AndrewFG]

^
Perhaps to add to the above:

1. MC executes M-SEARCH periodically at an interval that depends on MC (although I don’t think there is an actual setting for that interval). I have a feeling that if sometimes the initial M-SEARCH on MC startup fails, you may need to wait a whole interval before it might once more find the device. So perhaps a “Refresh” button to trigger M-SEARCH sooner might be a good feature request?? (Or a setting to shorten the interval?)

2. By contrast MC should respond to SSDP NOTIFY ALIVE messages asynchronously, so if a device comes online between the M-SEARCH intervals, it should also get discovered by MC. But I have a suspicion that in this case MC only (re) discovers devices that it already knows about?

[markf2748]

^
mark, FWIW I too find that on occasion MC is slow discovering UPNP devices.. I have been seeing this issue for literally years, but have never been able to accurately put my finger on the reasons why. AFAICT MC does both execute SSDP M-SEARCH and respond to SSDP NOTIFY, but sometimes it seems to miss the UDP responses to one or the other. It is very ephemeral and to track it down I would probably have to run MC in a debugger (which ain’t gonna happen). My only advice is to use reserved IP addresses on all devices, which seems to ameliorate things, but again I don’t know why..

Andrew - thanks much for your acknowledgement.  It has taken me hours upon hours to identify exactly the circumstances under which this issue occurs, especially since it now happens reliably only after a long sleep period.  As stated in OP, I currently use all static IP addresses.  I too had the distinct impression that converting to static IPs helped matters, but did not resolve it entirely.  I am a little less sure about putting the CAs on the 2.4GHz band, but I think it also helped.  The WiFi load is so incredibly small for 2 channel stereo that logically I think you win with higher signal strength and lower bandwidth for a CA dongle.  Up until recently, I also had minim server running in the background, which added two javaw.exe processes to Port 1900.  Disabling minim server may have also helped some.  With each modification I euphorically felt I had it solved, but turns out not so.

After MC discovers the CAs (which takes patience on the part of the user if the NUC has been sleeping!), the system usually works perfectly all day long, until the NUC goes to sleep for a significant time (~1h).  Then wash, rinse, and repeat.

Occasionally (rarely) MC will lose the zones without the NUC sleeping.  The last time I saw this, all messaging in Media Network came to a halt.  In this case I could still play to CAs using the Android BubbleUPnP app to make selections from the MC library and the phone shows up as zone when I do that.  But JRemote2 does not see any CA (DLNA) zones to play to.

I have seen the CAs disappear entirely from the network when there is a Windows 10 update notice sitting in Windows All Settings > Update & Security.  But it is a known off-normal phenomena that such innocent looking notices can step all over a PC's network communications.

My money is on some kind of initialization difference or process memory/cache refresh difference between when Device discovery server (DLNA) first starts up vs when it resumes from long sleep.  The symptoms certainly point in that direction.

^
1. MC executes M-SEARCH periodically at an interval that depends on MC (although I don’t think there is an actual setting for that interval). I have a feeling that if sometimes the initial M-SEARCH on MC startup fails, you may need to wait a whole interval before it might once more find the device. So perhaps a “Refresh” button to trigger M-SEARCH sooner might be a good feature request?? (Or a setting to shorten the interval?)

I see a nearly continuous stream of NOTIFY and M-SEARCH activity from the Device discovery server (SSDP) during that whole time when MC has not yet found CA (DLNA), per the Media Network window.
IMPORTANT UPDATE:  NOTIFY yes, but M-SEARCH were sourced from another computer on the network (not the NUC).   That computer was doing rapid fire SSDP discovery and after it's SSDP Discovery service was disabled, all the M-SEARCH packets disappeared.

^
2. By contrast MC should respond to SSDP NOTIFY ALIVE messages asynchronously, so if a device comes online between the M-SEARCH intervals, it should also get discovered by MC. But I have a suspicion that in this case MC only (re) discovers devices that it already knows about?

My only network rederers are the two CAs, plus my Android phone when I use a controller app on it. The phone gets discovered when I run a music app.  Both CAs are always powered on.  When MC is working normally, the CAs get discovered "immediately", as long as they are powered.  Powering cycling a CA off/on is normally reflected in the respective MC zone quickly disappearing and then returning, i.e. it is an example of a device known to the current session getting "rediscovered".
UPDATE:  Andrew, I think you are essentially correct.  See hypothesis & test in my next post (Reply #7).  Thanks.

I am guessing there are many other users experiencing similar behavior, but they have not nailed down the circumstances and so just tolerate it as some kind of unknown instability.  There certainly have been reports of other products working well when MC fails discovery.

[markf2748]

Current working hypothesis
CA (DLNA) only get discovered by a DLNA server (such as MC or Whitebear DMRA) when the server broadcasts a SSDP M-SEARCH packet.  Then a response from the CA (DLNA) allows the server to further communicate without requiring any more M-SEARCH packets i.e. the CA (DLNA) renderer has become "known" to the server.

Note 1 - I disabled SSDP discovery service on a non-music laptop to clean up the network traffic.
Note 2 -As seen before, the CA (DLNA) discovery delay can occur after a logout/login cycle if there has been no prior discovery.

Test
1) Set up MC with DLNA Controller Options 2+3+4.
2) Log out / log in to my user account.
3) Start Wireshark on the NUC with packet collection filters for WiFi udp.  Display the packet collection with additional filtering for SSDP + M-SEARCH. 
4) Start up MC, which does not display CA (DLNA) zones for about 15 minutes.
5) When CA (DLNA) zones appear, check Wireshark - et voila the first set of three M-SEARCH packets are found at about the same time as MC zones first show up.
6) Start up Whitebear DMRA, which detects CA (DLNA) devices during it's initial 20 second search.  Check Wireshark ... Et voila - there is a second set of three M-SEARCH packets found during the DMRA search.
7) The M-SEARCH packets detected by Wireshark also appear in MC's Media Network running log, with about the same timestamps, so there is detection consistency.
8] Note that throughout this test, both the router and MC broadcast high density bursts of NOTIFY packets, but they apparently have no impact on discovery until after an M-SEARCH packet was sent.
9 ) Wireshark continued to run for another hour with no additional M-SEARCH packets detected.

Conclusion
These are pretty darn convincing first results which confirm the hypothesis.

Crux of the matter:  Why is MC's interval between broadcasting SSDP M-SEARCH packets sometimes extended, and what can be done about it in order to obtain consistent fast DLNA discovery?

After a long PC sleep, MC appears to "forget" previous discovery (cache expires?).  In some instances initial fast discovery is missed altogether.  This test suggests that either one of Andrew's feature request ideas (1. in Reply #5) should help solve these problems. 

If anyone cares to see other packets, has ideas for additional experiments, or beta test I would be happy to oblige.  Meanwhile I will repeat for consistency.

[AndrewFG]

^
+

[markf2748]

^
+

Hi Andrew, thanks for your continued interest.

This morning, after NUC in long uninterrupted sleep last night (unlike me), I woke it using wired USB mouse.  Then opened running MC from taskbar.  All CA (DLNA) zones ok with no apparent delay to human user.

I repeated wired mouse wakeup with same results this evening, capturing the data shown in attached figures.  MC's Device discovery server (DLNA) started close to the wakeup time.  Wireshark detected M-SEARCH packets nearly coincident with the Win10 wake up and again one minute later.  Note:  Event Manager shows Wireless as the Wake Source Device, likely because DLNA is operating on the WiFi Interface.

Will test further with WOL.

[markf2748]

A Workaround
With BubbleUPnP installed as a windows service, modify its configuration file (after saving a backup): 
C:\Programs (x86)\BubbleUPnP Server\configuration.xml
Change the blastAliveInterval value from 0 (default = disabled, results in 15 minute blast intervals with MC) to 30 (minimum allowed blast interval in seconds):

<blastAliveInterval>30</blastAliveInterval>

This causes BubbleUPnP to broadcast Bubble labeled SSDP NOTIFY packets every 30 seconds, resulting in faster, reliable (so far) CA (DLNA) discovery by MC. If you are patient, the period can of course be increased, lowering traffic.

Bubble's burst period can also be customized using a startup command line option, according to their documentation:
https://www.bubblesoftapps.com/bubbleupnpserver2/docs/config_advanced.html

Discussion
I have found no real downsides at this point.  Seems to be a necessary change for reliable discovery speedup, at least until JRiver makes its Bubble discovery more robust.

Wireshark showed that by default, with MC, BubbleUPnP sent out SSDP NOTIFY packets for the CAs every 15 minutes.  If I was lucky and caught the first burst when opening MC (it happens sometimes, either by wired mouse or WiFi WOL), then the CA (DLNA) zones appeared immediately.  More often, I had to wait for the next burst, after which the zones appear. 

SSDP M-SEARCH packets are sourced by MC's Device discovery server (DLNA) at irregular intervals, but apparently they are not always effective for Bubble discovery.  It seems the first M-SEARCH packets always follow Bubble labeled NOTIFY packets, rather than the other way around.  Eventually MC's M-SEARCH packets disappear for a long time after the CAs have been discovered.  The regular Bubble bursts continue on indefinitely.

It's easy to see precise millisecond timing relative to wake from sleep by looking at the wake up event time in Windows Event Manager (illustrated in my Post #9 above).

Wireshark settings
Interface:  Wi-Fi
Collection Filter:  udp
Display Filter:  (http.request.method == "NOTIFY") && (frame matches "BubbleUPnPServer")

Other useful Display Filters:
(ip.addr eq w.x.y.z) && (http.request.method == "M-SEARCH")
(ip.addr eq j.k.l.m)     [reveals all Google Chromecast packets]
ssdp                         [reveals all SSDP packets]
etc.

where
w.x.y.z = ip address of your MC server
j.k.l.m = ip address of your CA

Note: After all this my WiFi WOL stopped working!  Go figure.  I dropped back 2 WiFi driver versions and all seems to be ok now.  Wireshark detected wol magic packets getting through for every driver.  No idea what's going on there. (I suppose this raises the question, was the WiFi driver a factor all along?  Unlikely, since I did occasionally see the delay issue with a wired mouse, and WOL had been working very reliably for a long time, so I think MC discovery still needs to be addressed.)

High hopes this time around.  I'm happy to hear any and all critiques, or even better see MC fixed.

[markf2748]

MC Version 28.0.73 posted today.
From the release notes 28.0.72 (10/7/2021):
6. Changed: When waking from a deep sleep mode, MC will send a M-Search to ask DLNA devices on the network to re-announce their presence.

Test
I installed 28.073 and reset the BubbleUPnP configuration.xml to default
<blastAliveInterval>0</blastAliveInterval>
Reboot and sleep for 2:14:29 h:m:s.
WOL and find CA (DLNA) zones show up with no noticeable delay!

First try is good - will keep watching it.

Thanks Matt.