Bugzilla – Bug 17472
Erratic playing of AAC stream on IP3K players.
Last modified: 2011-08-24 07:18:15 UTC
There is a bug which results in the erratic playback of transcoded internet radio streams. This is most commonly noticed on AAC stream on IP3K players (e.g. SB3, Boom, Duet). One of the symptoms of this bug is the player showing stream format is MP3 rather than AAC. If the user plays an AAC stream (e.g. from SomaFM App or BBC live AAC) on a IP3K player and then stops the stream. Wait for at least 6 mins. Then if the user tries to play the same stream URL - player will try to play the stream as MP3 and will fail - so no audio. Wait long enough and another cache timer seems to expire and stream becomes playable again. The problem is in parseDirectHeaders routine in the file Slim/Player/Protocols/HTTP.pm although it might also be trye for other parseDirectHeaders routines. This routines the HTTP headrers to be provided in an array of strings - each string terminated by 0x0A and 0x0D (\r\n). The pattern matching headers argument removes that last character but leaves the 0x0D which is noted for numeric strings but for "Content-type" is means the mime type has an added character and so is not found in the defined SBS "types" - so SBS assigns the MP3 content type. The @headers argument is passed to the parseHeaders routine (which in turn calls parseDirectHeaders) by the request routine in the Slim/Formats/RemoteStream.pm. In this case the strings in @headers are terminated by "\r\n". The @headers argument can also be passed to the parseDirectHeaders routine by the directHeaders routine in the Slim/Players/Squeezebox2.pm. In this case the strings in @headers have all "\r" and "\n" removed In these cases since parseDirectHeaders will remove the last character - streams with a mime type of "audio/aacp" will be reduced to "audio/aac" before being checked in SBSB "types". This means for some mime types this comparison could fail. In practice I think suffix may be used to provide the correct audio format. It may be more serious for numeric arguments since last digit of a number may be lost. I don't know the conditions under which directHeaders routine is called.
Created attachment 7404 [details] Patch file to fix HTTP.pm by adding code to remove unwanted chars in @headers I was wrong in my previous comment about the possibility of last character being chopped off a header. So the bug is simpler and the fix only has to deal with the possibility of calling routine not having tidied up @headers properly. The attached patch copies code from RemoteStream.pm to process a header to remove unwanted chars - especially 0x0D which is matched as a char by the "." in the header pattern matching. The patch remove unwanted chars from all headers but it really only significant for headers which are strings such as Content-Type. The trailing \r char is ignored during conversion of headers which are numeric (e.g. Length).
you are very talented bpa! don't forget to vote for your own bug!
Could you please provide me with a stream exposing this issue? Should I see it with all SomaFM or BBC live streams?
Michael, look here: http://forums.slimdevices.com/showthread.php?t=89675 http://forums.slimdevices.com/showthread.php?t=89793 bug 17201
Any of the SOMA AAC stream from the APP will display this problem. Play the stream, stop it and then wait for at least 6 minutes and then try to play same stream. Bug 17201 has nothing to do with this issue.
== Auto-comment from SVN commit #33167 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33167 == Fixed Bug: 17472 Description: apply patch from bpa to fix streaming of AAC radio stations to ip3k players. Thanks Bryan!