Print

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

[markf2748]

MC network Device Discovery seems to fail when there is a MC blocking message on the MC Server's window.

I encounter this issue only when the wi-fi network app MO 4Media or JRemote2 connects to the MC PC server but fails to find all networked renderers.  When I face the server, I see a blocking message on the screen about bit rate.  The great majority of the music library is 16-ibt 44.1 KHz flac, with a few 24-bit 48 KHz and 96 KHz flacs.

"OK" out of the message and the network apps "find" all the renderers.  Root cause of the message may be related to my USB DAC, connected to the server PC, timing out and going to sleep.  However, there must be some other condition involved, since simply putting the DAC and the PC Server to sleep, and then connecting is not sufficient to raise the problem.

In the same situation, immediately following those apps' failures, the Android BubbleUPnP player app (with BubbleUPnP Server running on the MC PC server) discovers all renderers and plays from the MC media library just fine.

Please find a way to make MC's network discovery and remote media access robust in the presence of blocking but apparently non-fatal MC messages on the server.  The next time this happens I will post the server message.

2/21/2024 Revised for accuracy.

Windows 11 Pro 23H2  64-bit | MC 32.0.19

[markf2748]

Attached is the blocking error message popup that appears when I start up MC locally while the attached USB DAC is in Standby State ("asleep").

I have since confirmed that remote renderers can still be discovered when the local DAC is in Standby State.  The DAC was in Standby State when I faced the server after the Device Discovery failure.  So I assume there must have been a play request at some point to raise the error message on the screen.  I've started logging with a 50MB max file size to capture the event sequence in the future.

Re the error message itself:

The message is not exactly lying, but not 100% truthful either.  The ASIO interface absolutely supports the sample rate of 48000 Hz.  The issue is that the DAC is in Standby State.  It would be more helpful if the error message's second line said something more like "Please check device availability", and omitted the wrong assumption about the device's playback capabilities.

I believe the 48000 Hz is governed by the tracks sitting in Playing Now.  When those tracks have a sample rate of 41000 Hz, then that is reflected in the error message.

Enhancement Suggestion: The information in the cited error message should be revised for accuracy.  This kind of message should unblock after a short period (maybe 10 seconds), but remain visible or get stored away in a timestamped notification area, with a clear warning symbol in the interface so it can be checked later.

[markf2748]

Proposed Root Cause:

I find MC's Device Discovery server takes a long time (5-10 minutes) to display all available DLNA renderers (under Playing Now) after the PC server wakes up from a long sleep (several hours or an overnight sleep for example).  When devices do not show up under PN, Android players MO 4Media and JRemote2 do not see them. On the other hand, Android BubbleUPnP displays all DLNA renderers "immediately" after the computer wakes up and plays to them just fine.

Initially after wake up, the DLNA devices do not appear under MC Tree > Playing Now ("PN").  At the same time,  MC Tree > Services & Plug-ins > Media Network reports that all 5 servers are running properly.  I click the "SSDP (Device Discovery)" tab to initiate a rescan of the network.  DLNA renderers are found in its output window, but still do not appear under PN (see attachment).  I initiate a second rescan.  Again devices show up in the scan output window but not under PN.  A moment later the devices finally show up under PN.  At that point, both MO 4Media and JRemote2 list the DLNA devices and can play to them just fine.

Note 1:  The two DLNA speakers appear in MC courtesy of the BubbleUPnP Server which transcodes them from Google Chromecast Audio media streamers.  I don't think Bubble is the reason for MC's PN delay since the renderers appear to be discovered quickly by MC's network scan.

Note 2:  This testing was performed while the USB DAC attached to the server was in its Standby State (overnight sleep).  I don't believe it has any impact on what I report here.

In retrospect, I believe the great majority, if not all, of my recent issues with MC network discovery fall into exactly this "long PN delay after long sleep" scenario.

[markf2748]

