View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016611 | MMW 5 | Casting (Google Cast / UPnP) | public | 2020-05-13 23:03 | 2021-08-26 14:33 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0016611: MM Player can't be used when Chromecast/DLNA device is turned off | ||||
| Description | When MM is casting to a Chromecast or DLNA device and this device is turned off you can no longer play files in MediaMonkey. You can switch it to Internal Player, but Pause/Stop buttons don't do anything and you're forced to restart MM to be able to play. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2260 | ||||
|
|
I guess expected would be MM5 should Temp auto failover to Internal untill Selected DLNA device gets available and have selected unavailable device grayed in listing? |
|
|
An automatic return to Internal Player may be unwelcome for some users (a setting for this would be great though). Another way around this would to show a message after x seconds have passed that device has become unavailable. This message would tell the user attempting to reconnect in 30 seconds and have a button to switch to Internal Player now (or switch Player allowing any to be selected). To solve the current problem I'd expect that: 1) Switching to Internal Player (or any other available Player) continues playback (it doesn't) 2) That Pause and Stop work on the Player (they don't) |
|
|
Possible relations to I am unable to replicate dtsig issue at https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=96550 LOG ID: 46CB0170 |
|
|
Fixed in 2248 (together with related crashes C49112E2, 46CB0170) |
|
|
Tested 2248 and I'm not replicating a crash. However, the usability is still problematic in the sense that if the CC device is disabled/unplugged during playback and the user presses play/pause, then MM tries to connect for about 10-20s and if the user tries switching from the CC device to Internal Player, the switch doesn't occur. Would it be possible that if the user switches the output player that the new setting completely overrides any activity happening on the previous connection? |
|
|
Fixed in 2251 |
|
|
Not fixed reopen. Slightly different steps: 1. Start playback Playing thru Nexus player 2. Kill power to Device to forcefully remove device 3. Nothing happen it looks like all is ok on MM5 player like Nexus player is available 4. Switch to Internal Player -> Playback continue normally on internal player 5. Switch to nexus player (strange it was still available even I unplugged power to it 6. Connectin -> Fail -> Grayed track -> Connecting -> Fail Dialog -> Gray track. 7. Press stop (have it enabled in groove skin) 8. Must manually switch to internal player |
|
|
I don't think that the player should be removed from the list (or auto-switched to internal player), because the player could be unavailable just temporarily (mostly user just forgot to turn it on or turned it off accedentally). I think that Peke's use case above is quite expected, because: - MM reports that the Nexus Player is turned off or inaccessible - so user si informed - user can switch to internal player anytime (or turn on the Nexus Player anytime) The original issue is resolved, i.e. switching to 'Internal Player' drops all connections (or connection attampts) to the no longer available Nexus Player |
|
|
Verified 2251. As to the issues raised by Peke, I agree that it's a distinct and minor issue (it's not really a bug so much as it's different behavior than is usually observed on Android devices that cast to cc devices). |
|
|
Peke, at 0016611:0058216 you wrote that at step: 6. MM tried unsuccessfully to connect to the player and MM generated an appropriate error dialog to that effect. (This is what I consider to be a different workflow though not necessarily a bug). 7. Pressing STOP seemed to work. 8. Switching to internal player also works as expected. You didn't mention anything in that comment about MM STOP button not working OR an attempt to switch to the internal player not working (and I'm not able to replicate any such problem). So if you're seeing such an issue, please update your repro steps and clearly indicate what bug occurs (vs what would have been expected). |
|
|
In Step 2 I unplugged Nexus player from power to force shutdown and in Step 3 "3. Nothing happen it looks like all is ok on MM5 player like Nexus player is available" MM5 continued to play normally like Nexus player is not disconnected. So I stopped playback Switched to internal and played track -> Switch to Nexus player Constant Nag screens like MM5 can't connect to Nexus player -> OK Next track starts to play -> Nag Screen -> Ok Next track Starts to play -> Nag Screen -> ..... There is no way to press stop as Modal dialog is on top. I pressed stop on keyboard and then manually downgrade to internal player. It should be automatic? That is why I suggested that Nexus player gets grayed and not selectable and that Internal player is selected Automatically. If you do same when using USB sound card It is Auto Stopped and Switched to next default sound card on next playback no need for manual change. Chrome cast behavior should be same as Chromecast device is just another output as any other sound card and behavior should be same. |
|
|
OK I think I understand. I see that: 1) Once the CC is unplugged, MM continues to 'Play' to the unplugged Chromecast. I'm not sure if that's a bug though--it may be that MM doesn't receive any sort of notification/feedback. 2) When new tracks start to 'Play', MM attempts to reconnect for the track and generates an error for the track, and initiates playback for the next track after the user accepts the error. Although this works, it isn't the most user-friendly approach. But as far as other issues: STOP button works fine. Switching to the internal player works fine. So the original functional issues are resolved, but a couple of usability issues remain. I'll open the usability issues in 0016671 to be addressed in a future release. |
|
|
Verified 2255 Original report fixed future updates are handled in 0016671 |
|
|
Fixed in 2260 by fixing 0016671 |
|
|
Verified 2260 |
