1.fm?

[mrw]

However, if that is checking a URL (which it appears to be based on the variable name) then I think it is quite possible for a genuine AAC to not have a dot.
If correct then would it mean that real AAC content would not necessarily be detected properly?

Here is my take:

The problem here is that the last three characters of the stream url http://strm112.1.fm/reggae_mobile_aac suggest that it might be aac, but it actually has Content-Type correctly identifying it as audio/mpeg, i.e. MP3. But LMS overrides that and deems it to be aac. Which doesn't work.

I don't think you can guarantee a win when dealing with misconfigured servers. But this server is not misconfigured. It is LMS's attempt to deal with other misconfigured servers that is breaking a correctly configured server.

And the reason seems to be that LMS's 'test' for misconfiguredness is, perhaps, one dot shorter than it might be.

I'd suggest that LMS should not break a correctly configured stream.

[bpa]

Here is my take:

The problem here is that the last three characters of the stream url http://strm112.1.fm/reggae_mobile_aac suggest that it might be aac, but it actually has Content-Type correctly identifying it as audio/mpeg, i.e. MP3. But LMS overrides that and deems it to be aac. Which doesn't work.

I don't think you can guarantee a win when dealing with misconfigured servers. But this server is not misconfigured. It is LMS's attempt to deal with other misconfigured servers that is breaking a correctly configured server.

And the reason seems to be that LMS's 'test' for misconfiguredness is, perhaps, one dot shorter than it might be.

I'd suggest that LMS should not break a correctly configured stream.

IIRC This seems to be a the same problem as before, LMS initially misidentifies the contenttype by suffix or MIME but then later after examining te actual audio frames, LMS updates the ContentType but there were two caches and the corrected value gets lost. I can't look at the code until later this eve to see where the audio frames are checked (which LMS has to do to get sample rate and sample size to know if stream has to be transcoded).

[slartibartfast]

I thought that was fixed.

The original bug was a shortcut to designate type from extension (IIRC not the last 3 letters) name rather than scanning the contents. IIRC The recent fix scanned the contents of first few frames to determine MP3 vs AAC from frame headers.

Have other users confirmed this is a real problem on their system and not just a problem on mine due to non standard setup.

I tried playing the second Reggae stream and crashed my Radio again. What is going on?

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

The code I have identified does not actually check for an extension, but rather the last three characters. This just looks like a mistake.
And it takes place after scanning the contents and determining the reported Content-Type.

I have confirmed the occurrence of bug by way of a trace into the relevant LMS code, and observing that my Radio simply fails to reproduce audio. It does not go into an 'endless reboot'.

The following is, I think, the change required to LMS. I get good playback after applying it. It changes the match to recognize the extension by requiring a '.' in the suffix, not just the last three characters.

 # Bug 3396, some m4a audio is incorrectly served as audio/mpeg.
 # In this case, prefer the file extension to the content-type
-if ( $url =~ /aac$/i && ($type eq 'mp3' || $type eq 'txt') ) {
+if ( $url =~ /\.aac$/i && ($type eq 'mp3' || $type eq 'txt') ) {
 $type = 'aac';
 }
-elsif ( $url =~ /(?:m4a|mp4)$/i && ($type eq 'mp3' || $type eq 'txt') ) {
+elsif ( $url =~ /(?:\.m4a|\.mp4)$/i && ($type eq 'mp3' || $type eq 'txt') ) {
 $type = 'mp4';
 }

Currently enjoying Back Staba by Israel Vibration.

Assuming we are both using the Community Firmware why is my Radio rebooting and yours is not?

Sent from my Pixel 3a using Tapatalk

[mitchhellman]

RadioNet plugin

Attachment 33029

ronnie

Well, that was simple-- thanks for the tip!

[mrw]

Assuming we are both using the Community Firmware why is my Radio rebooting and yours is not?

Assumptions, assumptions...

You'll be pleased to know that my Community Firmware reboots itself splendidly.

For undetermined reasons, the aac decoder in the official firmware seems to fail rather more gracefully on the non-aac data bening offered than does the aac decoder in the Community Firmware.

I managed to salvage a few (SqueezePlay) logs, but they are all somewhat different. Got a SIGSEGV at one point. One for @ralphy, I think. There might be something to be done to ease its response to 'bad data'.

I'll have to assemble my log traces into some sort of order.

[slartibartfast]

Assumptions, assumptions...

You'll be pleased to know that my Community Firmware reboots itself splendidly.

For undetermined reasons, the aac decoder in the official firmware seems to fail rather more gracefully on the non-aac data bening offered than does the aac decoder in the Community Firmware.

I managed to salvage a few (SqueezePlay) logs, but they are all somewhat different. Got a SIGSEGV at one point. One for @ralphy, I think. There might be something to be done to ease its response to 'bad data'.

I'll have to assemble my log traces into some sort of order.

That makes me feel better

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

Assumptions, assumptions...

You'll be pleased to know that my Community Firmware reboots itself splendidly.

For undetermined reasons, the aac decoder in the official firmware seems to fail rather more gracefully on the non-aac data bening offered than does the aac decoder in the Community Firmware.

I managed to salvage a few (SqueezePlay) logs, but they are all somewhat different. Got a SIGSEGV at one point. One for @ralphy, I think. There might be something to be done to ease its response to 'bad data'.

I'll have to assemble my log traces into some sort of order.

I suppose the workaround is to disable native aac until it is fixed.

Sent from my Pixel 3a using Tapatalk

[bpa]

The issue is indeed a rehash of the old mar 2020 problem.

First, in /Slim/Utils/Scanner/Remote.pm the ContetnType is set to "aac" based on URL.
Later, after reading data from the stream, in Slim/Player/Protocols/HTTP.pm (after calling parseDirectHeaders to get bitrate, contenttype etc.) the ContentType is set to "mp3"

Now to find where "aac" is being cached.

[mrw]

First, in /Slim/Utils/Scanner/Remote.pm the ContetnType is set to "aac" based on URL.

But that is done after looking at the remote headers.

Later, after reading data from the stream, in Slim/Player/Protocols/HTTP.pm (after calling parseDirectHeaders to get bitrate, contenttype etc.) the ContentType is set to "mp3"

So we're reading the headers again ?

Now to find where "aac" is being cached.

Clearly SqueezePlay is being told that the stream is aac, hence the problem.

I don't know what the "old March 2020" problem is/was. Do you have a pointer ?