This morning I woke up the MC Server PC (using MO 4Media's built-in wake up function) after overnight sleep and then watched the Device Discovery Server's Activity Log.  The attached USB DAC was left in Standby State.  The MC Server Overview said

"Number of Servers:  5 (all running properly)",

but clearly this was not the case:

The SSDP Activity Log showed no activity for 22 minutes (zero entries), no network devices listed under Playing Now, and Android MO 4Media showed no DLNA devices.  The SSDP server "uptime" appears to track time in minutes since wake up, but seemingly has nothing to do with the actual functional state of the SSDP.  During this 22 minute period I ran several SSDP (Device Discovery) re-scans.  The scan's output window showed the DLNA renderers (as previously described), but there was nothing in the SSDP Activity Log.

After the 22 minutes I re-launch MC.  Immediately things become normal with SSDP Activity Log rolling along, DLNA devices under Playing Now, and MO 4Media showing DLNA renderers.

So clearly there is an issue with MC's SSDP after PC Server wake up from a long sleep. This is a real problem when connecting to a PC Server which is allowed to go to sleep, remotely woken up, and then trying to run the most common Android player apps for MC.

My guess:  MC launches SSDP too early in the wake up cycle, so it "misses" and never gets properly launched, while the MC Media Network messaging to the user is confused at best.  ReScan apparently is a totally independent view of the network (not a bad thing), but has no connection to what is actually happening within SSDP and PN, so its tab title is misleading.  Just an outside guess.

Definition: "re-launch MC" means close its GUI window, kill the Media Center Service (JRService.exe), and start up MC again.  In the most recent MC versions, this can be done by MMB click on the Windows close button.

Win 11 Pro 23H2 64-bit | Intel NUC 8i5BEH | MC 32.0.20

[markf2748]

I woke the PC Server up from overnight sleep this morning using its mouse and keyboard and logged into the PC Server.  As previously reported, MC (which as always was left alone running during this sleep/wake up cycle) shows no CCA DLNA devices under PN.  However with this physically connected wake up method the SSDP Activity Log was rolling right along.  No change with MC SSDP (Device Discovery) re-scans.  Using Bubble's configuration tool I confirmed that the BubbleUPnP Server was active and it showed the two CCA devices as valid DLNA renderers.  Based on long experience, I trust Bubble's configuration tool (C:\Program Files (x86)\BubbleUPnP Server\configure.url).

I then relaunched BubbleUPnP Server, leaving MC alone.  The two CCA DLNA renderers then showed up under MC's PN.

So per single test today:  MC SSDP Server once again does not discover BubbleUPnP Server's DLNA renderers when the system wakes up from long sleep, for whatever reason.  Either relaunching MC (previous tests), or relaunching BubbleUPnP Server (today's test), is sufficient to establish discovery.

[JimH]

Read Bob's comments in this thread:
https://yabb.jriver.com/interact/index.php?topic=84384.0

[markf2748]

Read Bob's comments in this thread:
https://yabb.jriver.com/interact/index.php?topic=84384.0

Thanks for the link.  It's an interesting thread, but is focused on renderers dropping out after initially playing.  In my case, it is all about discovery after wake up from long sleep.  Thankfully I have not experienced loss of a renderer while it is playing.  Nevertheless, the thread suggests two things to try:

(1) Changing "DLNA Controller Options".  I have only selected "Disable SetNext Support (for broken renderers)".  I will try deselecting that on one renderer, and selecting it on the other, to see if it affects wobbly inital playback after a long sleep (hesitates on first track, then skips and plays second track).  Not likely to affect discovery.

(2) I can look for presence of DLNA renderers in Windows Explorer > Network.  I normally see all DLNA devices there (though it sometimes requires a refresh of the window).  I will have a look after wake up from long sleep, which should be another way to see actual status of BubbleUPnP Server's DLNA renderers after wake up, independent of MC.  Note that, as I've reported, MC's "SSDP (Device Discovery)" always sees them - can someone from JRiver please explain why that is, yet at the same time they are missing under PN?

I did an enormous amount of work looking into this type of problem, I think around Sept-Oct, 2021, including running Wireshark through the wake up sequence.  I thought it had been fixed, but suppose I should review those posts (been hoping to avoid that!).

[markf2748]

Re (2):  Once the PC Server is woken up, it and other computers see the CCA DLNA devices listed under Media Devices in a Network Explorer Window.  These are created by BubbleUPnP Server, so the PC Server must be awake, but no need to log into the server to get them on the network.

I log into the PC Server, confirm that CCA DLNA are seen as Media Devices in its Network Explorer Window. Open MC.  Once again, the devices are seen by MC's SSDP (Device Discovery), but are not visible under PN, and hence are not available to MO 4Media.  Android BubbleUPnP Player sees them.

