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.0https://yabb.jriver.com/interact/index.php?topic=109481.0https://yabb.jriver.com/interact/index.php?topic=117626.0