Re: [SlimDevices: Plugins] 1.fm?
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 enthusiasm, > and it is, perhaps, of academic interest only. > > I think you can be very pleased with the result. I did my fair share of looking at disassembly code with objdump -d of the official jive binary when I was building the decoder code. Thanks. I am happy with the results and really don't think more investigations are required. The message is only printed at the log warn level and above, so it's not displayed with the default info level. mrw wrote: > I guess the decoder element is just seeing a lot more of the errors than > it would in the 'stock' firmware. Chasing that down seems to me to be a > real labour of love. Given that all incoming stream data is somewhat > protected by way of being delivered by TCP, and can reasonably be > assumed to come from a competent server, I think that you may have done > enough. > > Unless another hiccup should arrive out of the blue :) Agreed. Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 are 41 icy-metadata chunks in the file. So that might make sense. I was surprised that the stock firmware only reported one sync error, and appeared to play without blips. Perhaps the stock firmware is just "better" at gliding over corrupted incoming data and avoiding the problem in the first place. ralphy wrote: > > I also get concealing corrupted frames messages, which the stock > firmware doesn't report or appear to have similiar. > 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 enthusiasm, and it is, perhaps, of academic interest only. ralphy wrote: > > It's great to be able to confirm that the sync error code handles > works. > I think you can be very pleased with the result. I guess the decoder element is just seeing a lot more of the errors than it would in the 'stock' firmware. Chasing that down seems to me to be a real labour of love. Given that all incoming stream data is somewhat protected by way of being delivered by TCP, and can reasonably be assumed to come from a competent server, I think that you may have done enough. Unless another hiccup should arrive out of the blue :) mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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: > > > Jan 30 14:57:08 squeezeplay: DEBUG audio.decode - decode_start:703 decode_start > Jan 30 14:57:08 squeezeplay: INFO audio.decode - decode_start_handler:279 init decoder aac > ... > Jan 30 14:57:08 squeezeplay: DEBUG audio.codec - src/decode_aac.c:473 decode_aac_start(2) > > > > > > My tests are with LMS 8.01. Have there been changes in aac/mp4 > handling since then that might be influencing what the device has been > told about the stream ? > > It's disappointing. I thought I had an "easy" test file, but I suspect > that LMS/other factor is getting in the way. Without that out of the > way, it will be difficult to draw any conclusions. My goal was to > easily deliver a 'duff' aac stream. It seems that that is a failure on > your set up, for some reason. > > *Edit:* I've just re-run the test on Logitech Media Server Version: > 8.1.1 - 1610364019, the latest available. > I get the same result as I did before. Which seems to rule out LMS as > the source of the problem. Because when I copied the classicfm.aac file to my test system I stupidly changed the extension to m4a. Sorry about that. I'm running v8.2.0, git-91db8512b from yesterday on my test system. 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. I also get concealing corrupted frames messages, which the stock firmware doesn't report or appear to have similiar. At least I can't find anything. Code: strings jive | grep -i conc lua_concat _Z22CConcealment_SetParamsP14CConcealParamsi _Z18CConcealment_ApplyP16CConcealmentInfoP22CAacDecoderChannelInfoih prvBasePlusReconCoefficients _Z18GetConcealmentInfoi _Z27CConcealment_SetAttenuationP14CConcealParamsPsS1_ _Z27CConcealment_InitCommonDataP14CConcealParams _Z19FreeConcealmentInfoPP16CConcealmentInfo auReconCoefficentsHighRate_Dec chexReconCh _Z28CConcealment_InitChannelDataP16CConcealmentInfoP14CConcealParamsi concatenate CONCAT __concat %s:%d Not enough bytes. Couldn't get error concealment. %s:%d can't set conceal method (%x) It's great to be able to confirm that the sync error code handles works. I've attached the full log file from the CF radio test. +---+ |Filename: radio.txt| |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33196| +---+ Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 should be included. So it is reasonably full of "duff data". I play that file by dropping it into my music folder, and browsing for it in the Squeezeplay BMF menu. Findings: On the standard Radio firmware we appear to have solid playback. Surprisingly, only one 'sync error' is reported, although I expected to see many more. I don't know why we don't. On the Community version we get, as expected, a reboot. So, I don't know that this particular "stream with duff data" is necessarily a good sample for robustness testing, but it might be educational to see how your revised decoder fares with it. I've attached logs. +---+ |Filename: classicfm.aac.zip| |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33173| +---+ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 problem fixed, you have the freedom to do whatever you > think may be most practicable/expedient/useful/time to move on/whatever > you feel. Turns out the sample.m4a file in the ffmpeg ticket has the audio at the beginning of the file so can't be played native, so that file is no good for testing. When I optimized the file using mp4file or ffmpeg to move the atoms to the beginning it plays fine as the process "fixes/hides" the sync errors. You have to have MPEG-4 leading audio disabled in LMS file types as well for the test. I did some digging into the sync vs bits error logging between the stock and community firmware. The API has changed for sync error handling from the original proprietary fdk aac and the current android version 2.0.1 I'm using. Both the AAC_DEC_TRANSPORT_SYNC_ERROR and AAC_DEC_NOT_ENOUGH_BITS API errors are to be handled by reading more of the stream. In squeezeplay I tried checking for the SYNC error before BITS but the api still returns the BITS error for the 1.fm stream. I suspect if it wasn't for the segfault we wouldn't have even noticed. I did discover that I used the wrong return code for the SYNC error checking, which I've changed. Now I need to find a file/stream that triggers the error. Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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 problem fixed, you have the freedom to do whatever you think may be most practicable/expedient/useful/time to move on/whatever you feel. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 stream. In > general, though, you might just be responding to random/corrupted data. > But, whatever, it is doing the right thing. > > > Personally, I don't think I would be in too much of a hurry. It's always > good to allow matters to settle, and reflect on things. It's really good > that you were able to locate the source of the problem so quickly. 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. Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 the HTTP header is actively telling us that the stream is MP3: > > # Bug 3396, some m4a audio is incorrectly served as audio/mpeg. > # In this case, prefer the file extension to the content-type > mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 should be: https://trac.ffmpeg.org/ticket/7331 Perhaps that is already happening. Or perhaps the ticket is wrong. I have no knowledge. ralphy wrote: > With the patch I posted earlier ... the bad data is handled gracefully; > radio/touch pops up an error message, stops and LMS logs; > > > Code: > > [21-01-23 13:04:44.2620] Slim::Player::Squeezebox2::statHandler (149) Error: 00:04:20:XX:XX:XX: Decoder does not support file format, code 0 > > Which is true in this case, because you happen to have an MP3 stream. In general, though, you might just be responding to random/corrupted data. But, whatever, it is doing the right thing. ralphy wrote: > > I have not pushed r16826 to the community firmware repository yet as I'd > like to test it for a bit longer first. Personally, I don't think I would be in too much of a hurry. It's always good to allow matters to settle, and reflect on things. It's really good that you were able to locate the source of the problem so quickly. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 not > enough bits-. > The first log is not so clear, but I did not have full access before the > Radio rebooted itself. We may just be seeing some 'last gasps'. > > Of interest, I think, is the Standard firmware log. Here we see -DEBUG > audio.codec - src/decode_aac.c:124 sync error 4096 2148-. > > That makes me think the the standard firmware might have a stream > synchronization step prior to submitting frames to the decoder proper, > i.e. scanning the incoming stream for something that looks like AAC. Is > such a step taken in the Community firmware ? I could imagine that a > pre-scanning loop that glides over obviously duff data might improve > resilience where a somewhat corrupted stream is present. What does > -faad- do in terms of attempting synchronization ? > > I have no experience of this area. Thanks for the logs. They are similiar to what I'm seeing on both the touch and radio. 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. The reboot is caused by the watchdog after jive segfaults and exits from an out-of bounds memory access bug I had in the aac decoder which I 'described earlier' (https://forums.slimdevices.com/showthread.php?113719-1-fm=1005538=1#post1005538). In squeezelite, the faad decoder logs this and stops as you'd expect. Code: [14:17:11.374585] faad_decode:400 error reading stream header [14:17:11.375532] decode_thread:100 decode error] With the patch I posted earlier and is included in the '8.0.1r16826 firmware' (https://sourceforge.net/projects/lmsclients/files/squeezeos/) the bad data is handled gracefully; radio/touch pops up an error message, stops and LMS logs; Code: [21-01-23 13:04:44.2620] Slim::Player::Squeezebox2::statHandler (149) Error: 00:04:20:XX:XX:XX: Decoder does not support file format, code 0 I have not pushed r16826 to the community firmware repository yet as I'd like to test it for a bit longer first. The latest firmware builds also includes the About change we discussed elsewhere. Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 doesn't work if you have "*sort favorites list*" active in settings. *Server - LMS 8.2.0 *Pi4B 4GB/Argon one case/pCP v7.0.0 - 74K library, playlists & LMS cache on SSD (ntfs) *Study -* Pi3B/pCP 7.0.0/pi screen/Hifiberry DAC HAT Ruark MR1 Mk2 *Lounge* - Pi2/pCP 6.0.0 > HiFiBerry DIGI+ > AudioEngine DAC1 > AVI DM5 *Garage* - Squeezebox Boom + Fostex sub *Dining Room* - Pi3B/Bluetooth/Echo Show 8 *Spares* - 2xTouch, 1xSB Radio. 1xSB3, 6xRPi kidstypike's Profile: http://forums.slimdevices.com/member.php?userid=10436 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 on win 10 brix server, x2 sb radios, x1 touch, x1 controller : location 2: lms 8.0 on win 10 brix server, x2 sb radios, x1 duet receiver, x1 controller : alexa mediaserver smart skill, material android, squeezelitex control staresy's Profile: http://forums.slimdevices.com/member.php?userid=807 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 sub-folder. I'm using Squeezelite-X with the Material Skin, and drag-and-drop won't work. mitchhellman's Profile: http://forums.slimdevices.com/member.php?userid=32063 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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. > > https://github.com/ralph-irving/squeezeplay/blob/master/src/fdk-aac-2.0.1/libAACdec/src/aacdecoder_lib.cpp#L1960 > A good discovery ! ralphy wrote: > I found the problem with the FDK AAC decoder segfaulting in the > community firmware. > > Considering I wrote the aac decoder 18 months ago and this is the first > reported issue is pretty good and it took a "bug" in lms to expose it. > I would never had thought to test feeding mp3 data to the aac decoder. It's a very unfair world. :) 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 not enough bits-. The first log is not so clear, but I did not have full access before the Radio rebooted itself. We may just be seeing some 'last gasps'. Of interest, I think, is the Standard firmware log. Here we see -DEBUG audio.codec - src/decode_aac.c:124 sync error 4096 2148-. That makes me think the the standard firmware might have a stream synchronization step prior to submitting frames to the decoder proper, i.e. scanning the incoming stream for something that looks like AAC. Is such a step taken in the Community firmware ? I could imagine that a pre-scanning loop that glides over obviously duff data might improve resilience where a somewhat corrupted stream is present. What does -faad- do in terms of attempting synchronization ? I have no experience of this area. +---+ |Filename: Radio log - Community firmware - 4.txt | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33052| +---+ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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.
https://github.com/ralph-irving/squeezeplay/blob/master/src/fdk-aac-2.0.1/libAACdec/src/aacdecoder_lib.cpp#L1960
I also needed to force the AAC decode thread to stop when a decode error
is encountered.
This is the patch I'm currently testing on my linux system.
Code:
Index: src/audio/decode/decode_aac.c
===
--- src/audio/decode/decode_aac.c (revision 1327)
+++ src/audio/decode/decode_aac.c (working copy)
@@ -135,7 +135,7 @@
return FALSE;
}
- err = aacDecoder_DecodeFrame(self->heaacdec, (INT_PCM
*)self->output_buffer, OUTPUT_BUFFER_SIZE, 0);
+ err = aacDecoder_DecodeFrame(self->heaacdec, (INT_PCM
*)self->output_buffer, OUTPUT_BUFFER_SIZE / sizeof(INT_PCM), 0);
if (err == AAC_DEC_NOT_ENOUGH_BITS) {
LOG_DEBUG(log_audio_codec, "not enough bits");
@@ -150,14 +150,14 @@
/* Do concealment of corrupted frames */
if (IS_DECODE_ERROR(err)) {
LOG_WARN(log_audio_codec, "concealing corrupted frames %x",
err);
- err = aacDecoder_DecodeFrame(self->heaacdec, (INT_PCM
*)self->output_buffer, OUTPUT_BUFFER_SIZE, AACDEC_CONCEAL);
+ err = aacDecoder_DecodeFrame(self->heaacdec, (INT_PCM
*)self->output_buffer, OUTPUT_BUFFER_SIZE / sizeof(INT_PCM), AACDEC_CONCEAL);
}
/* Give up decoded on any other error */
if (err != AAC_DEC_OK) {
- LOG_DEBUG(log_audio_codec, "error %x", err);
+ LOG_DEBUG(log_audio_codec, "decode aac frame error %x", err);
- current_decoder_state |= DECODE_STATE_ERROR;
+ current_decoder_state |= DECODE_STATE_ERROR |
DECODE_STATE_NOT_SUPPORTED ;
return FALSE;
}
Considering I wrote the aac decoder 18 months ago and this is the first
reported issue is pretty good and it took a "bug" in lms to expose it.
I would never had thought to test feeding mp3 data to the aac decoder.
Ralphy
*1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio
'Squeezebox client builds'
(https://sourceforge.net/projects/lmsclients/files/) 'donations'
(https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted)
always appreciated.
ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484
View this thread: http://forums.slimdevices.com/showthread.php?t=113719
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 'co-prime' issues in play. :) mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 ? And, thereby, potentially introducing > an error, as in this case. > > I would like to believe that, these days, any servers that are > misconfigured would quickly lose most of their audience (I'm thinking > mobile telephones, etc.), and would be corrected by their operators > rather quickly. So the problem should now be too rare to warrant LMS's > special attention. > > But I don't have sufficiently wide knowledge of the real world to know > for sure. Perhaps the "attempt to fix" should just be removed (or > commented out). Then we might find out whether it still does, in fact, > achieve more successes than failures. 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. Last time it was fixed by clearing the entry in 2nd cache when first cache was being changed. So I'm guessing there is code path that wasn't patched last time (or maybe a new path created after AAC/MP4 remote streaming changes in 8.0 subsequent to the previous fix). I think I was wrong about audio headers but still right about caches out of sync. Down the rabbit hole. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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. 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 ? And, thereby, potentially introducing an error, as in this case. I would like to believe that, these days, any servers that are misconfigured would quickly lose most of their audience (I'm thinking mobile telephones, etc.), and would be corrected by their operators rather quickly. So the problem should now be too rare to warrant LMS's special attention. But I don't have sufficiently wide knowledge of the real world to know for sure. Perhaps the "attempt to fix" should just be removed (or commented out). Then we might find out whether it still does, in fact, achieve more successes than failures. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 solution as it is a bug fix on a bug fix on a bug fix (aaargh) > https://forums.slimdevices.com/showthread.php?111812-ByGolly-Old-Time-Radio=968645=1#post968645 I will follow through. Maybe I'll see something. But yes, I was beginning to wonder if we were seeing fixes on fixes on fixes, all in different places. :) mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 decoder needs to handle problem better. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 "lack of resilience" to duff > aac data would be eliminated by simply disabling native aac. But that > would not be effective if the user had, perhaps temporarily, switched to > MySqueezebox.com. > > This is the first time that I have encountered a problem with an aac > stream in the several months I have used the "draft" Community Firmware > release(s). The problem, I would say, lies firmly with LMS, nevertheless > one would wish that the firmware handled the problem rather more > gracefully. :)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. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 LMS has to knoe bitrate to know whether to downsample the stream to a player or not > Clearly SqueezePlay is being told that the stream is -aac-, hence the > problem. Yes Squeezeplay/Squeezelite etc assumes LMS has analysed the stream and so starts doing AAC decoding on a MP3 stream. I saw the problem because I was playing through a Receiver which was failing to transacode an MP3 stream using faad. > I don't know what the "old March 2020" problem is/was. Do you have a > pointer ? 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 solution as it is a bug fix on a bug fix on a bug fix (aaargh) https://forums.slimdevices.com/showthread.php?111812-ByGolly-Old-Time-Radio=968645=1#post968645 bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 does the transcoding. But you are right, the Community Firmware's "lack of resilience" to duff aac data would be eliminated by simply disabling native aac. But that would not be effective if the user had, perhaps temporarily, switched to MySqueezebox.com This is the first time that I have encountered a problem with an aac stream in the several months I have used the "draft" Community Firmware release(s). The problem, I would say, lies firmly with LMS, nevertheless one would wish that the firmware handled the problem rather more gracefully. :) mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 get > bitrate, contenttype etc.) the ContentType is set to "mp3" > So we're reading the headers _again_ ? bpa wrote: > > 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 ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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 slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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 [emoji1787] Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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
slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609
View this thread: http://forums.slimdevices.com/showthread.php?t=113719
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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. > > 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's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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. This seems to be a the same problem as before, LMS iniitally misidentifies the contenttype from by suffix or MIME but then later after examining the actual audio frames, LMS updates the ContentType but there were two caches and the corrected value gets lost. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 author of \"now playing\" plugins covering radio france (fip etc), kcrw, supla finland, abc australia, cbc/radio-canada and rte ireland Paul Webster's Profile: http://forums.slimdevices.com/member.php?userid=105 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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.
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=113719
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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. > > Have other users confirmed this is a real problem on their system and > not just a problem on mine due to non standard setup. It's a real problem - checked with a clean Pi system. The previous bug was related to ContentType cached in two places and the updated cache was not being used. This was fixed was around 23 Mar 2020 to file Slim/Utils/Scanner/Remote.pm "Feels" like it is same bug. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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.- > https://github.com/Logitech/slimserver/blob/public/8.1/Slim/Utils/Scanner/Remote.pm#L300 > > I suspect that this 'override' is the cause, but needs confirmation. The > change for bug 3396 was made in 2010, I would think by now all streaming > servers are reporting a correct -Content-Type-. So, perhaps the > 'override' can, now, be safely removed. > > I don't think one can ever know for sure, but I think I would now be > minded have more faith in the reported Content-Type than perhaps I might > have been in 2010.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. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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.- https://github.com/Logitech/slimserver/blob/public/8.1/Slim/Utils/Scanner/Remote.pm#L300 I suspect that this 'override' is the cause, but needs confirmation. The change for bug 3396 was made in 2010, I would think by now all streaming servers are reporting a correct -Content-Type-. So, perhaps the 'override' can, now, be safely removed. I don't think one can ever know for sure, but I think I would now be minded have more faith in the reported Content-Type than perhaps I might have been in 2010. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 the following. The "unk" showed up before I started playing so I think it is a left over of some sort. Code: [21-01-21 10:03:03.9225] Slim::Player::StreamingController::_playersMessage (796) Getting stream info...: http://strm112.1.fm/reggae_mobile_aac [21-01-21 10:03:03.9229] Slim::Player::Song::getNextSong (223) http://strm112.1.fm/reggae_mobile_aac [21-01-21 10:03:03.9231] Slim::Player::Song::getNextSong (245) scanning URL http://strm112.1.fm/reggae_mobile_aac [21-01-21 10:03:03.9246] Slim::Player::Source::playmode (95) 00:04:20:16:07:0e: Current playmode: play [21-01-21 10:03:03.9251] Slim::Formats::Playlists::M3U::write (251) Writing out: /mnt/hddrive/home/latest/trunk/prefs/clientplaylist_00042016070e.m3u [21-01-21 10:03:04.1463] Slim::Player::TranscodingHelper::getConvertCommand2 (485) Error: Didn't find any command matches for type: unk [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 bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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' HTTP/1.0 200 OK P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI" icy-name: reggae Connection: close Content-Type: audio/mpeg mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 with the 2nd 1.FM reggae > http://strm112.1.fm/reggae_mobile_aac - I can't get it to play with > Receiver. > > > The "single URL" setting makes a playlist of all the playable URLs so a > problem URL may happen again as it is in the playlist or LMS may just > move onto next URL in the list.The strange thing is my settings are Stop at > power off/remain Stopped at power on but it appears that sometimes that is ignored in the case of reboots. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 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 with the 2nd 1.FM reggae http://strm112.1.fm/reggae_mobile_aac - I can't get it to play with Receiver. The "single URL" setting makes a playlist of all the playable URLs so a problem URL may happen again as it is in the playlist or LMS may just move onto next URL in the list. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
Material Skin. 33030 +---+ |Filename: 1.FM.jpg | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33030| +---+ *Server - LMS 8.2.0 *Pi4B 4GB/Argon one case/pCP v7.0.0 - 74K library, playlists & LMS cache on SSD (ntfs) *Study -* Pi3B/pCP 7.0.0/pi screen/Hifiberry DAC HAT Ruark MR1 Mk2 *Lounge* - Pi2/pCP 6.0.0 > HiFiBerry DIGI+ > AudioEngine DAC1 > AVI DM5 *Garage* - Squeezebox Boom + Fostex sub *Dining Room* - Pi3B/Bluetooth/Echo Show 8 *Spares* - 2xTouch, 1xSB Radio. 1xSB3, 6xRPi kidstypike's Profile: http://forums.slimdevices.com/member.php?userid=10436 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 before. Sent from my Pixel 3a using Tapatalk slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 worked. > Sent from my Pixel 3a using Tapatalk go to the settings for NetRadio and tick the "display one url " box Man in a van's Profile: http://forums.slimdevices.com/member.php?userid=43627 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
RadioNet plugin 33029 ronnie +---+ |Filename: radionet.png | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=33029| +---+ Man in a van's Profile: http://forums.slimdevices.com/member.php?userid=43627 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 info... so I'm thinking of writing to them to see if they might improve the Roku channel, especially since both their webpage and their Android app have most (if not all) of these features. I'll ask about APIs, too. mitchhellman's Profile: http://forums.slimdevices.com/member.php?userid=32063 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 would probably be better for you but this should be a quick and easy workaround. Paul Webster http://dabdig.blogspot.com author of \"now playing\" plugins covering radio france (fip etc), kcrw, supla finland, abc australia, cbc/radio-canada and rte ireland Paul Webster's Profile: http://forums.slimdevices.com/member.php?userid=105 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] 1.fm?
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 Swiss :-). But no address or contacts form or developers documentation. If you can figure out whether they have an API, that would be helpful. ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