Today at 18 minutes up time, I noticed the CCA DLNA devices under PN on the PC Server.  Restart MO 4Media and, as expected, they show up there as well.

So again we have the situation that after PC Server wake up from long sleep, there is a long delay until the CCA DLNA devices appear under PN (at least today they eventually showed up).

This behavior supports the idea that MC Discovery Server misses these network devices during initial wake up from long sleep, possibly due to scanning too early in the wake up cycle.  At the same time, MC's SSDP (Device Discovery) is aware of them early on.

Troubleshooting this behavior is challenging because the behavior after a short sleep/wake up cycle can be different than that after a long sleep/wake up cycle.  That may be due to the PC Server reaching a deeper sleep state over time.

Memory jogs:

Long thread (early October, 2021) describing what is likely same problem.  Its last post (Reply #11) describes an MC fix: 
https://yabb.jriver.com/interact/index.php/topic,130828.msg906986.html#msg906986
Apparently this fix no longer works, or is no longer active.

Related post/thread (late March, 2023):
https://yabb.jriver.com/interact/index.php/topic,135511.msg938876.html#msg938876
Today in Windows Services I find both JRiver Media Center 31 Service and JRiver Media Center 32 Service, set to Manual Startup.  I just set MC 31 to disabled (since I no longer run it).  Unlikely that will make any difference, but I'll see.
There is also mention by that OP (Reply #15) of only auto-starting Media Center, without specifically starting MC Service at all.  I suppose I can try that as well.
I will also try my own old suggestion (unfortunately forgotten ) of Playing Now > Refresh Dynamic Entries to see if that updates PN after long sleep. [Edit:  this option is greyed out if the CCA DLNA zones are not present under PN].

[bob]

Remote connections should never cause a block on the main UI on the server. Sounds like a bug to me.

[markf2748]

Remote connections should never cause a block on the main UI on the server. Sounds like a bug to me.

Thanks for the acknowledgement.  It certainly appears to me that something is wrong when MC's SSDP (Device Discovery) tool detects CCA DLNA renderers which do not appear under PN.  Especially weird when the Discovery Server shows what appears to be a normal sequence of M-SEARCH and NOTIFY events in its Activity Log in response to running the tool.  Windows Explorer shows the renderers as well.

The following setup last night, followed by a reboot and then putting PC Server to sleep, resulted in my two CCA DLNA zones being present under PN after wake up this morning (from mouse & keyboard) after long sleep:

1) MS Windows Services > JRiver Media Center 32 Service > Startup Type > Automatic (delayed start).
In prior trials this had been "Manual".

2) MS Windows Services > BubbleUPnP Server > Automatic
Always set this way.

3) MS Windows > Settings > Apps > Startup > Media Center 32 "On"

4) MC > Options > Startup > Windows Startup > Run on Windows startup:  Media Center and Media Server
This was used in most prior trials.  This choice apparently leaves the Media Servers running, even when MC UI is closed.

I confirmed from the command line tool powercfg /systempowerreport that the PC Server was asleep for 8 hours before wake up this morning.  The report indicates "Standby" which I assume corresponds to Sleep Mode 3 on the Server PC, even though it reports Event Log "TargetState" and "EffectiveState" as "4".  Separately, powercfg /A reports that "Standby <3>" is the only sleep state available on this computer.  In summary:  AFAICT nothing unusual about today's long sleep/wake cycle itself.

Remains to be seen if today's success is consistent over time.

Win 11 Pro 23H2 64-bit | MC 32.0.20

[bob]

Matt is expanding the MCWS play calls that disable UI message boxes.
When a message box is showing, the tree can't update since both are on the main thread.
When the next build comes out please give it a try.

[markf2748]

Matt is expanding the MCWS play calls that disable UI message boxes.
When a message box is showing, the tree can't update since both are on the main thread.
When the next build comes out please give it a try.

Next Build.  1) After wakeup from long sleep (54 minutes) this evening with latest MC beta, it took 15 minutes for the CCA DLNA renderers to show up under PN, even though I ran SSDP (Device Discovery) sooner than that multiple times.  Overall behavior is same as I have described previously.

