Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 57

Thread: 1.fm?

  1. #21
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by Paul Webster View Post
    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.

  2. #22
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,140
    Quote Originally Posted by mrw View Post
    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).
    Last edited by bpa; 2021-01-21 at 08:35.

  3. #23
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,261
    Quote Originally Posted by bpa View Post
    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

  4. #24
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,261
    Quote Originally Posted by mrw View Post
    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.

    Code:
     # 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

  5. #25
    Quote Originally Posted by Man in a van View Post
    RadioNet plugin

    Attachment 33029

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

  6. #26
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by slartibartfast View Post
    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.

  7. #27
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,261
    Quote Originally Posted by mrw View Post
    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

  8. #28
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    6,261
    Quote Originally Posted by mrw View Post
    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

  9. #29
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,140
    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.

  10. #30
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by bpa View Post
    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.

    Quote Originally Posted by bpa View Post
    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 ?

    Quote Originally Posted by bpa View Post
    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 ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •