View Issue Details

IDProjectCategoryView StatusLast Update
0016595MMW 5Generalpublic2022-07-19 12:57
ReporterLudek Assigned To 
PriorityurgentSeverityminorReproducibilityunable to reproduce
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0.3Fixed in Version5.0.3 
Summary0016595: Issues when playing to Raspberry DLNA client
DescriptionDebugging with user via RNZ-952-82555 where MM4 is casting to his Raspberry client and the Respberry skips some songs randomly (reads 130 KB and then reports transport status STOPPED).

When this happens MM4 should cast the next song in the queue. Currently the playback just stops entirelly.
TagsNo tags attached.
Fixed in build2600

Relationships

related to 0018401 closedlowlander Play To Playing not showing that file is playing 
related to 0019264 closedLudek Casting to some players (like OPPO UDP-20) can result in skipping some tracks 

Activities

Ludek

2020-05-11 17:33

developer   ~0057946

Fixed in 4.1.29.1906 and merged to 5.0.0.2248

Ludek

2020-05-18 20:31

developer   ~0058091

Fix confirmed via RNZ-952-82555

peke

2020-05-21 22:29

developer   ~0058174

Verified 1906 and 2250

No regressions found on other devices.

Ludek

2021-12-18 21:13

developer   ~0066416

Last edited: 2021-12-18 21:18

Based on log [Ticket # 3332] this can still happen with Respberry.

Very similar steps to repro, it can happen after track skip (initiated manually using Next in MM5). Details+logs in [Ticket # 3332]
Moving to MM5 to fix this for 5.0.3

Ludek

2021-12-18 21:25

developer   ~0066417

Fixed in 5.0.3.2600

Ludek

2021-12-21 20:56

developer   ~0066455

Last edited: 2021-12-21 21:36

Re-opened: Based on the new logs from ticket [Ticket # 3332] the 'Raspberry' device is specific and sends messages for the PREVIOUS track while the CURRENT track is already playing.
This confuses MM5 and can result in skips OR playback stop.

To be workarounded somehow.

Ludek

2021-12-22 18:41

developer   ~0066475

Last edited: 2021-12-22 20:41

I implemented the workaround and shared new testing EXE with the user via ticket [Ticket # 3332] to confirm.
Note that the same workaround should work also for the Onkyo's issue ([Ticket # 3309] -- but the user is not willing to test/debug further).

Fixed in 5.0.3.2600

peke

2022-04-20 21:31

developer   ~0067628

Verified 2615 Raspberry Pi 3