View Issue Details

IDProjectCategoryView StatusLast Update
0018398MediaMonkey 5UPnP / DLNApublic2022-01-20 15:54
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilityalways
Status closedResolutionreopened 
Product Version5.0.2 
Target Version5.0.3Fixed in Version5.0.2 
Summary0018398: Playback of wav files over UPnP --> crash C33D3070 / C33D6716
DescriptionWhenever MediaMonkey attempts to play a FLAC track from the QNAP Media Server (UPnP), the server converts the track to .wav (this is not configurable on my server) and MediaMonkey fails to play the track.

If the user attempts to play back any other track (even MP3 tracks that previously played) --> playback fails

If the user attempts to exit MediaMonkey --> crash C33D6716

If the user attempts to browse the UPnP Server and then exit MediaMonkey --> browsing is slow and crash C33D3070 on exit

Several such crashlogs have been submitted.
Additional InformationI believe that this is the same issue raised at ticket # 2863
TagsNo tags attached.
Fixed in build2509

Relationships

related to 0018330 closedLudek Trying to play http stream when disconnected from internet => (crash) 
related to 0018476 closedLudek Playback stucks when Media server tracks are no longer accessible (regression 5.0.2) 

Activities

Ludek

2021-10-07 17:48

developer   ~0065024

Last edited: 2021-10-07 21:55

View 4 revisions

Based on a brief review of the code/logs it could be a regression related to fixing 0018330 -- but I am not sure

Can you please test whether 2503 works fine to confirm my speculation?
Feel free to test also 5.0.1.2433 official (whether it exhibits the issue or not).

If the builds prior to 2505 also exhibits the issue then please right-click your QNAP server in MM5 and select 'Configure remote access...'.
Then access it again and put here the link to file
http://192.168.xxx.xxx:xxxx/Transcode/A0$128$130$67174657$142$494207236.wav?type=1,sfid=3,said=86028,sach=2,findex=0,vindex=-1,aindex=256,enMux=2,duration=265,client=25,mime=audio/wav,pn=LPCM,ext=.wav
which should now include your public IP so that I can test direclty on your stream and replicate the issue.

Thanks!

rusty

2021-10-07 19:19

administrator   ~0065028

Last edited: 2021-10-07 21:55

View 2 revisions

So you're mostly right. In 2503 attempts to play the wav files (converted from flac) resulted in a 'cannot decode...' error. BUT subsequent to the error other tracks play normally and MM closes normally.

So even once you fix the regression, we probably want to also fix the failed decoding of the .wav file.

Ludek

2021-10-08 08:45

developer   ~0065043

Last edited: 2021-10-08 12:37

View 2 revisions

The crash regression fixed in 2508

The reason why it fails to decode the stream needs to be debugged further, Rusty is going to set up VPN for us so that we can test directly on the particular stream.

rusty

2021-10-08 15:48

administrator   ~0065051

Last edited: 2021-10-08 20:14

View 5 revisions

Updated with test results from Updated build 2508:

The crash is _not_ fixed (it occurs exactly as with build 2507).

A couple of other points discovered in the course of testing.
1 On playback of the problematic tracks
--> playback is 'stuck' on the problem track and the MM UI can be browsed, but any attempt at playback of another track (whether local or on the network), is blocked (there's no response to any attempt at adding tracks to Now Playing)
2a If the user waits for about 1m15s
--> the error appears, the player 'lockup' ends, and any tracks that were were double-clicked during the 'lockup' start playing
2b If the user closes MM prior to the error dialog appearing
--> the previously described crashlog occurs

Note re. a fix: ideally, a problematic track shouldn't block playback for > 2-3 seconds before an error appears.

Ludek

2021-10-11 12:48

developer   ~0065097

Last edited: 2021-10-11 12:51

View 3 revisions

OK, the main problem is that the file
http://192.168.xxx.xxx:xxxx/Transcode/A0$128$130$67174657$142$494207236.wav?type=1,sfid=3,said=86028,sach=2,findex=0,vindex=-1,aindex=256,enMux=2,duration=265,client=25,mime=audio/wav,pn=LPCM,ext=.wav
is still actually FLAC file.

i.e. when it is downloaded and added '.flac' extension then MM5 plays it correctly as FLAC, but from the stream MM5 tries to play it as WAV (using in_wav.dll) resulting in the issues...

Ludek

2021-10-11 13:49

developer   ~0065098

Fixed in 2509

peke

2021-10-16 21:51

developer   ~0065270

Verified 2510

I verified with my QNAP UPnP. Please close after second verification.

rusty

2021-10-25 20:28

administrator   ~0065496

Tested 2511 and the issue still occurs. When I initially replicated, crash C33D3070 resulted. The second time (with dbgview running) the following resulted:

Navigate to Server > Music > Artists > Heart > All tracks
10034 Play Barracuda --> nothing plays
12420 Play Crazy on you --> Playback failed error - MediaMonkey cannot decode...
14620 Close MM
-->Crashlog C33D6716 / MM is frozen

Note: playing the same tracks via MediaMonkey for Android or Bubble UPnP works fine.

Ludek

2021-10-26 19:12

developer   ~0065518

Last edited: 2021-10-26 19:12

View 2 revisions

OK, so the file is really served as chunked stream being transcoded to wav in your environment while it is served as original FLAC when accessing the same stream via VPN.
Any idea why it is not transcoded while accessing via VPN ? I would need to simulate it in order to be able to debug/fix the stream decoding issue.

rusty

2021-10-26 23:11

administrator   ~0065523

I'm not sure about the transcoding--there aren't any transcoding settings on the QNAP server. So from my perspective there are 2 issues:
1) The fact that MMW can't play the tracks (MMA can without issues)
2) The fact that MMW5 crashes (MM4 can't play the tracks either, but it doesn't crash)

Ludek

2021-10-27 11:25

developer   ~0065527

2) Seems regression in 5.0.2 and is fixed by the same fix as 0018476 in 2512

Ludek

2022-01-20 15:54

developer   ~0066686

Last edited: 2022-01-20 15:54

View 2 revisions

1) is tracked as 0018764 now