mrw wrote:
> This is beyond my knowledge level. I see no more than you. I used to
> have an object dump (from -readelf-, I think) of the symbols, but I
> threw it away. A session with -ghidra- might reveal more if you really
> wanted to know, but the thought does not really fill me with
ralphy wrote:
> Because when I copied the classicfm.aac file to my test system ...
Ha ! An 'other factor'. I might not have owned up to that. :)
ralphy wrote:
>
> I've rerun the test and can confirm that I get 37 sync errors but the
> file plays...with a few "blips" in the audio.
>
There
mrw wrote:
> Questions:
>
> Why does your stock firmware behave differently to my stock firmware ?
> Why is your stock firmware trying to open an 'mp4' file ? The test file
> is not an 'mp4' file.
>
> What are you seeing in place of my stock firmware log here ?
> >
Code:
ralphy wrote:
> Now I need to find a file/stream that triggers the error.
I've conjured up a file that contains plenty of errors, and have
attached it. It is a plain '.aac' file, which I have constructed by
downloading 40 seconds or so from a remote stream, and specifying that
icy metadata
mrw wrote:
> I'm impressed that you were able to something with it.
>
> So, perhaps appropriate if the problem is a "basically OK but
> occasionally glitched" incoming remote AAC stream, but not particularly
> appropriate if it is just fundamentally duff (or MP3...).
>
> With the basic
ralphy wrote:
> That's for the pointer. I'm going to revisit the aac decoder in the
> coming days as when I tried the test file in that ticket, the track
> position progressed through the entire track but no audio.
> At least the decoder doesn't crash with the out of bounds patch applied.
I'm
mrw wrote:
> I came across this -ffmpeg- ticket which suggests what correct handling
> should be: https://trac.ffmpeg.org/ticket/7331
> Perhaps that is already happening. Or perhaps the ticket is wrong. I
> have no knowledge.
>
>
> Which is true in this case, because you happen to have an MP3
Paul Webster wrote:
> 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?
Only if
ralphy wrote:
> I trap on AAC_DEC_TRANSPORT_SYNC_ERROR as well but the newer fdk-aac
> decoder it's returning that error for this issue. Perhaps it's trying
> harder to decode the errant stream? but that's just a guess.
I came across this -ffmpeg- ticket which suggests what correct handling
mrw wrote:
> I've attached some Radio logs that I was able to capture. They may or
> may not be helpful, but you might as well have them available.
>
> As you will see, from the Community firmware the predominate messages
> are, in the main -DEBUG audio.codec - decode_aac_callback_heaac:141
Switching off "sort favorites list" worked for me.
Thank you, all!
mitchhellman's Profile: http://forums.slimdevices.com/member.php?userid=32063
View this thread: http://forums.slimdevices.com/showthread.php?t=113719
mitchhellman wrote:
> I created a sub-folder but haven't figured out how to move favorites
> I've created into the sub-folder. I'm using Squeezelite-X with the
> Material Skin, and drag-and-drop won't work.
It doesn't appear to work with the grid skin, but works fine using the
list view.
Also
mitchhellman wrote:
> I created a sub-folder but haven't figured out how to move favorites
> I've created into the sub-folder. I'm using Squeezelite-X with the
> Material Skin, and drag-and-drop won't work.
Try going to settings, under browse, de-select "sort favourites"
location 1: lms 8.0
Paul Webster wrote:
> You could still use your Favorites - but move them into a sub-folder.
> A maintained plugin would probably be better for you but this should be
> a quick and easy workaround.
I created a sub-folder but haven't figured out how to move favorites
I've created into the
ralphy wrote:
> I found the problem with the FDK AAC decoder segfaulting in the
> community firmware.
>
> The aacDecoder_DecodeFrame API function multiplies the buffersize
> provided in the parameters by the data size causing it to try accessing
> beyond the allocated output buffer.
>
>
I found the problem with the FDK AAC decoder segfaulting in the
community firmware.
The aacDecoder_DecodeFrame API function multiplies the buffersize
provided in the parameters by the data size causing it to try accessing
beyond the allocated output buffer.
bpa wrote:
> I think we're both at the edges of our knowledge. I' m not going to
> worry about previous bugs/misconfiguration - I see the prime issue as
> two caches out of sync.
I don't doubt that you will be shown right, other than in using the term
'prime'. I think there may be two
mrw wrote:
> An area that is well outside my knowledgebase ! I'll continue to study
> and gain understanding.
>
> Nevertheless, I think the basic point that I noted is valid. Should LMS
> be trying as hard in 2021 to "fix" server misconfiguration problems that
> may have been prevalent in 2010
bpa wrote:
> The problem is same as before - two caches out of sync
>
> for same 1.fm URL
> $contentTypeCache has "aac" accessed in Schema.pm
> $urlToTypeCache has "mp3" access in Info.pm
An area that is well outside my knowledgebase ! I'll continue to study
and gain understanding.
The problem is same as before - two caches out of sync
for same 1.fm URL
$contentTypeCache has "aac" accessed in Schema.pm
$urlToTypeCache has "mp3" access in Info.pm
bpa's Profile:
bpa wrote:
> headercontent is audio frame data.
Thank you. That was the piece of understanding that I was missing.
bpa wrote:
>
> Problem was an AAC stream being identified as MP3 (as suffix was .mp3).
>
> Starts at ppst #43 but goes on and later MichaelH offers (and implement)
> a better
slartibartfast wrote:
> It could be the first time an aac stream has actually been MP3. It looks
> like an error by the content provider. It probably should be aac.
It is not good for any sort of invalid aac stream causes radio to
reboot. In this instance it is LMS problem but it shows aac
mrw wrote:
> I won't be doing that, because it is important to be able to flush out
> problems, which this episode has done.
>
> It would be interesting to know what -faad- makes of the misidentified
> stream, when LMS does the transcoding.
>
> But you are right, the Community Firmware's
mrw wrote:
> But that is done _after_ looking at the remote headers.
Headers iare HTTP
headercontent is audio frame data.
> So we're reading the headers _again_ ?
LMS always has to examine the audio stream ( a file/audio stream header
not a HTTP header) for example, to determine bitrate as
slartibartfast wrote:
> I suppose the workaround is to disable native aac until it is fixed.
I won't be doing that, because it is important to be able to flush out
problems, which this episode has done.
It would be interesting to know what -faad- makes of the misidentified
stream, when LMS
bpa wrote:
> 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.
bpa wrote:
>
> Later, after reading data from the stream, in
> Slim/Player/Protocols/HTTP.pm (after calling parseDirectHeaders to
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
mrw wrote:
> 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
mrw wrote:
> 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
slartibartfast wrote:
> 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
Man in a van wrote:
> RadioNet plugin
>
> 33029
>
> ronnie
Well, that was simple-- thanks for the tip!
mitchhellman's Profile: http://forums.slimdevices.com/member.php?userid=32063
View this thread:
mrw wrote:
> 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
bpa wrote:
> 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.
>
>
mrw wrote:
> 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
Paul Webster wrote:
> 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
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?
Paul Webster
http://dabdig.blogspot.com
bpa wrote:
> The original bug was a shortcut to designate type from extension (IIRC
> not the last 3 letters) name rather than scanning the contents.
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
bpa wrote:
> 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.
>
>
slartibartfast wrote:
> I seem to remember a similar issue fairly recently where the stream type
> didn't match the name. I'll try to find the thread.
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
mrw wrote:
> Well, a quick look at Slim:Utils:Scanner:Remote is very suggestive.
> Anything ending in -aac- is deemed to be so even if the scan shows that
> it is -mp3- !
>
> -# Bug 3396, some m4a audio is incorrectly served as audio/mpeg.-
>
bpa wrote:
> >
Code:
> >
> [21-01-21 10:03:04.4177] Slim::Utils::Scanner::Remote::readRemoteHeaders
(376) This URL is an audio stream [aac]: http://strm112.1.fm/reggae_mobile_aac
>
> >
Well, a quick look at Slim:Utils:Scanner:Remote is
mrw wrote:
> I wonder why that should be. Headers indicate -audio/mpeg-, meaning, I
> believe, MP3.
Agreed. I need to look a bit more, I only did a quick test - it may be
a side effect of some change I have in my own system (I sometime forget
to unwind all of some test setups)
The log shows
bpa wrote:
> Found the problem.
>
> My LMS has determined it is AAC and tries to use faad - but it is an MP3
> stream.
I wonder why that should be. Headers indicate -audio/mpeg-, meaning, I
believe, MP3.
Code:
curl -I 'http://strm112.1.fm/reggae_mobile_aac'
bpa wrote:
> The plugin just finds the URL and lets LMS try to play it. I've had
> reboot issue with players and odd URLs. If the setting is "resume on
> poweron" then LMS will send the "bad" URL to the player once it is
> powered on (i.e. rebooted) and so loops.
>
> There is something odd
bpa wrote:
> There is something odd with the 2nd 1.FM reggae
> http://strm112.1.fm/reggae_mobile_aac - I can't get it to play with
> Receiver.
Found the problem.
My LMS has determined it is AAC and tries to use faad - but it is an MP3
stream.
slartibartfast wrote:
> I didn't know there were any settings [emoji3]. What was causing the
> boot loop though? When it finally recovered the second stream played
> correctly. I have never experienced a boot loop with any player before.
>
> Sent from my Pixel 3a using Tapatalk
The plugin just
Material Skin.
33030
+---+
|Filename: 1.FM.jpg |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=33030|
Man in a van wrote:
> go to the settings for NetRadio and tick the "display one url " boxI didn't
> know there were any settings [emoji3]. What was causing the
boot loop though? When it finally recovered the second stream played
correctly. I have never experienced a boot loop with any player
slartibartfast wrote:
> I tried playing 1.fm Adore Jazz on my Radio and 6 streams were
> displayed. The first played OK so I tried the second one and now now my
> Radio is stuck in a boot loop.
> Edit. Finally started the Radio possibly by holding the "left" button
> but I have no idea why that
Man in a van wrote:
> RadioNet plugin
>
> 33029
>
> ronnieI tried playing 1.fm Adore Jazz on my Radio and 6 streams were
displayed. The first played OK so I tried the second one and now now my
Radio is stuck in a boot loop.
Sent from my Pixel 3a using Tapatalk
RadioNet plugin
33029
ronnie
+---+
|Filename: radionet.png |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=33029|
H. I may contact 1.FM. I tried out the Roku channel for 1.FM, and
it's a pitiful thing; all you can do with it is choose one of the
streams and let it play. No way to indicate or save favorites, no title
or artist info, no album covers, no indication of song length/elapsed
time, no next song
mitchhellman wrote:
> Rather than cluttering my Favorites with all of these 1.FM streams, I'm
> hoping that someone can build something that will enable me to scroll
> through the various streams.
>
You could still use your Favorites - but move them into a sub-folder.
A maintained plugin
I was wondering if anyone has considered the possibility of creating an
app or plugin to enable the Squeezebox to connect to 1.FM streams? 1.FM
I tried to find any information about their service... but their website
isn't too helpful. Google found some About... page which mentioned they
were
(Please excuse my ineptitude; I've been using my Squeezebox Duet for
about 10 years, but I am nowhere near the level of knowledge that many
(most?) of you display.)
I was wondering if anyone has considered the possibility of creating an
app or plugin to enable the Squeezebox to connect to 1.FM
55 matches
Mail list logo
