View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018398 | MMW 5 | UPnP / DLNA | public | 2021-10-07 17:34 | 2022-09-19 14:37 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0.2 | ||||
| Target Version | 5.0.3 | Fixed in Version | 5.0.2 | ||
| Summary | 0018398: Playback of wav files over UPnP --> crash C33D3070 / C33D6716 | ||||
| Description | Whenever 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 Information | I believe that this is the same issue raised at ticket # 2863 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2509 | ||||
| related to | 0018330 | closed | Ludek | Trying to play http stream when disconnected from internet => (crash) |
| related to | 0018476 | closed | Ludek | Playback stucks when Media server tracks are no longer accessible (regression 5.0.2) |
| related to | 0019380 | closed | michal | UPnP playback of certain track formats --> failure and/or crash C33DC74A |
|
|
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! |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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... |
|
|
Fixed in 2509 |
|
|
Verified 2510 I verified with my QNAP UPnP. Please close after second verification. |
|
|
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. |
|
|
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. |
|
|
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) |
|
|
2) Seems regression in 5.0.2 and is fixed by the same fix as 0018476 in 2512 |
|
|
1) is tracked as 0018764 now |
