MM5 freezes in RD after connection loss

[MediaMongoose]

When I have MM open in my remote desktop (from laptop to PC upstairs) and I lose my connection for whatever reason, the MM window goes black and can only be killed from the task manager.
(OS = Windows 10)

[Lowlander]

Which Build (Help > About) of MediaMonkey are you using?

[MediaMongoose]

5.0.2.2532

[Lowlander]

Please capture this in a debug log (step 4b) and attach the log to a Support Ticket: https://www.mediamonkey.com/forum/viewtopic.php?t=86643

This will help a developer analyze why this happens in your setup.

[Peke]

Hi,
I have tried to replicate in latest Mm5 build and could not replicate.

Please try latest one from https://www.mediamonkey.com/forum/viewt ... 86639&sd=d

[proteus]

Same symptom using Remote Desktop

MM5 works OK, except:
On login via remote desktop, MM5 changes to black window or white window and hangs.
I this state it is not responsive to input events.
Must kill with Task Manager (This does not always work, in this case there are two instances on MediaMonkeyEngine, killing both leave a window with no way to kill except reboot)

MM 5.0.4.2692

My goal is casting to remote speakers, using control with MMRemote.
The setup works, but not reliably due to this issue.

[proteus]

Update,
I just sat and watched the MM5 window via Remote Desktop (always open).
Playing a playlist (no shuffle) via cast to my Kef LS50.
MM5 (MM 5.0.4.2692) is on a machine with cable to router, LS50 is WiFi to router.

1) At the beginning of the 2nd track and tracks after (usually) there is a pause and a message:
"The 'LS50' player is turned off or inaccessible" - this self corrects after a short pause.

2) After a few (?) tracks we get a message (it disappears fast, so is it approximately) :
Playback failed, 'LS50' cannot decode XX.mp3

A very short time later the MM5 window goes white, and MM5 is unresponsive.

Suggestions:

A) I'm inclined to think this is not RD related, its just that RD users wouldn't see the message only the final state.

B) Since other players work OK, and some (all?) behavior is track related it looks to me like an MM5 issue.

Update 2

The above is with WASAPI, if I use DirectSound or waveOut the "cannot decode" message always occurs on the first track transition. It is not related to the actual song so the inability to decode does not refer to the data.

Update 3

Back to WASPI

I just noticed something else odd, when the turned off or inaccessible message occurs the Cast button goes 'off' and taping it shows "internal player" not "LS50" selected in the dropdown (both are there). But the cast does play the next song (see self correct above) on LS50.

[CrashMonkey]

Must kill with Task Manager (This does not always work, in this case there are two instances on MediaMonkeyEngine, killing both leave a window with no way to kill except reboot)

Reboots should not be needed. Do you do this under "Task Manager ->Tab, Users" ? If so try to do it at the first tab, at processes. There it should work. Or else use the more advanged process explorer from microsoft: https://learn.microsoft.com/nl-nl/sysin ... s-explorer

[proteus]

Workaround

The issue for Cast is the ethernet connection.
On my server I turned on WiFi and disconnected Ethernet, and the issue has disappeared.
Note, you must disconnect Ethernet for the issue to go away.

This makes some sense assuming message times are longer through the router, and that presumably creates longer timeouts that MM5 can't handle.

Clearly MM5 should not hang depending on network topology, so I view this is an issue to be fixed that has a workaround.

[proteus]

Wait....

I still see the error messages occasionally. Have not figured out what other network timeout are not handled

[proteus]

Somewhat frustrated by the MM5 Cast experience...

... I notice this works with no issue and no latency: "In Windows File Manager select a set of mp3 , right click -> Show more options -> Cast to Device -> Speakers", which is sad.

[proteus]

updated to 2819

Works much better, but still issues, try FF 4 or 5 times in succession.
The UI and the player get out of sync, and the only way to resync seems to be to exit the app.

[yomatt]

I'm having a similar problem. MM Version 5.0.4.2693 hangs with a black window after loosing RDP connection and reconnecting. Running on Windows 10 Professional 64 bit fully patched.

Not accessing MM via casting but do sync with android app.
When I go to kill it via task manager MM is showing Power Usage of "Very High" with significant CPU usage.

Seems to restart fine after the app is killed.