View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015428 | MMW 5 | Casting (Google Cast / UPnP) | public | 2019-02-05 21:49 | 2020-11-09 10:12 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015428: Chromecast: multizone issues | ||||
| Description | 1) When the user first enables multizone --> list of devices includes Chromecast Groups, however, when the user selects such a group for playback --> nothing happens! If Groups aren't supported, then they shouldn't be listed. 2)a) When the user enables multizone and selects 3 different chromecast audio devices and initiates playback --> Playback starts 2 times partially and then a 3rd time fully with all 3 devices finally in sync b) When the first track completes and the second one starts --> The 3 different chromecasts don't play in sync! 3) When the user switches from multizone to Internal player --> Various in-process chromecast connections to the 3 different devices fail to terminate (in fact MM5 appears to continue to try to connect to them). It might make sense for all chromecast sessions to terminate any time there is a change in output device settings (e.g. also when a new device is added to Multizone). Tested 2154 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2179 | ||||
|
|
1) I have only one Chromecast device, so I cannot test Chromecast Groups atm. Could you please generate debug log so that I could see how to detect the group and remove it from the list (until the groups are supported). Note: I might want to buy another Chromecast device to test the groups and try to reverse engineer to support them. 2) The current sync process workflow is: - mute all players in multizone - wait until playback is started/buffered on all players - seek to zero position to synchronize the players - enable the sound to hear it all on the players But I found that the MUTE command to Chromecast devices currently fails (it is a regression) => Fixed in 2162 3) I cannot replicate, could you please generate debug log using build 2162? Note that I tested with single Chromecast device + two DLNA players in the mutlizone -- as I don't have multiple Chromecast devices |
|
|
1) I have got 'Chromecast audio' device now, but I am observing another issue. Once I created a Goggle Cast group then my 'Chromecast audio' gets the groups's name instead of its 'Chromecast audio' name. Assigned to me to look into it. 3) A user is also seeing this: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93941&sid=05bc416cf8168be6927264cfd2bda6a0 |
|
|
Item 1) is fixed in 2164 |
|
|
The remaining items are fixed in 2165 + added more debug string (in case you will still seeing an issue with multizone). I am just seeing that while 'Chromecast audio', 'Internal Player' and 'foobar2000' are perfectly in sync, the other Chromecast device is sometimes out of sync because of buffering (there is hearable gap in the playback). It sometimes reports states like PLAYING, then BUFFERING for a while and then 'PLAYING' again, but during the BUFFERING phase it can get out of sync (300ms - 400ms), but this is issue rather with this particular device (or network connection?), because the same happens when this device is part of the 'Google Cast Group' casted from MMA. The other 'Chromecast Audio' device has never the BUFFERING phase and plays just fine. |
|
|
2) I'm able to replicate this often by starting a new track when multizone is enabled 0 initiate playback Track plays 1 enabled multi-zone (Kitchen, Study) 2 initiate playback --> (line 3700) Playback begins as MM status bar shows Connecting on Kitchen, Connecting on Study. BUT: speakers don't play in sync, and MM player doesn't display the seek bar!! --> (line 4900) After about 2m (sometimes it's after 30s), Playback restarts on the same track as MM status changes (status bar entries disappear, presumably buffering is complete) This time playback playback from the different devices is in sync. The same thing also often occurs after the first track completes. i.e. see log 2b 2 initiate playback (on 3 devices) --> (line 12000) Playback begins ('Coming home') as MM status bar shows Connecting/buffering on multiple devices BUT: speakers don't play in sync, and MM player doesn't display the seek bar!! --> After about 4m, Playback restarts on the same track as MM status changes (status bar entries disappear, presumably buffering is complete) This time playback playback from the different devices is in sync. 3 Track completes and the next track ('Easy runaway') starts playing (~line 27000) --> Playback begins, but speakers play out of sync as MM status bar shows Connecting/buffering --> After a few seconds, the Buffering messages disappear and playback restarts, with speakers in sync 4 Track completes and the next track ('Fire on the Horizon') starts playing --> Playback begins, but speakers play out of sync as MM status bar shows Connecting/buffering 5 Press 'Stop' --> MM5 continues to show 'Buffering on xxx' for each of the 3 chromecast devices for about a minute and then they disappear (unlike case 3b below in which for some reason the next track started playing) 3)a) I believe that issue 3) (failure to switch to the internal player) and various other issues (failure to stop see below) are related to the state that MM5/Chromecasts are in at line 3700 above. See the attached log (line 14929) for an example where MM takes about 15 seconds to switch from chromecasts to the internal player. Other similar issues that I've observed: b) Press 'Stop' while in the state of line 3700 --> Playback stops and then the next track starts playing! c) Press 'next' while in the state of line 3700 --> Next track doesn't start (playback stops) NOTE: none of these issues occur with MMA Debug logs are on FTP |
|
|
2) In the log I see something slightly different, you switched from multi-zone, back to internal player, and back to multizone. Then the seek bar was not displayed and updated. Log file 'Bug_15428_issue_2.LOG': - line 2102 , time 146, playback of track Stick Figure - Out the Door.m4a was initiated - both 'Kitchen' and 'Study speaker' was playing the track, but 'Kitchen' was 1 seconds ahead ('Study speaker' was reporting "PLAYING" with position 0 for almost half a second, i.e. it had a pre-gap for some reason) - after 13 seconds of the playback (12854 on Study speaker, 13753 on Kitchen) you switched to 'Internal Player', it was line 3198 - internal player was playing the song 'Stick Figure - Out the Door.m4a' using in_mfaudio.dll - at line 3772 the playback on 'Internal Player' was stopped as you switched again to multizone ('Study speaker' & 'Kitchen' ) - line 3979, track played in sync ( 892/274860 ms on Stydy Speaker, 900/274860 ms on Kitched) BUT, you are right that at this point the seek updating has stopped! - one minute later (line 4116), track still playing in sync ( 51371/274860 ms on Study Speaker, 51381/274860 ms on Kitchen) - two minutes later (line 4486), someone (or something) performed action seek to zero position (00:00:00) and thus playback restarted and was playing in sync (on Kitchen and Study Speaker) - 30 seconds later (line 5799) you stopped the playback But you seem to be right that the seek bar update lost (at line 3700 - after switching back from Internal to Multi-zone) can somehow cause subsequent auto-restart of playback (line 4486) and possibly the other issues. |
|
|
I think that I have fixed it in 2166 (based on the logs). But please re-test (as I couldn't replicate in my environment) and generate log from 2166 (in case it is not fixed for you) |
|
|
2) I tested 2166 with the following tracks: 1. Anna Kendrick - Cups 2. Yann Tiersen - Le Banquet 3. Lemonheads - Into your arms 4. Simon and Garfunkle - Feelin' Groovy 5. Simon and Garfunkle - The 59th Street Bridge Song 6. Yann Tiersen - J'Y Suis Jamais Alle 7. The Beach Boys - Little Deuce Coupe Multizone consisted of 3 chromecast audio devices. Test 1 (PC connected via ethernet): 1 Enabled Multizone in MM5 2 Initiated playback --> 1. in sync, 2. not in sync, 3. not in sync, 4. started 2 seconds then restarted and played in sync, 5. not in sync, 6. not in sync 3 Pressed STOP --> 7. kept playing (similar to issue 3??) !! 4 Pressed STOP again --> playback of 7. stopped 5 Moved track 7. to position 4. 6 Played track 3 --> in sync --> track 4 (little deuce coupe) skipped! --> track 5 (Feeling Groovy) not in sync Test 2 (pc connected via WiFi): 1 Enabled Multizone in MM5 2 Initiated playback --> Similar results (i.e. tracks often out of sync) except that playback got completely stuck after track 4 (see log) Could this have been related to Podcast updates or Synchronization with MMS? Note: I switched to 'internal player' after waiting 10m for playback to start. Test 3 (pc connected via WiFi): 1 Enabled Multizone in MM5 2 Initiated playback --> all tracks play out of sync except 7. (Little Deuce Coup) which plays correctly p.s. Logs are on the ftp server. Note: for test 1 I accidentally left logging on after the test while testing another unrelated issue. I retested this with MMA playing to the same group of chromecasts and all tracks played in sync without issue. 4) Multizone UI issues: a) If the user presses 'Cancel' within the multizone dialog, they may expect that Multizone was not enabled. To clarify change: - OK --> Save - Cancel --> Close b) In relation to the above, the UI should silently 'multizone' from being selected if no devices are enabled in multizone c) text tweak: multizone --> multi-zone |
|
|
Fixed and optimized in 2168 |
|
|
Tested multizone playback in 2168 and playback doesn't seem to work correctly or at all: 1 Played Cups --> playback out-of-sync. 2 STOP 3 Played Le banquet --> playback out of sync 4 Switched laptop to Wi-Fi 5 Played 'Crazy Love' --> received message that all three chromecasts were inaccessible! Then MM continued to show attempted connections to all three devices and failure message (same as above). 6 Pressed STOP 7 Played tracks via MMA --> 5 tracks played in sync over all 3 devices 8 Activated multi-zone playback in MM5 --> Buffering on device1/device2/device3 appeared 9 Initiated playback of 'Cups' --> Buffering on device1/device2/device3 appeared but playback didn't start (MM skipped through each track without playing). Logs on ftp. |
|
|
The regression after switching network interfaces (steps 4 - 9) is fixed in 2169 (was caused by some optimizations in 2168 - cached serving IPs) As for the playback out of sync (Steps 1-3), for some reason the "Dining Room CC" is always ahead (700ms for the track 'Played Cups', 1000ms for the 'Le banquet '). MM5 sends the "sync seek to zero position (00:00:00)" at the same time for all the three Chromecast devices and when all the three devices already buffered the track and are silently playing it, but the 'Dining Room CC' seeks to something like 0.83 seconds instead of 0.00 for some reason (probably round down). So I probably need to wait until all the three devices are over 1 second before sending the "sync seek to zero position" => Fixed in 2169 |
|
|
Tested 2170 and: - Out of 9 tracks, only 2 played in sync (over both ethernet and wifi). Note that I played the same set of 9 tracks over both wi-fi and ethernet, and there was no obvious pattern regarding which of the tracks played in sync. - Several of the tracks exhibited a 'stutter' at the beginning of the track. I'm not sure if this is coincidence or not, but 2 of the 'stutters' were associated with playback that was in sync across all 3 chromecasts. - On the wifi test pass, I believe that a couple of tracks skipped completely (because my track count for tests was 2 short) Note: -On the ethernet test pass: Le Banquet and Feeling Groovy (also stuttered) played in sync -On the wifi test pass: ?? and 59th street bridge song (also stuttered) played in sync -When playing via MMA: all tracks play in sync -Logs posted to FTP |
|
|
I analyzed the logs and I also don't see a pattern regarding which of the tracks plays in sync. The data is buffered on all three devices once the "seek to zero position" command is sent by MM5. So the devices should just play in sync, but it is not the case based on logs and sometimes is 'Study CC' ahead, sometimes 'Dining room CC', sometimes 'Kitchen CC', no pattern. I don't see how I could influence this. As for the playing in MMA: all tracks play in sync -- this is not what I am seeing in my tests, but I have 'Chromecast v2' and 'Chromecast audio' in the Google Cast audio group, it is possible that in case of the group consisting from the 'Chromecast audio' devices only there is a hidden sync mechanism that I am not aware of. EDIT: Once I re-analyzed the logs I found that 'Study CC' is often ahead because of ignorance of the "seek to zero position" command. It seems that once the 'Study CC' already is near to zero (like 496 ms, 828 ms) then it does not seek to zero, but continues the playback. The strange is that ''Kitchen CC' was at 893 ms and performed seek to zero correctly. EDIT2: Other time the 'Study CC' was at 612 ms and seeked to zero correctly while 'Dining Room CC' was at 825 ms and ignored the seek command. Maybe the command is lost somehow , to be found more... |
|
|
I have reproduced the occasional track skipping and fixed for 2174 I also fixed a bug related to pausing of multi-zone player + some timeout issues. The "play in sync" issue is also tweaked and improved in 2174 |
|
|
Tested 2174 and it's much improved, but I'm still observing sync issues: 1 Enable multizone 2 initiate playback --> On startup MM indicates that all three devices can't connect. Upon clicking 'OK' in these dialogs, playback starts! --> 1. 'Cups' plays but doesn't play in kitchen! 3 Stop playback. Turn off Casting. Turn on Casting. Play track 2 --> 2. 'Modeh Ani' starts playing right away (i.e. no apparent attempt to connect/sync the 3 devices before playback began. Playback is out of sync! --> 3. 'Le Banquet' plays in sync --> 4. 'Into your arms' started playing (1s) out of sync, and then restarted in sync! --> 5. 'Crazy love' started playing 3 times and then played out of sync! --> 6. 'Feeling groovy' started playing 3 times and then played in sync! --> 7. 'The 59th street Bridge Song' started playing 3 times and then played in sync! --> 8. same as above --> 9. same as above Debug log posted to ftp. |
|
|
I managed to add "Google Cast Group" support in build 2178 (which I suppose resolves your "out of sync" issues) |
|
|
Tested 2178. I'm not sure how to use the Google Cast Groups--any such groups that have been created in Google Home do not appear in the MM5 multizone UI OR in the CC context menu. That said, I did test Chromecasting in this build and both multizone and regular chromecasting failed. MultiZone: 1 Set multizone to include Dining Room/Kitchen/Study 2 Initiated playback of Track 1 --> Errors indicating that both 'Kitchen' and 'Dining room' were off/inaccessible --> After a short amount of time playback proceeded to the Dining Room (but not to any other location) --> Track 2 proceeded in the same manner Single Zone: 1 Set CC destination to dining room 2 Initiated playback of track 4 --> Multiple messages that 'Dining room' is off/inaccessible --> No playback Debug log posted to FTP. note: I then tested playback to Chromecast with MMA and it worked as expected for both individual chromecasts and chromecast groups. |
|
|
For all the Chromecast devices in the log I see: "last_seen":"2019-05-24 13:38:10" It seems that the devices are no longer visible/discoverable by MM5 on your network (for some reason) and MM5 takes them just from the persistent.json (couldn't auto-discover them neither using SSDP or mDNS) Also, I see "Connect timed out" for "Dining Room CC" and "Kitchen CC", only the "Study CC" replied (communicated). But I guess that the "time outs" could be caused by the failed discovery, because the IP addresses could be changed for the devices since the 2019-05-24 . In the log from build 2174 there were all the devices (including the groups) detected via mDNS by MM5: Dining Room CC, 192.168.0.81, uuid: e33cb49f-2dd3-b4f1-6200-ff1766ae4b77, type: Chromecast Audio Kitchen dining group, 192.168.0.81, uuid: 268d62f9-4882-40b4-bf20-c542ec5e7826, type: Google Cast Group Kitchen CC, 192.168.0.83, uuid: 0c8dd90a-4bd3-8535-26ee-06a9ecc4b844, type: Chromecast Audio Dining Room CC, 192.168.0.81, uuid: e33cb49f-2dd3-b4f1-6200-ff1766ae4b77, type: Chromecast Audio Home group, 192.168.0.84, uuid: b643d5d2-4033-41fe-8b4b-8e8d8c579935, type: Google Cast Group Study CC, 192.168.0.84, uuid: d32009b7-5216-583d-35ba-0e297d98f29a, type: Chromecast Audio Any idea what could be the change in your network environment since 2019-05-24 -- that it fails to discover them now ? Could you please do following tests: 1) delete persistent.json so that MM5 does not take the "cached" list of Chromecast devices 2) start DbgView , run 2174 and see whether it is able to detect your devices, save the log 3) delete persistent.json again and repeat the step 2) with build 2178 |
|
|
BTW: I was playing with this and trying to simulate your issue I got to the state where I was getting also the "connect timeout" errors (although the devices were discovered using mDNS). But when I was in that strange state and run Chrome on the same PC then Chrome shown "No devices found" when I clicked the cast icon. See: https://www.dropbox.com/s/0nof9mdmrn3p9yw/Screenshot%202019-05-27%2023.38.19.png?dl=0 Could you please check whether Chrome on the same PC is able to detect the devices or whether it also shows "No devices found" ? EDIT: PC reboot helped me to get from that state (Chrome and/or MM5 restart did not help) |
|
|
I've uploaded logs to ftp with builds 2174/2178 having deleted persistent.json and found that: 1) Build 2174 didn't find chromecast audio devices 2) Build 2178 didn't find chromecast audio devices 3) When I turned on a chromecast-video device, build 2178 found it 4) Chrome only saw the chromecast video device (and not the audio devices) As I'd mentioned previously, MMA finds all 4 devices (3 chromecast audio + 1 chromecast video). |
|
|
Based on the logs the devices are not announced via mDNS service, the "ChromecastVideo.RS" is found via SSDP DIAL, but "Chromecast audio" can be generally found/announced only via mDNS. Any idea why Chrome/MM5 detected the "Chromecast audio" devices until 2019-24-05 and fails now? Isn't this caused by migrating to the newer PC/machine ? Or are you testing still on the old machine? I guess that once you are not able to see the devices in Chrome then you won't be able to see them in MM5 too. Could you try the troubleshooting tips: https://support.google.com/chromecast/answer/3249268?hl=en |
|
|
It seems that it was a networking issue, though I'm really not sure what specifically resolved it. In any case CC groups work perfectly now! There are still a couple of cleanup items: 1) I'm still observing crashes when switching to multizone (even though Multizone consists only 1 Chromecast + Internal player). See attached debuglogs (around line 14000)+ crashlog (though I'm not 100% certain that the cause was the same in both cases) Logs posted to ftp 2) From a usability perspective, I would suggest that [ ] Internal player should always be an option in the cast menu. e.g. something along the following lines: (o) Internal player ( ) Kitchen chromecast ( ) Chromecast group And when the user enables casting via CC or DLNA display the option to Monitor: ( ) Internal player (o) Kitchen chromecast ( ) Chromecast group ---------------------------------- [x] Monitor on Internal Player 3) Is there a reason to retain the multi-zone feature? |
|
|
1) I see, there is an exception "Unknown cast message type: PLAYBACK_SESSION_UPDATED" posted by "Home group" and was unknown for MM5 => fixed in 2179 2) I don't understand this item , what do you think that internal player should be an option in the cast menu? It is an option and it is also an option in the multi-zone. It cannot be option in the Google groups -- as google groups are configured via "Google Home" app and can consist only from the google cast devices. Or are you referring the two original variants and you want to change it to the former? See the screenshots here: 0009036:0045688 to see the two variants for multi-zone config. 3) yes, the multi-zone feature allows grouping of various players (be it internal, google cast, DLNA) -- so it is still useful. |
|
|
1) Seems to be fixed 2) What I meant is that if a user is casting, it would be useful if it were always possible to also monitor the audio stream on the local speaker. 3) But what scenarios are expected to work with multi-zone? i.e. a) CC + CC is unreliable b) Does CC + UPnP work reliably? c) Does UPnP + UPnP work reliably (I had tested it at one point and iirc the screams were out of sync) From my perspective, we should only include this feature if the feature includes functionality that guarantees that the various streams will play in sync. |
|
|
2) user can currently monitor the audio stream on the local speaker when 'Internal player' is part of the multi-zone 3) As for the realibility: I guess it depends on testing environments and devices. Before I even start implementation of this I talked to Jiri that we cannot guarantee the audio stream being in sync in the multi-zone (for various device types), he said that it is OK and that he considers this feature still useful (e.g. for garden parties) |
|
|
Verified 2273 During testing of 0015222 I also tested this and in current state of tech we use there is no way to clearly watch synced playback as too many factors can influence the stream and cause the delays. as written in 0015222 I have been testing way to introduce sync frame in stream that would be easily utilized by MMA and possibly other devices thru skip data frames. ATM there is not much we can do. |