The PN behavior seems to have reverted back to what I reported in October, 2021 (the first link posted above in Reply #7).  Matt fixed it back then by initiating an M-SEARCH right after wakeup from sleep.  Back then there was no SSDP (Device Discovery) tool available to users.  Now that we have that tool, and can run a network scan with it at any time, combined with watching the SSDP Activity Log, it's clear there is a serious disconnect between SSDP (as run by the tool and reported in Activity Log) and PN.  There is something like a 15 minute interval between M-SEARCH blasts for which PN actually recognizes the corresponding NOTIFY events, and there is no early detection after a wakeup from long sleep.

CAVEAT:  There is insufficient message information in the MC Activity Log to verify what is going on with complete confidence.  It would take a wireshark analysis, or more message info in the log, to better identify what is going on.  Nevertheless I think my points are most likely correct.

Additional message header info that would be useful to see in the Activity Log, if it's not there already (I've wanted this for a couple of years now):
M-SEARCH  ST:, SERVER:, USN:
NOTIFY  NT:, NTS:, SERVER:, USN:

2/28/2024 Updates:
2) AM wakeup after 4h52m sleep - successful early detection.
Note: MS Windows Services > JRiver Media Center 32 Service > Startup Type > Manual
3) Wakeup after 1h19m sleep - successful early detection.

2/29/2024 (leap day!) Updates:
4) AM wakeup after 9h48m sleep - successful early detection.
Note:  PC was put to sleep while logged in with MC running.  It is possible the circumstances around going to sleep affect the outcome at wakeup. Will watch that.  The reported sleep state is always the same, as previously reported.

3/1/2024 Updates:
5) AM wakeup after 8h52m sleep - successful early detection.
Note:  PC was put to sleep while logged in with MC running.

3/2/2024 Updates:
6) AM wakeup after 3h14m sleep - successful early detection.
Note:  PC fell sleep on its own (timed out) 2h58m after a reboot last night.

32.0.21 & .22 Batting Average:  .833 (6 at-bats)

I'm calling this issue fixed until further notice!
Thanks, it's huge!     

Win 11 Pro 23H2 64-bit | MC 32.0.21 & .22 (current betas)

[markf2748]

The fix continues to work nicely, truly hip hip hurray  . But there is a side effect which should be addressed.

Apparently by disabling warning messages, some rather useful messages have disappeared for the user.

Example:   Suppose the USB DAC attached to my PC Server is in its own low power standby mode.  Then have MC try to play a track to it.  MC used to put up a blocking warning message telling me something was amiss (the message text needed improvement, but at least it was there).  Now, dead silence, no message at all, MC just marches on.  Not great.

Feature Request:  See my Replay #1 above.

The issue of messaging is an old one.  It might be a lot of work to fully implement, but JRiver could start off by activating the most common previously blocking messages as notfications.  Here is a recent reference to messaging in the context of CD/DVD burners:
https://yabb.jriver.com/interact/index.php/topic,137560.msg953955.html#msg953955
It also comes up in the context of MC clients mysteriously losing control of their PC Server.

Edit:  A few hours later, I tried to play a track again with DAC in low power standby. This time the old blocking DAC error message shows up.  Not sure what happened here.  Is it expected that blocking messages should still show up?

[bob]

The blocking messages should show up when started except when the playback is started from a remote (MCWS)

[markf2748]

The blocking messages should show up when started except when the playback is started from a remote (MCWS)

Thanks for the clarification, which I basically confirmed.

There is a relatively common "corner case" which strictly speaking may not violate your statement, but causes confusion:

1) DAC attached to the PC Server is in low power standby (common use case and easy test for generating error messages).
2) Remote Android connects to PC Server and plays to a CCA DLNA renderer.  Works nicely, thanks.
3) Play from Android to PC Server "Player".  No sound because DAC is in standby. Phone's playing slider jumps back to start (OK).  No message anywhere (sort of acceptable).
4) Return to the PC Server itself and try to play a track.  No sound because DAC is in standby.  No error message (not good).
5) At some point, error messages show up again when playing directly from MC on the PC Server (creates confusion).

So user experiences transitions between effective server states with "messages visible" and "messages hidden" when playing directly from the server.  The messaging state apparently depends on whether or not the remote is in use, and may also depend on time elapsed since last remote play or connection.  That's where the confusion (and shock) enters.  Seems to happen independent of whether the PC Server is remotely woken from sleep or is already running before using the remote (you may need to further verify this aspect).

I almost certainly ran into this case yesterday (Reply #12),  probably without step 3), and confirmed today with step 3). 

3/7/2024 Edited 4th paragraph for clarity.