View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008577 | MMW v4 | DLNA/UPnP | public | 2011-10-27 18:29 | 2012-02-05 22:33 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0008577: Some m4a files can play in MM, but not via MM DLNA renderer | ||||
| Description | As described here: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=61382 , some m4a files won't play via the MM renderer even when they play in MM (file available via the forum post). | ||||
| Steps To Reproduce | 1 Set up the UPnP / DLNA Server to share the file in question 2 Enable both the DLNA server and renderer 3 Use a DLNA controller to play the file and render it via the MM renderer --> Playback doesn't start | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1453 | ||||
|
|
The file works fine for me over DLNA, both directly by browsing the server in MM interface and also by using a media controller (PlugPlayer in my case) and MM as renderer. |
|
|
Try on a machine using Quicktime as the m4a decoder. If that doesn't work, I'll generate a debug log. |
|
|
You are right, using Quicktime as the m4a decoder it doesn't work, but I guess it has never worked with any m4a stream. |
|
|
But the user on the forum indicates that it fails also with the MediaMonkey_AAC_Plug-in_1_0_6 for him. There is also one regression, playback of FLAC files that are going to be auto-converted from M4A (or another format) fails, will be fixed in build 1450. |
|
|
I tested on a machine with Quicktime + MM Codec Pack 2.1.4 and it still fails. Could it be that MM's DLNA renderer preferentially tries to use Quicktime instead of the codec pack to decode the stream? I'm not confident of that hypothesis, though, because other .m4a files play just fine over DLNA in this manner--the problem is specific to the file provided by the user. |
|
|
This file is ALAC, maybe this is the reason? |
|
|
@Rusty, the user on the forum indicated that after re-installing MM_Codec_Pack_Trial_2.0.0.14.mmip the file is playable for him (same as for me). So try to re-install it and if it doesn't help then generate debug log please. @Michal, is the file playable for you? |
|
|
It is playable. But with autoconversion to MP3 it throws memory error, log sent. |
|
|
Note that the memory error was reproducable only from the Delphi environment (otherwise it cannot cause any trouble), but thanks to this I found issue 0008587 that is fixed in 1451. |
|
|
Attached is an dbgview log and elog of: This log shows: 1 User plays 3 files in MM, 1 MP3, 2M4a 2 User sets up DLNA server in MM --> 2 renderers become active on one instance of MM! 3 User activates MM Renderer 1 and MM Server, and verifies that it works with MP3 --> MP3 Plays successfully 4 User activates MM Renderer 2 and MM Server, and verifies that it works with MP3 --> MP3 Plays successfully 5 User Plays M4A file 1 successfully 6 User Plays M4A file 2 --> playback fails to initiate --> AV occurs (attached) --> MM freezes and must be forced closed Note: the problem of MM generating 2 renderers for one instance of MM is a separate bug--it just happens to have occurred while testing this issue. It's not entered anywhere else because I can't replicate it. If the log gives enough information about the problem, please enter a separate bug. Note also: the MM Codec Pack was installed. |
|
|
Note also: streaming the file with MM DLNA Client from MM DLNA Server works correctly as well (even when client and server are running on same machine). |
|
|
The file that failed to render is an ALAC, and it freezed in a DLL that is part of Media Foundation, because (on Windows 7) the M4A streams are played by MF preferrably. On XP we plays them ourselves by using f_aac_codec.dll. There would be valuable to find: 1. Does it always freeze on the ALAC file ( http://192.168.0.118:45874/%25/12713.m4a )? According to http://msdn.microsoft.com/en-us/library/windows/desktop/dd742784%28v=vs.85%29.aspx It seems that MF cannot render ALACs, but it should fail gracefully and not freeze. 2. I guess that removing in_mfaudio.dll solves the problem? 3. Is the stream http://192.168.0.118:45874/%25/12713.m4a playable by WMP? |
|
|
The "two renderers" issue is tracked here: 0008595 |
|
|
Note that I have just tested this on Windows 7 and in my case the in_mfaudio.dll isn't able to play the ALAC stream at all there is an AV as can be seen from these lines: [2272] in_mfaudio: Error opening input file: http://192.168.2.2:4000/%25/11286.m4a [2272] , hr = 0xC00D001A [2272] BQ: Added new task. Currently 1 tasks in queue. [2272] PlayFile failed: Access violation at address 65A804ED in module 'in_mfaudio.dll'. Read of address CCCCCCCC |
|
|
I've just found that the AV in in_mfaudio.dll was there, because the file itself has been somehow deleted from the disk (not sure why). When I re-added the file then it failed to play it with following lines: [2272] in_mfaudio: ConfigureAudioStream:SetCurrentMediaType failed, trying 44100Hz, hr = 0xC00D5212 [2272] in_mfaudio: ConfigureAudioStream: SetCurrentMediaType failed, hr = 0xC00D5212 [2272] TWAInputPlugin.Play finishing i.e. It doesn't play the ALAC stream (as expected), but doesn't freeze as in the Rusty's case. |
|
|
It really seems that MF cannot play ALAC files at all. Also WMP fails to play the file completelly (both as stream and as a local file). Assigning back to Rusty to answer questions from note #28542 , it seems that the file was played by our codec pack (after MF failed). Hard to say why MF frozen on the Rusty's machine. |
|
|
1. MM does _not_ freeze on attempting to play this Alac file. It just doesn't play it (http://192.168.0.118:4000/%25/12713.m4a) 2. On a machine with the codec pack 2.0.1.4 installed, if the in_mfaudio.dll is removed, the Alac file in question plays. 3. Windows Media Player generates an error (it shows an 'x' next to the file), but doesn't crash/freeze. |
|
|
Although I cannot reproduce it, Rusty indicated that in case in_mfaudio.dll isn't removed then MM _always_ freezes on his machine (see attached ELF). Michal, the solution seems to be to detect the ALAC file by ourself in the in_mfaudio.dll and fail gracefully (without the freeze) so that another plugin could play it. |
|
|
Fixed in build 1453. I've reproduced the freeze when playing over http, resolved by manual ALAC detection. |
|
|
Verified 1453 |
