Bugzilla – Bug 9638
mov123 and wmadec transcoding broken with new streaming
Last modified: 2009-09-08 09:24:07 UTC
Created attachment 4092 [details] sample m4a coded with Nero AAC Many of my CDs are coded with Nero AAC codec (version 1.1.34.2). SqueezeCenter 7.2.1 is the last version which is able to play these files. Version 7.3 looks like it is playing them but there is no sound out of the Duet Receiver. The Controller is showing the now playing screen and playback time is running. This seems to be a cross-platform problem. In our network there is a PC with Windows XP SP3 and a PowerBook G4 with OS X and neither of them can play the files. The file extension is *.m4a.
Confirmed, SC 7.3 PC and MAC both fail to play the attached file. Verified the latest QT installed on both systems. see attached logs
Created attachment 4106 [details] Server Log
This looks like a file path issue with mov123 as a result of new streaming changes. Alan, would this one be for you?
(One way of looking at) the problem is that there is a deficiency in mov123 in that it does not know how to interpret "-" as a filename meaning standard input. I guess that this should not be too difficult to fix, for someone familiar with the code (Dean?), as it appears to be able to deal with the source being a remote stream. The problem arises because, with new-streaming, all transcoding is handled via Pipeline, which passes the source stream to the transcoding pipeline on its standard input. The transcoding command no longer gets its hands on the actual input filename. I can see some arguments for changing this but the current transcoding configuration-management functionality does not really provide the necessary info to make the right decisions. Some generic redesign in this area could help in various ways. Dean, can you look at mov123?
When you say "look at it" can you be more specific? Is what we need some command line options to specify the input format? That would be pretty straightforward.
wmadec like mov123 also appears to have the standard input limitation. Perhaps the description of this bug should be updated to something like "mov123 and wmadec transcoding broken with new streaming." I also wanted to mention that faad2 and mplayer might provide a transcoding solution for the limitations of wmadec and mov123.
The current codes in mov123 is something like: IF file-path looks like a remote URL THEN use some code that knows how to open remote streams ELSE use come code that knows how to open a local file ENDIF It needs an extra clause: ELSIF file-path == "-" THEN just use stdin
FYI, faad and mplayer are broken in Linux as well. I found a workaround in this post: http://forums.slimdevices.com/showthread.php?p=349044&highlight=faad#post349044 the $FILE$ param within the converter definition is being ignored. fix is in Song.pm: (though now I see this only fixes faad) my $filepath = '-'; if ($command =~ /faad/) { $filepath = $track->path; } $command = Slim::Player::TranscodingHelper::tokenizeConvertCo mmand($command, $type, $filepath, $url, 0 , $maxRate, 1, $quality);
*** Bug 9817 has been marked as a duplicate of this bug. ***
Fixed with change 23721
*** Bug 8858 has been marked as a duplicate of this bug. ***
Checked this with last night's build, and while the AAC tracks are working, ALC don't seem to be...
Alc would be bug 9794 but his should also be fixed.
Verified in 7.3 - 24723.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC