Re: [SlimDevices: Radio] Community Build Radio Firmware
P Nelson wrote: > For the speaker output, does the Both Channels Stereo or Mono have the > same result, or is there actually a sonic difference? The reason I ask > does combining a right and left signal result to the same speaker result > in a canceling or enhancing an audio signal? Not @ralphy, but I would expect the same result. As I recall it, Both Channels (Mono) pushes (L+R)÷2 (i.e. Mid ÷ 2) into each of the L & R components. The Radio speakers DSP mixer simply combines L & R components with L+R, i.e. it makes Mid. Either way, we get the same result, theres no tinkering around with Side. Of course, if the source L & R has been mixed with some phase cancelling/enhancement/effects stuff then Mid could be made to sound odd, or just plain silent. I would suppose that such a source could hardly be a good candidate for monaural reproduction. The Radio headphones DSP mixer does nothing, i.e. it is a pass through. Im too far from my Radio to actually physically test mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radio disconnect from LMS, still active on wifi...
THildebrandt wrote: > > As i understand it, there no solution apart from establishing wired > connection, yes?? A solution to what ? This is the basic problem, we dont know what -what- is. It may be an issue with the Radios WiFi, it may be an issue with the router, or it may be something else. And different people may have different problems but conflate them into one single cause. If it is a relatively recent phenomenon, Id be investigating what may have recently changed. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=117231 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radio disconnect from LMS, still active on wifi...
You could try Advanced settings|Diagnostics|Network Health|Repair network, it might be quicker than a full restart. I think Id be looking at network connectivity generally, rather than the Radio. But who can know for sure ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=117231 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
Heuer wrote: > Maybe UE has a different WiFi chip? Maybe. As far as I can see, there was no change to the WiFi element of the firmware. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
Heuer wrote: > Whilst troubleshooting I found both the Radio and Vonets would connect > reliably to the AP in my office but not to any of the other three AP's. > A swift comparison of the AP settings revealed three had 'band steering' > switched on whereas the Office AP did not. Switched all off and Radio > now connects happily and no need for Vonets. > > Interestingly this setting only affected the UE Radio, other two > 'normal' Radio's are not affected by band steering. An interesting observation . What firmware version are you using on the 'normal' Radios that are affected ? I think I would have expected no difference in behaviour. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
JJZolx wrote: > Something I never asked (or looked for), but do the connection issues > happen on both 2.4 GHz and 5 GHz bands? I had been using only 2.4 GHz > when all of my connection problems began. Logitech's players can't use the 5 GHz bands. The technology was not available when these devices were designed/manufactured. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] How to force Radio to display screensaver?
RobbH wrote: > I take it back! After a reboot of the LMS server, the Radio screensavers > are now working as expected. Perhaps a consequence of tghis chnge in the Community Firmware: https://github.com/ralph-irving/squeezeos-squeezeplay/pull/3 mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=117148 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
Syco54645 wrote: > > I see the radio occasionally on my router but it drops off as soon as it > shows up. It seems to be boot looping. > My bad. It would be boot looping because Squeezeplay didn't start, as indicated by the fact that you could only see the Logitech screen. The factory reset certainly reverts everything back to pristine firmware, providing a fat finger countermeasure. To quote the -ssh- login message: > > You can safely modify any of the files on this > system. A factory reset (press and hold add on power on) will remove all > your > modifications and revert to the installed firmware. > A firmware update does _not_ overwrite the contents of the -/etc- hierarchy, which is where your -rc.local- lives. That may be what you picked up on. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
Syco54645 wrote: > I was setting up wlan poke on one of my radios and I mist have > fatfingered the rcS.local as the radio is no longer booting, it just > sits on the logitech screen. Is there a way to get past this so that I > can fix my gaf? The -ssh- daemon and wifi should be running by that point. Did you try ? Otherwise I think it would be factory reset time. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
mherger wrote: > > Are you saying that the community firmware uses a "blob", whereas the > original _might_ have built from the source? I'll have to poke around > private repositories... >From the looks of it, Id say the original (kernel module and firmware binary blobs) was 99% certainty built from a source package(s). With the exception of, perhaps, calData_ar6102_15dBm.bin. That is my interpretation of the commit history: https://github.com/Logitech/squeezeos/commits/public/7.8/poky/meta-squeezeos/packages/atheros The binary blobs poky recipe, used by the community firmware, was created fairly late in the day. It would not surprise me to find a too small buffer somewhere, but thats just idle speculation. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
mherger wrote: > I'm looking for someone who's got a very good understanding of how WLAN > works, in particular in the Radio, or where in the SqueezeOS source the > wlan is being configured. I've been in touch with one vendor of Wifi > routers (AVM/Fritz!Box). Their latest dev firmware would break > compatibility with the Radio. They have been able to identify one cause > for the failure - but are asking questions I can't answer myself. > > They believe that the problem is related to 11ax (wifi6?) and WLAN > beacon size. Now they're asking whether the beacon size was limited in > firmware or similar. Alas... I have no idea how to figure out. I'm not > too familiar with the firmware code base. Would anybody out there know? My thoughts. Others may have more information. The Radio's Wifi is something of a closed book to us, because the source code (whatever it may hold) is "PRIVATE" - i.e. it requires access to the private subversion repository to review and build. We have to use a "binary only" poky recipe to populate the firmware image. Here is a link to the relevant poky build recipes (Logitech repo): https://github.com/Logitech/squeezeos/tree/public/7.8/poky/meta-squeezeos/packages/atheros. (Ralphy's repo: https://github.com/ralph-irving/squeezeos/tree/public/8.0/poky/meta-squeezeos/packages/atheros). The Atheros driver supplied (ar6000.ko) provides a Wext (Wireless extensions) interface to the hardware, and is used by wpa_supplicant to do its thing. The script 'wlan' shows how the firmware is started up. It uses 'loadAR6000l.sh' and 'wmiconfig' to configure the hardware. On the Radio these are are found in '/lib/atheros' with the wlan script in ' /etc/init.d'. I do not have a very good understanding of Wifi nor experience of Wifi drivers. Perhaps access to the source code would throw light. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way ro subscribe to this podcast or any other using
bwaldron wrote: > This can help in that regard: https://getrssfeed.com Very neat. Thanks. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=117019 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way ro subscribe to this podcast or any other using
jeanwedding wrote: > Standalone. SB only please for Pretty please rhwere is no ay Im gong to > keep my old comp running all the time > > flatearthpodcat.com.so I can just copy and past it please > and how can we find podcast lists that. will play on our SB > standalone??? > rhanks all and I do appreciate yall advice and most worksyeah For standalone SB, log in to your account at MySqueezeBox (https://www.mysqueezebox.com), take the "My Apps" tab and choose "Podcasts". Paste the relevant rss feed URL into the "Add a podcast feed" box at the bottom, and click on "add". If you don't see the "Podcasts" app under "My Apps", you'll need to install it from tab "App Gallery". The URL I find for your flatearth.com podcast is: https://feeds.soundcloud.com/users/soundcloud:users:321459426/sounds.rss Once done, you should then be able to browse into this podcast listing on your device, under the Podcasts menu somewhere on the device - probably in "MyApps", and choose an episode to play. This might be a bit hit and miss, although it did work on my Radio. Reason being that the Radio cannot handle "https" audio streams, it can only handle "http". There is a chance that the podcast will provide "https", in which case - fail. But it did work for me, so I guess it's providing "http" streams. I'm not sure what the good/best/easy to use sources for podcasts are. What you need is the "RSS" link. But I find fewer and fewer podcast publishers provide that. They provide links for iTunes/Apple, or Google podthing, or something, which are very easy to use if you are using an iThing, or an AndroidThing, or SomeOtherThing. But they don't make it easy to find the actual underlying RSS URL. But that's what we need. Probably most of them don't know what it is, because they have an easy to use PublishingThing which hides the details from them. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=117019 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
rdeckard wrote: > > The key thing here seems to be disabling wlan, but possibly requiring > stock firmware when doing so? @POMdev identified that the WiFi components seemed to be hogging the CPU, according to your 'top' listing. That would certainly give rise to sluggishness. If the WiFi is 'regularly' misbehaving in that manner, then disabling the wlan, as you did, should remove the sluggishness. Of course we don't know why the WiFi is apparently misbehaving... I wouldn't expect any difference in behaviour between 'stock' and 'community' firmwares. If you find that there is a difference, reliably, please report back. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
rdeckard wrote: > > Came back less than an hour later, and it was already in the > sluggish/unresponsive state. Does it show the very high CPU usage for those wi-fi radio related tasks, which you saw before, while in this state ? If so, might be worth trying to disable the wlan subsystem and seeing if the problem persists. I recall that you found a thread that shows how to do that. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
rdeckard wrote: > > What's the best way to retrieve logs from the Radio? > Login via SSH. Enable it in the advanced settings. Log is /var/log/messages Log does not survive a reboot, so copy it to the root user directory to preserve. Alternatively collect using scp. I have occasionally had sluggishness, but not enough to investigate. Is there a common feature, e.g. a particular track or stream ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] So long, Squeezebox Radio
Presumably WiFi 6 / Mesh / whatever Power line adapter(s) ? Could fit some scenarios. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=116906 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Red vs Blue Wi-Fi Icon on SB Radio
P Nelson wrote: > > Why red vs blue, and what might be different? > Red: no network connection. Blue: network connected, but no connection to LMS. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=116818 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Radio run time on battery
Redrum wrote: > but out of curiosity, could a reduced timeout be set via a selection of > settings in the radio settings menu? An Applet could be made to provide access to that setting, I think. I did something along those lines to enable modifying the Alsa buffer size. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=116234 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
FredFredrickson wrote: > Does this have any potential applications for the Duet Receiver? My > receivers fall offline all the time. No. Duet Receiver runs different firmware. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
SlimChances wrote: > EDIT: I think this is a different problem. My Radio will play internet > radio streams(so wifi works) but not my local library. Will post in a > separate thread. A blue wifi icon indicates that the wifi is connected to your AP and has a working network connection. But the Radio has not been able to connect to a server (local LMS or MSB.com). So, yes, this would seem to be a different problem to the problem addressed in this thread. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Radio dropping connection to LMS
FlossenNacht wrote: > > They're showing up on my router as connected devices. But they can't get > a ping on my LMS. Do they ping anything else? Example: ping www.google.com mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115297 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Installing Squeezebox
bobb wrote: > When i installed LMS on this new pc i didn't paste the " old" prefs > file, and was surprised my radio presets were there, i am meaning the > long press presets. > i can set them new but why are they gone after choosing " squeezebox > radio"? Possibly your Radio was connected to MySqueezebox in the cloud, and not your local LMS. MySqueezebox also keeps its own set of presets. When you chose the Radio in your local LMS, the Radio then uses LMS, and looks to LMS for its presets. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115356 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Installing Squeezebox
bobb wrote: > > In LMS settings the "player" was empty, so i went to " home" and at the > top right i could choose " squeezebox radio", in "settings" the radio is > there but my presets on the radio are gone and i can only listen to > radio via the web interface. > I must be missing something? Presets are stored in LMS prefs, not the Radio. Easy way to set a preset is to long press the preset button on the Radio when its playing the stream. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115356 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Radio dropping connection to LMS
FlossenNacht wrote: > It seems I misunderstood the problem, apperently they're not dropping > the connection to my NAS, they're dropping the connection to the > network. > I now have tried to assign them static IP's. > I'll keep you posted if it worked or not. Might be worth a look if it doesn't work out: https://forums.slimdevices.com/showthread.php?115124-Work-around-for-SqueezeBoxRadio-wifi-drop-out https://forums.slimdevices.com/showthread.php?114775-Simplified-instructions-for-Squeezebox-Radio-Wi-Fi-fix-(wlanpoke) https://forums.slimdevices.com/showthread.php?109953-WiFi-connection-unstable-lost-on-three-Radios mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115297 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Work-around for SqueezeBoxRadio wifi drop-out
aidy_w wrote: > Hi, > Both are dependent on the the atheros wireless driver. This seems to > have a bug that places it into a uni-directional state. Traffic out from > the IP layer but responses do not make it to the host. > Not just IP, I think. I did manage, once or twice, to get my Radio into this state, probably due to very poor positioning/bad signal strength relative to the AP I had set up [1]. I observed that it would send reassociation requests to the AP just fine, but completely ignored the APs positive responses. This was evident from the APs log. Its not easy for me to reproduce the conditions and examine further. Particularly as I generally use the Radio for its intended purpose of listening to music. [1] Tinkering with hostapd on a Raspberry Pi. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115124 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
Tony T wrote: > not sure why you don't put the logs into a folder that survives a > re-boot Wear on flash memory ? By default, there is considerable logging activity. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way to get the remote control again to get my presets to work with the re
agbagb wrote: > > Though, am I correct in thinking, from my few experiments today, that a > remote # button can only either PLAY or SAVE, despending on the setting > chosen in the beta menu? That there's no medium push for PLAY, super > long / double push for SAVE or some such? I believe so. The medium/super long distinction is in play for the Classic, and presumably Boom/Transporter. They are driven by a different control system which, essentially, runs on LMS, in contrast to the Radio/Touch which run and are driven by SqueezePlay. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115084 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way to get the remote control again to get my presets to work with the re
agbagb wrote: > However, I think this may be easier on Radio. On the Radio it seems to be very easy. For option 'IR Hold 2' I am presented with a large list of choices, including 'Play preset 2' and 'Set preset 2'. So I take 'Play preset 2', following which it will be ticked in the UI, and long hold on the button will play out preset 2. If I then decide to take 'Set preset 2', well, then that one will be ticked instead and, I suppose, active. Which said, I did manage to find myself set up with an 'Add to end' once, I'm not sure why. Perhaps there are some beta quirks present in the operation of the menu. I don't have a Touch, so I don't know what challenges that may be presenting. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115084 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way to get the remote control again to get my presets to work with the re
Excellent ! Thank you all. I now have my Radios set up so that Holding buttons 1 -> 6 on the remote will play presets 1 -> 6, just like on my Squeezebox Classic. I don't need to use the remote to save presets - I can walk over to the Radio and use its buttons to do that, on the rare occasions that I want to change the presets. Or use the web interface. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115084 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way to get the remote control again to get my presets to work with the re
mrw wrote: > Mine works, although its a knack. HA ! How wrong can one be. I have described the position with a Squeezebox Classic. But it does not work on a Squeezebox Radio, which I think is the subject matter of this thread. Did it ever ? I dont remember. Perhaps time for a look mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115084 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] is there a way to get the remote control again to get my presets to work with the re
jeanwedding wrote: > I still hate the fact that my nice Logitech remote I bought when they > were first available no longer can use it to play one of my six set > favorite buttons On MY STAND ALONE Squeezebox. buttons to work via the > remote control? It used to when the remote I first used it. Then a > firmware update made the preset not work with the remote Has there been > a fix for this? that why I bought several remotes and SB radios. Thanks > all PSIm not interested in keeping a comp or laptop constantly > running to be able to play all my SBs. Mine works, although its a knack. A longish hold to play the preset. Longish needed, because otherwise the number is interpreted as an item in the current menu. A really long hold to save the current track as the preset. And, just to be sure, I tried it just now, because I havent set a preset in some years it still works ! mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115084 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radio no longer powers on
isolli wrote: > Thanks for all the replies! Time for an update. > > I removed the battery. It changed nothing to the problem I described. > The battery might be dead, but the problem seems to be with the power > button. > > I am in the same situation as bstrulo: I recently took the radio out of > storage, and the power button seems jammed. Unfortunately, I wasn't able > to fix it like bstrulo did, by repeatedly pressing the button until it > improved. Someone once remarked that, after taking a radio out of storage, it would not start. But, after leaving it plugged in overnight, or for several hours, it would then start. Might be worth trying. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=115023 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
P Nelson wrote: > Not sure why WinSCP does not want to work with the stock firmware vs the > community firmware, assuming SSH might be an issue. Ah ha ! Possible light bulb moment: The stock firmware SSH requires the use of older, now outdated, key exchange and cipher algorithms. I guess that a modern WinSCP might not enable these by default. Certainly modern OpenSSH doesn't. I don't know how one persuades WinSCP to use the older algorithms, but someone will. In openSSH I would be saying something like: KexAlgorithms +diffie-hellman-group1-sha1 Ciphers +aes128-cbc,3des-cbc,aes256-cbc mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
P Nelson wrote: > I sense in reading the Community build forum is that the Wifi > interference problem did not impact very many people, so there was > limited interest to including it in the community firmware. Not so much limited interest, from my point of view, but rather awaiting results of research. Following which, figuring how best to introduce the logic implemented by wlanpoke into the firmware, if that is appropriate. However, as I don't experience the issue, it would be rather difficult to validate the result... mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)
P Nelson wrote: > Any idea on resolving this error message? a) Have you enabled remote login on that Radio ? b) I don't know why you are getting a SFTP message. I assume that you are trying to use SSH. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114775 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
Heuer wrote: > For the first time ever one of my Radio's lost its bass response this > morning despite it running the latest community firmware. Seems the > issue is still not fixed. OK, so that makes at least two of us ! https://forums.slimdevices.com/showthread.php?104141-Bass-amp-problem=997227=1#post997227 mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
mikitil wrote: > Only thing i'm not 100% happy with, its a disco light to, its leds ar so > bright and pulsing. Perhaps some of this :) : https://www.amazon.co.uk/AmazonCommercial-Electrical-centimeters-Multi-Color-10-Pack/dp/B07YDSNGCT/ref=sr_1_1_sspa?adgrpid=53419212375=1=Cj0KCQjwna2FBhDPARIsACAEc_UN9bqg4Bq9x-UOcrB5xHX4WESPvCbP8E1n5oaLsis9z-k90SoYPlUaAlZbEALw_wcB=259087081561=c=9045917=g=e=4527009925982921836=kwd-21804356=28150_1724812=electrical+tape=1621875065=8-1-spons=1=ZW5jcnlwdGVkUXVhbGlmaWVyPUEzRjJJUjAyUTlNUkhIJmVuY3J5cHRlZElkPUEwNDg4MDI4M1BMQ09MSjE0SDhQTiZlbmNyeXB0ZWRBZElkPUEwNDM4ODc1VkJMUjlLMllPTjU5JndpZGdldE5hbWU9c3BfYXRmJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ== mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
mikitil wrote:
> Bonus question 2: I have seen now sometimes one or the other Radio
> loosing Bass, don't really know how to say this right. All works on this
> Radio and then from one moment to another one is loosing Bass but i hear
> what is playing just without the deep tones? Not always the same radio
> and not only since firmwareupdare.
If you are referring to the issue raised in this thread ("Bass Amp
problem")
https://forums.slimdevices.com/showthread.php?104141-Bass-amp-problem
then I would expect you to find that the community build firmware
effectively fixes the issue. That has been my experience, anyway. (The
community build firmware has been modified to take account of it.)
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=111663
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
kllngtme wrote: > okay, so one more thing I wanted to throw out there. Has anyone else had > wifi issues trying to connect to a hidden SSID since the community > firmware updates have been applied? I saw something done with the wpa > configs in the radios but I wasn't sure what it meant exactly. > > My problem is that the radios just disconnect off the wifi. The wifi > logo will go blue sometimes and or red completely. Signal strength isn't > the issue. I'm noticing the radios seem to continue seeing my non hidden > SSID's but the hidden SSID seems to show no signal when the radio gets > disconnected. I can connect to my non hidden SSID it seems though so I'm > thinking it's just an issue with connecting to hidden SSID's? Anyone > else had anything similar? It's conceivable that you might have trouble with a hidden SSID, due to changes in the version of wpa_supplicant used. But I think I know how to fix that. Which said, I have never tried connecting to a hidden SSID. How does one go about doing it ? If you can tell me, I can go about testing the fix that I think may be necessary. If you're seeing a blue icon, the Radio thinks it has a good network connection, but is having difficulty with connecting to LMS. If red, then it believes that there is not a good network connection mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
Tony T wrote: > ok, but my original question... No, which was the first word given in my answer. :) mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
Tony T wrote: > Is wlanpoke now included as part of the CBRF? No. There is no "CBRF" per se. The "Community Firmware for Squeezebox Radio/Touch/Controller and LMS 8" thread is here: https://forums.slimdevices.com/showthread.php?113479-Announce-Community-Firmware-for-Squeezebox-Radio-Touch-Controller-and-LMS-8 The first post has a link to the CHANGELOG. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > The wireless extensions version is 22. Thank you for that, I thought I had come across the definition in the past, but couldn't remember where. There's nothing better than a hard fact, which you have (kindly) provided, to spoil a perfectly good tale ! It turns out that our -ar6000.ko- seems to have chosen to increment the SSID length it is provided, by one. Not just for its own use, mind, it increments the length in the data buffer provided by the originating -SIOCSIWESSID- ioctl call. That (now changed) data buffer then informs the kernel's subsequent -wireless_send_event- event notification. And if the SSID was 32 bytes long, well, it now appears to have been 33 bytes long. I shall add that the kernel's -ioctl_standard_call- is also capable of tinkering with the SSID length in some circumstances, but seems to be capable of cleaning up after itself... (-net/wireless/wext.c-). I found one sample of an AR6000 driver source code that appeared to display this behaviour, and several that did not. Never mind that the sample I found is apparently for an AR6003, and Linux v3.3. The fact that one driver source appears to have done it suggests that others might have done it. That sample carefully increments the length if -WIRELESS_EXT > 20-, presumably because it knows, I suppose, that -wpa_supplicant- and friends will have taken care _not_ to increment the length in this circumstance. Ho hum. (File wireless_ext.c at: http://dl.linux-sunxi.org/SDK/A20/A20_SDK_20130319/lichee/linux-3.3/modules/wifi/ar6003/AR6kSDK.build_3.1_RC.514/host/os/linux/ But not worth examining. ) A little peek inside our -ar6000.ko- seems to reveal the same behaviour. There is always room for misinterpretation/error... Anyway, we can legitimately "squash" the kernel complaint by simply restricting the "random SSID" to 31 bytes in length, not 32, so my tale still contains a kernel of truth. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > 33 is the only length I've seen. > > I've added this for all players to 8.0.1r16852 which is now on > sourceforge and removed the patch above which I had only applied to the > radio firmware. Thank you very much. As I raised the point, I thought I'd better have a look... :) This is on a Radio: Code: Mar 30 11:37:58 kernel: [ 180.444967] eth1 (WE) : Wireless Event (cmd=0x8B1A) too big (33) Mar 30 11:37:59 kernel: [ 180.459621] AR6000 disconnected from 78:dd:12:cd:a2:f2 Mar 30 11:37:59 kernel: [ 180.602091] eth1 (WE) : Wireless Event (cmd=0x8B1A) too big (33) Mar 30 11:37:59 kernel: [ 180.632777] AR6000 disconnected Mar 30 11:37:59 kernel: [ 181.255741] AR6000 disconnected Mar 30 11:37:59 kernel: [ 181.264227] eth1 (WE) : Wireless Event (cmd=0x8B1A) too big (33) Mar 30 11:38:09 kernel: [ 191.271217] AR6000 disconnected Command -0x8B1A- is -SIOCSIWESSID-. It sets the SSID. SSIDs have a maximum length of 32 bytes. After running through the current hostap sources (which incorporate -wpa_supplicant-), I find a plausible cause: -wpa_driver_wext_disconnect- Amongst other things: > Set a random SSID to make sure the driver will not be trying to > associate with something even if it does not understand... Note that the random SSID is of length 32. https://w1.fi/cgit/hostap/tree/src/drivers/driver_wext.c?h=hostap_2_9#n1985 -wpa_driver_wext_set_ssid- Will add on extra character (NUL) to the SSID if -drv->we_version_compiled < 21-. https://w1.fi/cgit/hostap/tree/src/drivers/driver_wext.c?h=hostap_2_9#n182 So, possibly we have some kind of mismatch here if the wireless driver is compiled for wireless extensions < 21 (is it ?). Because setting a random SSID, or any SSID, of length 32 won't work, because -wpa_supplicant- will bump the length by one, to 33. I won't pretend that it makes 100% sense to me, I would have thought that it might have been spotted some time ago. But perhaps there aren't any current bits of wireless kit that use wireless extensions < 21. I have always associated the kernel message with connection/disconnection events, although that's not saying much. But I think I spin a plausible tale, even though it may not be supported by hard facts. Hard facts require a more rigorous investigation. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
POMdev wrote: > What is your radio's signal level? That 45 seconds does seem like a long > time. Good call. -68dBm -> -70dBm, at that location. (A short ethernet cable's length away from my iMac). Not enough to reliably receive broadcasts, in my experience. At -53dBm (normal location) I seem to be getting consistent completion within 12 -> 15 seconds, with just one, successful, udhcpc renew. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
POMdev wrote: > If SqueesePlay restarts wpa_cli, I guess it is safe to do so in the > script...??? What about restarting wpa_supplicant (thinking about that > as a next script step)? The following sequence of events seems to work. One point is that, in -wpa_supplicant.conf-, the current network is not "disabled", so, on restarting, -wpa_supplicant- will automatically attempt to reconnect. I think that's how it is, anyway. -wpa_cli- will not run without -wpa_supplicant- running, basically (I think) because the control socket (-/var/run/wpa_supplicant/eth1-) is not present. Latest source code seems to add an --r- option to keep it running regardless. SqueezePlay appears to be unfazed, it seems to re-establish its connection to the control socket when -wpa_supplicant- is restarted. (See -/tmp- for extant sockets created by -wpa_cli- and SqueezePlay). But I don't know how robust it all is... Sourcing this script: Code: killall wpa_cli killall wpa_supplicant # Note - udhcpc is left running /usr/sbin/wpa_supplicant -B -Dwext -ieth1 -c/etc/wpa_supplicant.conf -t /usr/sbin/wpa_cli -B -a/etc/network/wpa_action # I don't seem to need this, because it takes about 10 seconds # for a reconnection to occur. So wpa_cli is already running # by the time a "CONNECT" message is generated, and it will # trigger wpa_action to do this. #kill -usr1 `cat /var/run/udhcpc.eth1.pid` Gives this log output: Code: Mar 27 13:25:46 kernel: [62748.835724] eth1 (WE) : Wireless Event too big (33) Mar 27 13:25:46 kernel: [62748.848882] AR6000 disconnected from xx:xx:xx:xx:xx:xx Mar 27 13:25:46 kernel: [62748.977828] eth1 (WE) : Wireless Event too big (33) Mar 27 13:25:46 kernel: [62748.983375] AR6000 disconnected Mar 27 13:25:46 kernel: [62749.544881] eth1 (WE) : Wireless Event too big (33) Mar 27 13:25:46 kernel: [62749.549242] AR6000 disconnected Mar 27 13:25:56 kernel: [62759.564458] AR6000 disconnected Mar 27 13:25:57 kernel: [62759.823446] channel hint set to 2437 Mar 27 13:25:57 kernel: [62759.843344] AR6000 disconnected Mar 27 13:25:57 kernel: [62759.903100] AR6000 connected event on freq 2437 with bssid xx:xx:xx:xx:xx:xx listenInterval=100, beaconInterval = 100, beaconIeLen = 22 assocReqLen=62 assocRespLen =76 Mar 27 13:25:57 kernel: [62759.918990] Network: Infrastructure Mar 27 13:25:57 root: wpa_action eth1 DISCONNECTED Mar 27 13:25:57 root: wpa_action eth1 CONNECTED Mar 27 13:25:57 udhcpc[7967]: Performing a DHCP renew Mar 27 13:25:57 udhcpc[7967]: Sending renew... mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > There is also a 'kernel patch to fix the Wireless Event too big > messages' > (https://github.com/ralph-irving/squeezeos/commit/edf339db574b10c9375972029e4c8fd91942aff0) > but I still get the occasional one in /var/log/messages. The only Wireless Event too big message that I can recall seeing is -eth1 (WE) : Wireless Event too big (33)-. '33' being the length of the offending message. Have you ever seen any others with different lengths ? I found a commented patch, otherwise identical to yours, here: https://www.spinics.net/lists/linux-wireless/msg21543.html. The relevant maximum permitted message length is -IW_CUSTOM_MAX-, which is defined to be 256. So the "Wireless Event too big" messages that I see are outside the scope of this patch. The kernel message is being sourced from here, in - wireless_send_event- (I think): https://github.com/Logitech/squeezeos/blob/585fb6501704f0ca93e2bde662ccf4f8c4c9af10/src/s3c2412/linux-2.6.22/net/wireless/wext.c#L1225 We might get a little more information by printing out the command as well, i.e. by replacing: Code: printk(KERN_ERR "%s (WE) : Wireless Event too big (%d)\n", dev->name, wrqu->data.length); with Code: printk(KERN_ERR "%s (WE) : Wireless Event (cmd=0x%04X) too big (%d)\n", dev->name, cmd, wrqu->data.length); The replacement being motivate by this patch taken up within the current kernel code: https://github.com/torvalds/linux/commit/e5f5b2fb07353de00ffde49221cffad71e2fecfe Perhaps something to slip in on a next test build. It might help track it down, even though it may not actually matter. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
POMdev wrote: > Checking the 7 radios here, wpa_cli was not running on 4 of them! So, > for these radios at that time, a simple re-association would not be > enough to keep SqueezePlay or jive happy. > > The latest 0.7.5 code on the GitHub development branch includes a > function to check if wpa_cli is running, and, if not, to relaunch it. > This is called before every ping test. Preliminary testing here shows > that the wpa_cli is being relaunched at more or less random times > unrelated to wireless connectivity, including on radios that have had no > serious ping failures or restarts. > > Either wpa_cli is exiting on its own, or something else (I hope not the > script) is killing it. Of course, the hard reset kills and relaunches > it, but that has always worked. I doubt it is the script. I will read > through the wpa_cli code and see about adding or enabling debug logging > to pinpoint this phenomenon. BTW, the recEvent utility also casts > suspicion on wpa_supplicant or wpa_client, see the earlier post on this. I think it be very helpful to find out what is killing it. If it is not the script, then that may hint at a problem with -wpa_supplicant-, or with its control socket. Some additional notes. There is room for error ! The reason, I think, that -wpa_cli- is being run as a daemon is to react to events from -wpa_supplicant-. The only thing it is actually doing is to "kick" -udhcpc- into renewing the lease when a connection event is noted. As far I can tell, that is all it is doing. SqueezePlay itself does not require -wpa_cli- be running, other than to deliver that kick, because it communicates with -wpa_supplicant- directly through its control socket (as does -wpa_cli-). The socket is -/var/run/wpa_supplicant/eth1-. SqueezePlay does restart -wpa_cli- when it brings a network up. (-Networking.lua- function -_ifiup- calls -restartWpaCli-). SqueezePlay itself does have the ability to respond to events from -wpa_supplicant- if it chooses. But it does not so choose. See -attach- / -detach- following -jive.net.Networking:request()-. That might be a route towards logging -wpa_supplicant- events. -wpa_cli- will work from the command line regardless of whether it is running as a daemon. But it is the daemonized instance that would "kick" -udhcpc- when a reconnection takes place. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > Good idea to not burden this topic with diagnostic or code-related > details. That is more suited for the Community-Build-Radio-Firmware > topic. Why not a completely new topic ? I think it would be much easier to find and follow. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > Right. I read through the Networking.lua code to see what it was doing, > then to the icon, and setting the status, and got lost! But in the > meantime, in investigating a too-long red icon, checking routing (cat > /proc/net/route), the gateway was missing, and didn't return for quite a > while. Apparently, the re-association alone caused this entry to be > deleted, hence the down/up reset, which I thought would trigger a lease > renewal to restore the entry. It did, but not rapidly enough. > > But then, using your tip, wpa_cli reassoc ; kill -s USR1 `cat > /var/run/udhcpc.eth1.pid` ; cat /proc/net/route works very quickly, the > gateway entry is still there, and the icon does not turn red at all, an > apparent big improvement over the previous code. > > However, after doing this several times, my radio on the TTL serial now > works with the just re-association alone, perhaps beaten into > submission? I wonder knowing what is causing the gateway entry to be > deleted, and that 'arp' 'address in use' message seen earlier? > > Perhaps this also will improve the success rate of the so-called > ResetQuick() method. This deserves some testing to make sure there are > no side effects. Thanks again. A successful re-association will trigger the -wpa_action- script into "kicking" -udhcpc- into renewing the lease. I think that taking the interface down at this point with -ifconfig- simply prevents/hinders -udhcpc- from doing its job. One shouldn't need to be "kicking" -udhcpc- again. I imagine that the gateway is being cleared by -udhcpc-, immediately prior to renewing the lease, after which it would load the new one. I doubt that re-association per se is the cause. But I haven't checked that. -udhcpc- is part of busybox, so the source code could be checked to obtain complete clarity. The "arp address in use" message is caused by not getting a "null' response to the ping in reasonable time (refer code in -Networking.lua-). If the interface is down, -arping- won't even try. SqueezePlay doesn't know/care what the true cause of the error is. Remark: SqueezePlay does most of its work using -ifup[i/] and [i]ifdown-, which pull the pre-up, post-down, etc., network action scripts into play. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > Thanks, that's amazing. Could you please check this alternative, which > may work on your community firmware machine: > > wpa_cli reassoc ; ifconfig eth1 down ; ifconfig eth1 up > > On the stock firmware, the network continues to work correctly, the > music keeps playing without interruption, but the wireless icon stays > red longer, suggesting that all is not well, which we do not want. The > matter of cooperation with the player requires further investigation, > and it is perhaps time for a community firmware test machine here. Well, it works, and with the longer red icon as well. But I'm not sure what you intend to achieve with the -ifconfig eth1 down ; ifconfig eth1 up-. I suspect that all it does is to delay -udhcp-'s attempt to renew the lease. Hence, possibly, the red icon. Also bear in mind that SqueezePlay only updates the icon every 5 seconds. Stock firmware log following -wpa_cli reassoc-: Code: Mar 22 23:46:24 kernel: [53445.450449] channel hint set to 2437 Mar 22 23:46:24 kernel: [53445.464623] AR6000 disconnected from 78:dd:12:cd:a2:f2 Mar 22 23:46:24 root: wpa_action eth1 DISCONNECTED Mar 22 23:46:24 kernel: [53445.884750] AR6000 connected event on freq 2437 with bssid 78:dd:12:cd:a2:f2 listenInterval=100, beaconInterval = 100, beaconIeLen = 22 assocReqLen=62 assocRespLen =76 Mar 22 23:46:24 kernel: [53445.900127] Network: Infrastructure Mar 22 23:46:25 root: wpa_action eth1 CONNECTED Mar 22 23:46:25 udhcpc[8399]: Performing a DHCP renew Mar 22 23:46:25 udhcpc[8399]: Sending renew... Mar 22 23:46:27 udhcpc[8399]: Lease of 192.168.1.65 obtained, lease time 86400 Mar 22 23:46:27 root: udhcpc_action eth1 renew ip=192.168.1.65 Stock firmware log following -wpa_cli reassoc ; ifconfig eth1 down ; ifconfig eth1 up-: Code: Mar 22 23:48:05 kernel: [53546.780711] channel hint set to 2437 Mar 22 23:48:05 kernel: [53546.795065] AR6000 disconnected from 78:dd:12:cd:a2:f2 Mar 22 23:48:06 root: wpa_action eth1 DISCONNECTED Mar 22 23:48:07 kernel: [53548.390377] AR6000 connected event on freq 2437 with bssid 78:dd:12:cd:a2:f2 listenInterval=100, beaconInterval = 100, beaconIeLen = 22 assocReqLen=62 assocRespLen =76 Mar 22 23:48:07 kernel: [53548.405760] Network: Infrastructure Mar 22 23:48:07 root: wpa_action eth1 CONNECTED Mar 22 23:48:07 udhcpc[8399]: Performing a DHCP renew Mar 22 23:48:07 udhcpc[8399]: Sending renew... I was intending that this log should simply show it taking longer. But, oh dear, udhcp didn't complete on this occasion ! I wasn't expecting that. The red light stayed on for a long time ! But everything apparently was working fine... Five minutes later: Turns out to have failed a "gateway" check, because no valid gateway: Code: # cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth1 0001A8C000010 0 0 00FF0 0 0 But I don't know why. I guess -udhcp- was interrupted and never finished. I should have checked with -ip route- A quick kick to -udhcp- (USR1 signal) seems to restore matters. Gateway should be: Code: # cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth1 0001A8C000010 0 0 00FF0 0 0 eth1 FE01A8C000030 0 0 0 0 0 Basically, this is all very intricate. Time for bed. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > Here is this morning's workaround, which seems to keep jive happy. Here, > anyway. It adds statements to the ResetQuick() function to first take > the wireless network down, then re-associate, then to bring the network > up: ifconfig eth1 down ; wpa_cli reassoc ; ifconfig eth1, which you can > enter (all on one line!) from your ssh terminal and not be disconnected. > > On the community firmware, which uses -wpa_supplicant 2.9-, we have: Code: # ifconfig eth1 down ; wpa_cli reassoc ; ifconfig eth1 up Selected interface 'eth1' FAIL Essentially a NOP as regards reassociation, but will trigger -udhcp- to renew its lease, for reason mentioned before. Reason outlined here: -wpa_supplicant 'ifdown' inhibits ability to SCAN or REASSOCIATE- https://github.com/ralph-irving/squeezeos/commit/4bf00d10846a7f2fe629d1d549222523c203cf0b This would not impact 'stock' firmware. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > The TTL connection can be a nuisance, but you can program a cheap (<$10) > NodeMCU ESP32 board to be a telnet to TTL serial adapter. It requires 4 > wires: gnd, TxD, RxD, and power (5v or higher). One of the jumpers needs > a cap in series to avoid holding off the NodeMCU during its boot. I can > post details if interested. A link would be interesting. Sounds helpful if you don't have a USB TTL adaptor, I guess. Or perhaps I have missed the point. >From where do you derive the 5V power ? What would be the current draw ? Presumably it must power the ESP32 radio, so > 300ma ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote:
> I ask because the radio next to my desktop, connected via a TTL serial
> interface to a terminal, has kept playing (very softly) for days and
> days, and the wireless icon stays white. However, when I tried the
> QuickReset method using the terminal ("wpa_cli reassoc"), then looked at
> Settings | Advanced | Diagnostics | Network Health | Check Network
> returns with ip address "already in use", the Server Info section
> displays "Can't Ping" either mysqueezebox.com, and the LMS Library
> machine, yet ping succeeds from the serial terminal. And the music has
> not stopped, either from Pandora or the LMS library. There was also a
> "Wireless Info" display showing "Wireless network" "Not Connected", and
> so forth.
I don't have a Radio TTL'd at the moment, so I can't confirm this:
I would guess that the re-association generates a WPA "CONNECTED"
message that would cause the -wpa_cli- -wpa_action- script to do:
Code:
# Kick DHCP client to do a renewal
kill -usr1 `cat /var/run/udhcpc.$IFNAME.pid`
Plausibly, the result of this could have resulted, in an environment of
poor connectivity, a failure to do a proper renewal. The consequences of
that on "Check Network" could be various... I shall not speculate
without reading through the code.
Incidentally, the -wpa_action- script fails on a WPA "DISCONNECTED"
message because the busybox shell doesn't seem to like an -if- clause
with no command inside it. But it didn't have to do anything anyway, so
it shouldn't matter. Having said that, I wonder how -wpa_cli- would
respond to the failure...
I'll have a go the next time my Radio is TTL'd to see what really
happens.
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=109953
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
Londonist wrote: > Am I correct in thinking that wlanpoke is included in the current stable > f/w for SBR? No, it is not. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > Wireshark has an UInt64/Int64 Lua userdata type implementation that > could provide some inspiration: 'see here' > (https://github.com/wireshark/wireshark/blob/22e7ddb63789ff603641be116ee24834ca7631f9/epan/wslua/wslua_int64.c) Excellent find ! mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
frankd wrote: > I am not sure if this info helps: Thank you. I think it is helpful to know that. It will be interesting to see what might come of @POMdevs forays into the Wi-fi chipss driver. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > Oh, ok, there are lines like `start_jiffies = (Uint32) > luaL_optinteger(L, 2, 0);` in there, so changing the Lua jiffy timer > datatype to anything else but Lua_Integer definitely breaks this code > :-/ > *EDIT*: or can a Lua_Number or userdata type be converted here > on-the-fly to Lua_integer? I don't know. TBH, without engaging with the code and the context, I dont think I can usefully comment. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
mrw wrote: > A roll over would quite likely lead to failing/stuttering/mis-timed > audio. All usage of time stamps throughout Squeezeplay/jive (and > jive_alsa) would need identification and examination. Both in LUA script > and 'C' code. Including, incidentally, any time stamp interactions with LMS. I don't know how they work. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
gordonb3 wrote: > in that ALSA backend will reset to zero after 49 days 17 hours (-ish) A roll over would quite likely lead to failing/stuttering/mis-timed audio. All usage of time stamps throughout Squeezeplay/jive (and jive_alsa) would need identification and examination. Both in LUA script and 'C' code. 'C' code for audio is found in -squeezeplay/src/audio/decode-. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > Question: @mrw do you think that a -userdata- type in Lua can be > implemented along with a metatable properly overloading all required > operators in such a way, that -no code changes at all- would be required > on Lua side??? That was my first thought. I think it probably is possible, but the devil will be in the detail, and requires proper study. One would define a 'fallback' operation, I believe. One detail is that the overhead of doing it would be increased relative to simple number comparisons[1]. Would this adversely impact performance on Radio/Touch/Controller ? I simply do not know. Perhaps not, but there must be overhead incurred in despatching the 'fallback'. [1] And they will be integer comparisons, by virtue of the lua "integer patch". mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > > Sounds interesting. How is this done? Settings|Advanced|Logging, like any other Squeezeplay logging. Im assuming that you have become acquainted with it over the last few months. net.socket is the relevant log category. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
ralphy wrote: > If the updated wpa_supplicant software for the radio is causing too many > problems, then lets consider reverting to the version included with > stock. > > I can continue to use v2.9 regardless. I'll lodge an issue on your github site, which will (hopefully) lay out everything v2.9 related in one place, as I know it. I have been quietly working on smoothing things out as time permits. I'll aim to lodge over the week end. It would be "nice to know" why the stock version doesn't work with your AP. Easy to ask, not so easy to answer ! It would be a shame to revert back unnecessarily, but, let's wait and see. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
POMdev wrote: > This suggests that the failure might be caused not by problems from chip > RF AGC issues, or the driver, but by something in the wpa_ software. Put > another way, the wpa_ software might be adapted to better handle the > chip RF problems. Debug builds of this software might identify a problem > that can be easily solved. I shall watch this space. I shall add that later versions of the wpa_ software (i.e. as included in the Radio's community firmware release) bring their own problems/incompatibilities with the way SqueezePlay has been brought up to expect. Not insuperable, I think (I have yet to relay one issue to @ralphy), but may add complication. Or even grant additional assistance. Debug logging -net.socket- does dump wpa_cli status reports. Of course the logs grow rather long... POMdev wrote: > > Finally. a miracle has happened at my house. The number of dropouts has > dramatically declined, although there are still outages in the radios > most exposed to the neighbors, but many fewer. Perhaps the neighbors > have also suffered from their own new systems, and have disabled or > constrained them to reduce their own problems. For whatever reason, > everything is working much better here on its own. We like miracles. Do find some more ! mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > Ok guys, I heavily edited my 'post #79' > (https://forums.slimdevices.com/showthread.php?111650-Spontaneous-turning-on=1013358=1#post1013358), > trying to *concentrate all our findings* so far, because, as my own > previous posts showed, I already forgot about many things that were > discussed and identified as problems or possible solutions before. > > So it seems to urgently need a place summing up all these findings. > *I hope that you agree* to what I've written there. Please tell me if > you don't. As regards "extending the upper bits", I do recall that that potentially raises some very hairy issues within LUA, at least the version of LUA that the Radio runs. These stem from its automatic promotion of integers to floats in the LUA 'number' type. I am hazy on the detail, and perhaps it is easily managed. I also recall a degree of inconsistency (bugs) between the definition of the underlying data types on 32 and 64 bit platforms. It might all be better in a later version of LUA. And I'm hazy on that subject too, it's a while since I looked. But has implications if one is looking beyond just the Radio/Touch/Controller. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
The Radio checks its network status every 5 seconds, as part of a task
that updates the UI display.
It has occurred to me that, perhaps, the actions of @POMdev's script
might be incorporated into SqueezePlay itself, as part of this regular
update. I don't know whether that is feasible.
My set up does not suffer the problem, so I can't investigate.
My first step would be to look at some SqueezePlay log output to see if
anything can be seen from that. As a start, it might be instructive to
see what, if anything, is logged when the WiFi connection is lost.
A debug log output from -applet.SqueezeboxBaby- will show the following
each time it has run the network status check successfully:
Code:
Mar 11 13:00:16 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 1
Mar 11 13:00:16 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 3
Mar 11 13:00:16 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 5
Mar 11 13:00:16 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 8
Mar 11 13:00:16 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 10
Mar 11 13:00:16 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 12
Mar 11 13:00:17 squeezeplay: DEBUG applet.SqueezeboxBaby -
SqueezeboxBabyApplet.lua:784 _updateWireless: 12
The check carried out is a partial "Network health check". A debug log
output from -net.socket- will show very much more.
If an "afflicted" Radio logs something different, well, that might start
to open up an avenue of investigation. My goal in doing this would be to
see if any natural 'hooks', or additional tests, might be suggested.
For those interested in pursuing, the relevant SqueezePlay code ('stock'
firmware) is here:
https://github.com/Logitech/squeezeplay/blob/public/7.8/src/squeezeplay_baby/share/applets/SqueezeboxBaby/SqueezeboxBabyApplet.lua#L773
https://github.com/Logitech/squeezeplay/blob/public/7.8/src/squeezeplay_squeezeos/share/jive/net/Networking.lua#L1998
But perhaps these avenues have already been exhausted, I do not know.
This is quite a long thread.
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=109953
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > I would -not- recommend switching to an unsigned value type > `lua_Integer` > The point being, I think, that, at least in C, checking that a signed integer is negative is probably more readable, and possibly more efficient, than checking that an unsigned integer is >= half MAX UINT + 1, or whatever. > > That's a very valid thought that has been discussed before, but IMO, > fixing bugs should not be prevented by the fear of finding more bugs ;-) > > Anyway, as you said, a regular scheduled restart might definitely still > be a very good idea for Radios. > We should also keep in mind, that all Jive-based projects (like > PiCorePlayer) are affected by this bug. I shall put away my fear ! But not a priority at present. First step will be to make some reasonable looking proof of concept LUA script function(s) to deal with the LUA side of things. Second step will be to trawl all C and LUA code for occurrences. I don't think that would be too hard. One other thing that would need attention (from memory) is the ordering of the timer list. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
gordonb3 wrote: > > Yes, but that also requires compiling to the correct (ancient) support > libraries, although maybe you could get away with static linking on a > newer development platform. Of course once you do that you can also fix > jive_jiffies() to perform the roll-over itself at some `safe` time > within the 2^31 limit. > Quite easily done with @ralphy's build of Squeezeplay, I think. Well, I know it is on macOS. gordonb3 wrote: > > Another option for testing in this case would be to upgrade LUA to 5.4+ > and replace all instances of `lua_Number` (signed) to `lua_Integer` > (unsigned), which should either shift the restart to after 49 days or > possibly continue indefinitely. Here I think you get to the nub of it. What might be convenient is a LUA numeric type that wraps around in the same way as the C integer/unsigned type. Then, given that timer setting is limited to 24 days in the future, and that expired timers are checked within 24 days of expiry, the semantics of timer checking can work fine. (One checks the _difference_ between timer value and current time. Just modular arithmetic.) I think both conditions are probably already met in the existing code. The LUA numeric type could probably be effectively implemented by defining a suitable LUA function or two, but it looked messy to me. Alternatively perhaps a LUA user defined type might be made to look and act cleaner. But, then what ? As far as I am aware, no Radio has ever run longer than 24 days. What else might be revealed ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
gordonb3 wrote: > Right, that was somewhat disappointing. There's nothing weird with > networking to be seen and reviewing the log times it seems like the task > manager simply stops executing the `ui` task even though there is no > logging of this task having been removed. This appears to indicate that > the task manager thinks that the task is still running, which may > actually be true if it entered an endless loop or at least longer than > it takes for watchdog to kick in. > > On to the next restart... Possibly there is more to be seen if you capture Squeezeplays STDOUT and/or STDERR. Or possibly not. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
P Nelson wrote: > When the red symbol appears, the Repair Network will not fix the > connection and trying to select my secondary access point network will > not work. I have to reboot to clear the problem. Not exactly the order of events that you describe above, but might be contributory: https://forums.slimdevices.com/showthread.php?113479-Announce-Community-Firmware-for-Squeezebox-Radio-Touch-Controller-and-LMS-8=1011202=1#post1011202 mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
P Nelson wrote: > When the red symbol appears, the Repair Network will not fix the > connection and trying to select my secondary access point network will > not work. I have to reboot to clear the problem. > Is this particular element of the problem exclusive to the Radio running the Community firmware ? I ask, because: a) I believe that your Red Radio is (or was) running Community firmware, but perhaps your Black Radio is not. b) I believe that I have located a problem within the Community firmware that could cause it to fail to reconnect in this circumstance. The stock firmware does not have the problem I have identified, so I would not expect it suffer this additional annoying impediment. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
P Nelson wrote: > My suggestion of a plug-in was for the delivery of the patch, as opposed > to a plug-in that affects the operation of LMS; similar to the Community > Firmware update that is selected via plug-in. The other option would be > the patch process developed by you for the firmware bug on the Radios. > Perhaps a note saying, if you have a wifi connection problem on the > radio, install this patch. > > Hopefully, POMdev will take the initiative to post on the development > forum. Without POMdev's support, I would not be much help. > I've been following this thread for some time. My Radio has not suffered the symptoms described here, so it is difficult to confirm first hand what is effective, but I did take a look at @POMdev's script to see if it might be taken up in an Applet. @POMdev It was not clear to me which elements of the script are "action" and which are "logging". Are you able to produce a version, or a sketch, that confines itself to "action" - that might help me understand what's going on. Squeezeplay (on the Radio) already carries out a regular network check, my thought is that the "action" your script takes might be inserted into that existing process. In your comprehensive wi-fi monitoring report you remarked: > ... from the Squeezebox even when it reports reasonable SNR (signal to > noise ratio) values Pedant mode: did you mean SNR or did you mean signal > strength ? I have never seen a noise level other than -96dBm on my Radio, which I suspect is a white lie. But perhaps you know better how to extract the numbers. Did you investigate the possibility of increasing the Radio's RSSI/SNR thresholds ? I believe that 'wmiconfig' advertises this possibility, although I have no idea how. My thinking being that, perhaps, increasing the thresholds might persuade the Radio's wifi chip to ignore your neighbour's wi-fi transmission altogether. But, without knowing the source of the interference, this is little more than an idle thought. Did you ever determine the state/configuration of the Radio's wifi and networking configuration during the troublesome periods ? E.g.: Does it still have an association with the AP ? Has the AP just thrown it off due to successive errors ? Etc. All very difficult to determine. As regards the Community Firmware for the Radio: this is shipped with a more up to date version of 'wpa_supplicant'. It has become clear to me that there are some behavioural differences between the two versions of wpa_supplicant that could impact matters. There have been a few occasions when, in conditions of particularly low wi-fi signal strength, my Radio (with Community firmware) seems to be "taking down" its wi-fi network. The effect of that is that scanning will no longer work... I have yet to nail the cause. I don't have wi-fi problems, and setting up the right conditions is very hit and miss. Rotating the Radio by a mere 5 degrees on the same spot can have an enormous effect on wi-fi received signal strength. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] WiFi connection unstable/lost on three Radios
frankd wrote: > > - In my case the driver for the wifi equipment seems to crash - I can > only recover when rebooting the radio, no chance to change the network > once it crashed (without reboot) > - The new community firmware has the same issue > As far I as can see, the Repair network advanced setting on the Radio does not restart the wifi kit. I think that might be added in, but needs checking. Not a solution, but could be helpful. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=109953 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Bass amp problem
slartibartfast wrote: > I just experienced the Bass Amp issue immediately after a plugin update > and subsequent LMS restart. I shall continue the quest. But I fear it will take a very large lightbulb and painstaking review of kernel sources to actually nail it. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=104141 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Bass amp problem
slartibartfast wrote: > I just heard a track on Radio 2 that at one point made me think that the > bass amp issue had returned but it was just the way the track was > produced. Sigh of relief [emoji1787]. It was a track I had never heard > before (Overnight Sensation by the Raspberries) and all of a sudden all > the instrumentation disappeared leaving a high pitched vocal. I know the feeling. My heart has been sinking a little over the last couple of weeks, but then I realized that the relevant Radio is using the original firmware. I have never heard of the Raspberries. Should I have done ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=104141 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Swap the knobs on the Radio
L0O wrote:
> Yup! IR keys works as well - but notice it is 'hold' - so longer push.
> Wonder if possible to move those 0-9 numbers to 'press' section - what
> do you think?
>
> >
Code:
> >
> irActionMappings = {
> press = {
> ["add"] = "add",
> ["sleep"] = "sleep",
> ["2"] = "play_preset_2", <-- -here-
> },
>
>
> >
I've no idea, really. The regular remote supplied with the Radio doesn't
have a numeric keypad, I guess you are using the larger version like I
got with my "Classic" SB3.
So, maybe there is nothing to be lost by using those buttons in the
manner you intend. It may mean, though, that you can no longer use the
remote to enter in letters and digits. I don't know that that matters.
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=113652
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Swap the knobs on the Radio
L0O wrote: > > I did and... it and it works! > Good, glad to have helped. Do your new IR key action mappings work as well ? I've never fiddled with those. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113652 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Swap the knobs on the Radio
L0O wrote: > Wasn't easy to turn ssh on without working push button ;) but IR from > Classic helped me. ;) > Anyway - it is not work. Yet - I hope. I made reboot after saved .lua > and restart via Radio - nothing helped. > Maybe the way is good but I need to edit different file? But which? > > It looks like this atm: > > That looks fine to me. It is only the *default* settings that have been changed. Perhaps you already have already chosen some shortcuts in the past, so the defaults are not being used. I suggest that you take the menu option "Restore defaults", which is the last item on the list, and see if that helps. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113652 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Swap the knobs on the Radio
L0O wrote:
> Is there possibility to change this 'click' to another button? Or even
> better to swap functionality with small one (where push is working)?
> I found remapping possibilities but not for this push/'click', also
> didn't found change functions of small one with big. But maybe didn't
> search enough. :/
Presumably you found the 'Shortcuts' applet under the 'Beta Features'
menu of 'Settings|Advanced', and found nothing that would help. Nor did
I.
If you are willing to edit the relevant script on the Radio (by logging
in through SSH), you can, at least, change the default setting for the
"mute" key (Volume knob press) in a way that might help you.
The script lives in '/usr/share/jive/applets/Shortcuts'. The script is
called 'ShortcutsMeta.lua'.
You could make an edit to a part of the file, as indicated below. The
line highlighted in red is to be changed, just replace "mute" by "go",
as I have done.
You will still have the "mute" function, but now only by a long
press/hold of the volume button.
What you are doing here is changing the default setting for the "mute"
key, which pressing the volume knob gives you. In principal, this option
could be added to the menu, so that it could be selected through the
user interface. But working out how the main script actually works
defeats me right now.
Code:
EXTRACT FROM /USR/SHARE/JIVE/APPLETS/SHORTCUTS/SHORTCUTSMETA.LUA
keyActionMappings = {
press = {
[KEY_ALARM] = "go_alarms",
[KEY_ADD] = "add",
*[KEY_MUTE] = "go",*
[KEY_PRESET_1] = "play_preset_1",
[KEY_PRESET_2] = "play_preset_2",
[KEY_PRESET_3] = "play_preset_3",
[KEY_PRESET_4] = "play_preset_4",
[KEY_PRESET_5] = "play_preset_5",
[KEY_PRESET_6] = "play_preset_6",
},
hold = {
[KEY_GO] = "add",
[KEY_ALARM] = "go_alarms",
[KEY_ADD] = "add_end",
[KEY_HOME] = "go_home",
[KEY_MUTE] = "mute",
[KEY_PLAY] = "create_mix",
[KEY_PRESET_1] = "set_preset_1",
[KEY_PRESET_2] = "set_preset_2",
[KEY_PRESET_3] = "set_preset_3",
[KEY_PRESET_4] = "set_preset_4",
[KEY_PRESET_5] = "set_preset_5",
Be aware that you may need to restore factory settings if you should
"make a mistake".
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=113652
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > Turns out it's the non-zero keepalive value. You can add -K 0 to > dropbear in /etc/inetd.conf and remove -I 0. I've updated the dropbear > build configuration file to fix it for the next build. Good find. I'll try that out. I find the Dropbear documentation somewhat confusing on the point. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > Looks like this might be an issue with the v2019.78 as I found this in > the changelog for the 2020.79. > > Fix idle detection clashing with keepalives, thanks to jcmathews. Feels right. Dropbear certainly dropped a message in the log that it "deliberately" closed the connection. I've logged the Radio wi-fi scanning issue on SqueezeOS-SqueezePlay with some thoughts for you to consider. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] After Factory Reset No Wi-Fi Icon
sota wrote: > Thanks @mrw I just figured this out myself. But I notice after entering > it manually that it will only detect my SSID on a network scan, none of > the other local Wi-Fi networks are detected. Yes. It will always "detect" the SSID to which it is currently connected. :) mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113516 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] After Factory Reset No Wi-Fi Icon
On the Radio, take the "I don't see my network" option, then "Enter my network name". That will allow you to enter the SSID of your wireless network manually, and proceed with entering the password. I've been running the predecessor firmware for some months now, and I am embarrassed to say that I didn't notice this problem. It was there, for sure... :( The new firmware is easily fixable, one way or another. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113516 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > Yes only those 2 binaries. All other support libraries are statically > linked, so you should be good. > > There is also a 'kernel patch to fix the Wireless Event too big > messages' > (https://github.com/ralph-irving/squeezeos/commit/edf339db574b10c9375972029e4c8fd91942aff0) > but I still get the occasional one in /var/log/messages. I'll communicate my wifi findings through your Squeezeplay (or SqueezeOS-SqueezePlay ?) repo. An action will be needed. I have noticed the occasional "too big" message, so far during initial start up. I'll keep an eye. I also find that the new Dropbear insists on throwing me off after a period of idleness. Something to with an '-L' switch, or lack of, I think. Not a worry, but something to be aware of ! mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Community Build Radio Firmware
ralphy wrote: > Let's continue to discuss the Radio wifi issue here as the most recent > firmware still uses the logitech AR6002 kernel module. On the subject of the Radio wifi, I seem to getting consistently poor wi-fi scan results with the updated -wpa_supplicant- tool. I cannot be sure, because I very rarely need to establish a new wi-fi connection, but it doesn't seem right. Basically, I have had to enter the SSID manually (in Squeezeplay set up) to be able to establish a wifi connection. Wifi scanning just does not seem to be working. I'm pretty sure, without being absolutely positive, that this is "new firmware" related. I haven't really being paying attention to this over the past few months, it has only just come to my attention when installing the latest firmware. I'm guessing that an issue has been there all along. Any suggestions as to how to test ? My thought is to carry out some checks over a period of, say, a couple of days, and compare how the the newer and original wpa_supplicant binaries perform. Perhaps a periodic run of -wpa_cli scan_results- and see what networks are seen with new vs original. Would I be right in thinking that the only changes to wi-fi are in the -wpa_supplicant- and -wpa_cli binaries- ? If so, it is just a matter of replacing the two of these. Or are there other libraries, etc., that I would need to consider ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111663 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bayard1music wrote: > I've got two Squeezebox Radios, although only one use at any one time. > > I get occasional reboots whilst listening typically to a National Talk > radio station here in the UK. By reboot, the screen reverts to the > normal Logitech symbol and the radio starts from fresh. I've caught the > radio pausing and seeing the 'buffering' message on screen just prior to > a reboot. Just pulling the RJ45 cablel does not produce a reboot. > > bayard1music wrote: > Is there no clue as to what is causing these perhaps 'previous reboots' > in the messages about buffering ? Why might I see such messages on > screen ? The rebuffering and the rebooting are not connected, as far as I can see. As a direct result of your original post, we have identified a hitherto unknown defect in the Radio firmware, (and other Squeezeplay devices), that causes it to mishandle ICY metadata, leading to a reboot of the Radio. And I have offered a work around for that. The Radio (and other Squeezeplay devices) is also known to spontaneously reboot after about three weeks of being on, due to another issue in the firmware. Rebuffering will occur if, for whatever reason, the connection is lost/flaky between the Radio and the source of the stream. There could be many reasons for that. One reason is if the remote server simply hangs up on you, perhaps after some hours of service. I did notice this happening on the Classic FM stream, and I imagine the LBC stream would do the same. They are both provided by the same entity (Global Radio). So, if your rebuffering typically arises after some hours of continuous playback, I would be minded to suspect that the remote server has simply hung up on you. The Radio will, nevertheless, attempt a reconnection, and, in my experience, succeed. There are always other possibilities. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bayard1music wrote: > Quick update. > > Since switching to the LBC radio aac stream we've not experienced a > single reboot. I've had a couple of instances of a 'buffering' message > following by 'rebuffering failed' . There's typically silence during > this period. But at least no reboots so far. I'm glad you've got somewhere. I still think that your success from switching to the aac stream may be a bit of a fluke. If the reboot problem does recur, setting 'Proxied streaming' as outlined in my earlier post should deal with the point. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
ralphy wrote: > I can build a radio firmware with your patch for test proposes if you'd > prefer that to having to create an installer for the custom jive binary. > The patch could be kept private until you're statisfied the issue has > been fixed. Thanks. I won't be offering a custom binary as I think there is an "ordinary user" workaround available. Nevertheless I think that Squeezeplay does need correcting, and I've satisfied myself that I have an appropriate patch. A second set of eyes is always welcome. I've attached to this post: - The patch that I think needs to be in Squeezeplay: -0001-Bugfix-Incomplete-extraction-of-icy-metadata-causes-.patch.txt- - A debug/verification patch that traces proper operation: -0002-Bugfix-icy-metadata-for-testing-only-verify-operatio.patch.txt- - A 'pokyized' version of the above that I applied to the existing squeezeos source tree to build the test jive binary: -00xx-poky-icy-fix-debug-version.patch.txt- I have tested both on desktop Squeezeplay on macOS, and on a Radio with a custom jive binary. Typical log output from the debug/verification version is as follows: Code: Dec 8 00:22:22 squeezeplay: INFO audio.decode - streambuf_icy_filter:393 ICY: Caught defect Dec 8 00:22:22 squeezeplay: INFO audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0 Dec 8 00:22:22 squeezeplay: INFO audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Ludwig van Beethoven - Symphony No.6 in F major Opus 68 (2)';StreamUrl='';UTC='20201208T002157.047'; Dec 8 04:21:34 squeezeplay: INFO audio.decode - streambuf_icy_filter:393 ICY: Caught defect Dec 8 04:21:34 squeezeplay: INFO audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0 Dec 8 04:21:34 squeezeplay: INFO audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Franz Schubert, Schubert Ensemble - Piano Quintet in A major D.667 (4)';StreamUrl='';UTC='20201208T042107.547'; Dec 8 09:12:42 squeezeplay: INFO audio.decode - streambuf_icy_filter:393 ICY: Caught defect Dec 8 09:12:42 squeezeplay: INFO audio.decode - streambuf_icy_filter:397 ICY: Stream buf read ptr should be 0, it is 0 Dec 8 09:12:42 squeezeplay: INFO audio.decode - streambuf_icy_filter:401 ICY: Recovered from defect: icy metadata: StreamTitle='Gustav Holst - `In the bleak mid-winter.` This was generated on a Radio, playing out this continuous stream: -http://media-ice.musicradio.com/ClassicFMMP3-. I will add that changing -STREAMBUF_SIZE- in -streambuf.c- from 3MB to, say, 150k, makes for a much for effective test session, because the incidence rate is increased about 20-fold. Let me know if you would be interested in a receiving a PR. +---+ |Filename: 00xx-poky-icy-fix-debug-version.patch.txt| |Download: http://forums.slimdevices.com/attachment.php?attachmentid=32469| +---+ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
mrw wrote: > I'm not sure what the best approach for an ordinary user would be. bpa wrote: > IIRC When a stream is proxied, icy metatada is filtered by LMS - so that > maybe the workaround Well, I think that that is the workaround for the "ordinary user". Having reminded myself of where in the settings one sets streams to be proxied, I can confirm that LMS handles the icy metadata, and the Radio doesn't see it. So the defect in the firmware is not triggered. This is only effective when using a local LMS server, it will not influence matters if using -mysqueezebox.com-. +---+ |Filename: Screenshot 2020-12-08 at 14.38.07.jpg| |Download: http://forums.slimdevices.com/attachment.php?attachmentid=32466| +---+ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
slartibartfast wrote: > I am running the jive alsa that you modified to workaround the bass amp > issue. I thought that one did support aac but I could be wrong. AAC decoding is carried out in the 'jive' binary. The modified 'jive_alsa' binary that you are running is not involved, it only receives decoded PCM. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bayard1music wrote: > i) I'm not sure that there any images on the AAC station (not in front > of me now), but there are some on the MP3 stream I'm sure. As it happens, Global Radio does not provide images in their icy metadata offering. Any images that you may see probably stem from how the stream has been started - if from the 'Radio' menu on the Radio then probably TuneIn (the underlying driver of that menu) is providing them. bayard1music wrote: > > ii) Should a modified version of 'jive' become available , might I ask > how I would program that on my Squeezebox ? Or is this only something a > developer would be skilled enough to do. I obviously don't want to > 'brick' the radio beyond recovery due to my errors. Plus how might I > know that the code is available if its something I could attempt. (I'm > an electronics eng. but whilst having some Rasberry Pi/Arduino > experience today I couldn't call myself a programmer.) I inadvertently overstated the capabilities of the replacement 'jive' that I have built and am currently running as a test. There are some closed source/private elements that don't go in. Notably no native AAC or WMA decoding. That's not necessarily a show stopper, because LMS will step in and transcode any AAC or WMA stream. But WMA (Windows media) requires, I believe, an additional plugin to be installed. I don't recall ever needing it, frankly. Helpful overview of the LMS transcoding process: https://forums.slimdevices.com/showthread.php?113362-The-sound-quality-of-different-LMS-versions-differ-!=997751=1#post997751 That said, there is a project to keep the Radio's firmware updated, initiated by forum member @ralphy: Community Build Radio Firmware: https://forums.slimdevices.com/showthread.php?111663-Community-Build-Radio-Firmware=995413=1#post995413 That does have native AAC support (kudos to @ralphy), although some other limitations remain. I suspect that the absence of a native WMA decoder is the only item of any significance, and then only if you find yourself needing that format. I am intending to offer up this particular 'patch' for inclusion in a future release, if it passes muster. 'Bricking' is a distinctly relative term. Given that you have Rasberry Pi experience, I imagine that you are content with using the command line to copy, move, unzip, delete files, etc. Were you to choose to install the 'jive' that I am making, it would be a simple upload together with a sequence of simple copy/move steps to put it in place *correctly*, followed by a *careful* check that all is as it should be before restarting the Radio. At worse, a factory reset would remove the change and revert to the 'vanilla' system. It would also remove any saved settings, Wi-fi password, etc... A different approach may yet be found that requires no firmware tinkering. As usual, it will become a matter of figuring out the various pros/cons. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bayard1music wrote: > Just to say I've had the radio on days and experienced so far no reboots > using the AAC stream URL instead of the MP3. Not conclusive as probably > had on less this week due to other domestic issues. I have seen one > instance of 'Buffering' message on the screen with a gap in the sound > but not a reboot. > > I'd be grateful if somebody could summarise the findings of some of the > experiments/tests being run by some of the members responding to my > original thread as I'm not sure I understand their findings or > implications. I can summarize the results of my experimentation to date: I first suggested using the AAC stream in preference to the MP3 stream on the premise that may be something afoot with the Radio's MP3 decoder, or with the stream being sent. That no longer seems to be in point, so I think your apparent recent "success" is likely to have been a fluke. I have located a defect[1] in the firmware (Squeezeplay/Jive) concerning the handling of 'icy metadata' that may be embedded in the transmitted stream. Where present, embedded metadata can supply the currently playing track title, possibly an image, etc. Both LBC & ClassicFM streams provide 'icy metadata', as do many other online streams. The effect of the defect is that, periodically, and somewhat randomly, mishandling of the metadata results in a reboot. In the case of both the LBC MP3 and AAC streams, the opportunity for mishandling happens about once in every nine minutes[2]. The odds of that mishandling actually happening probably are about 1 in 100[3]. Cranking those numbers gives odds for the stream playing continuously for about four hours as 70%. The ClassicFM MP3 stream would be worse, because it has a higher bit rate - the opportunities for mishandling are more frequent, arising about once in every 3.5 minutes. I am in the process of preparing a patched version of 'jive', the firmware component that runs on the Radio, that corrects this defect. If successful, that would offer one avenue to fix the issue. (I.E. by manually installing a replacement version on the Radio). This may not suit most 'ordinary' users. I don't know what might be the best approach for them, further investigation is required. @bpa suggests that "proxied" streaming may be effective: https://forums.slimdevices.com/showthread.php?113309-Squeezebox-Radios-Reboots-with-talk-radio-in-the-UK-cable-connected-cable-connect=997277=1#post997277 I intend to post a patched version of 'jive' suitable for testing by anyone who wishes to try that route. Hopefully it will nail the point in the real world, and not just on my test-bed. I just need to get my 'build system' running. Also, it's worth remembering that, if a stream is left running for a long period, it is quite likely that the remote server will simply hang up. This would give rise to a certain amount of 'rebuffering', followed by an attempted reconnect and resumption of the stream. This would not cause the reboot. With hindsight, this is not much of a summary ! [1] I am 100% confident in this statement. I may yet suffer for this display of hubris. :) [2] Each stream reportedly provides a stream rate of 48 kilobits per second, and there's a buffer of size approximately 3.3M bytes. So the buffer 'rolls around' about every 9 minutes. [3] I reckon each fragment of metadata is about 80 bytes in size, and is delivered every 8,000 bytes. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
mrw wrote: > The problem with this particular failed assertion is, I suspect, this: > -streambuf_fast_read- will not return all available data if the relevant > icy data is wrapped around in the fifo buffer. A second read is required > in those circumstances. And the code only attempts one read. That's my > 'defect'. Well, I have now positively confirmed this hypothesis. I have a suitably 'patched' software (Squeezeplay on macOS) running, which makes that vital second read. The icy metadata is now read in full, and it looks just as would be expected. There is no sign of a hiccup. Next steps are to create a suitably patched version of 'jive' for the Radio, and test under live firing conditions. But it will work... mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
slartibartfast wrote: > I started playing Classic FM hours ago and the playing time in the now > playing screen is 41 minutes. So I thought it must have rebooted but the > Radio uptime is currently over 8 days. What happened there? Good question, I became aware of something similar, with similar thought. Could it be that at some point the remote server went away, the Radio attempted rebuffering, but unsuccessfully, and then resumed the stream from scratch ? Which is what it would do. I've never paid attention to the playing time. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
I used to play the Classic FM stream quite a lot in the past (2/3 years ago ?), but I never noticed this problem. I wonder what icy metadata was supplied then. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bpa wrote:
> I should think a patch for Touch should be possible, if the issues is
> something like "unexpected" icy parameters (i.e. not StreamTitle and
> StreamURL) and/or with unusual/confusing values.
The problem with this particular failed assertion is, I suspect, this:
-streambuf_fast_read- will not return all available data if the relevant
icy data is wrapped around in the fifo buffer. A second read is required
in those circumstances. And the code only attempts one read. That's my
'defect'.
Which is not to say that "unexpected" icy parameters will not break
things elsewhere, or that a duff icy metadata length byte wouldn't
equally create difficulty.
I noticed that the ClassicFM and LBC streams can produce some relatively
large icy metadata when a track changes, or in other circumstances:
Code:
Dec 1 03:28:53 squeezeplay: DEBUG audio.decode - streambuf_icy_filter:383
got icy metadata: StreamTitle='Leo Delibes - Sylvia - Valse
Lente';StreamUrl='';track_info='k4Smc3RhdHVzoUihQM5fxbhnpHR5cGWhVKJpZKY0MDI1MDSEpnN0YXR1c6FDoUDOX8W57KR0eXBloVSiaWSmNDU4NDc2hKZzdGF0dXOhQ6FAzl/FuuikdHlwZaFUomlkpjQwNDM1OA==';UTC='20201201T032839.656';
Nov 29 14:32:01 squeezeplay: DEBUG audio.decode - streambuf_icy_filter:383
got icy metadata:
StreamTitle='';StreamUrl='ADBREAK_LENGTH_22:0851508063={}';UTC='20201129T143125.424';
So the odds of either of these streams triggering this assertion failure
is somewhat greater than a stream that is more modest in its icy
metadata offering. And it's not helpful that an assert failure message
ends up discarded through STDERR, I would think better redirected to the
system logger, at least pro-tem.
bpa wrote:
>
> Again the Community Radio guys might be able to help out - especially as
> it seem this problem affects a few stations.
I'll share my findings with @ralphy. I'll have to fire up my SqueezeOS
build system and test more rigorously - it lives somewhere in Amazon.
bpa wrote:
> Might be a cause of some reboots which were blamed on other things.
Agree.
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=113309
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
mrw wrote: > Perhaps I'll switch from LBC to ClassicFM, at least that gives me > soothing music. Well, that did the trick. I was rewarded with: Code: jive: src/audio/streambuf.c:382: streambuf_icy_filter: Assertion `r == icy_len' failed. at about 3.30 in the morning. Source code: https://github.com/Logitech/squeezeplay/blob/public/7.7/src/squeezeplay/src/audio/streambuf.c#L382 I believe that there is a defect in the code here, but that must wait further examination and testing with a suitably modified -jive- binary. In the meantime, the only way to proceed, I think, is to turn off Icy metadata capturing altogether. That would require a tweak to LMS, or perhaps the lua source code on the Radio. I'm not sure what the best approach for an ordinary user would be. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Bass amp problem
mrw wrote: > Having investigated the issue further over the last few months, somewhat > sporadically, I have pursued an alternative approach to the problem. It > appears to be effective, and has, in some form, been running on my > Radios for the last five months or so without any obvious adverse > effects. > > This "solution" requires installation of a modified -jive_alsa- that > eliminates the possibility of ALSA subsystem under-runs. In my > experience a "Bass Amp problem" is invariably preceded by an ALSA > under-run, and I believe that some of these under-runs, for unknown > reasons, trigger the problem. So, eliminate the under-run and the > problem goes away. > > Update December 2020: I find that the problem may still occur, so elimination of ALSA under-runs does not entirely cure the issue. But it has helped. I've had one instance in the last 10 months, flagged in the system log as follows: Code: Dec 1 01:39:31 kernel: [63310.151320] ssi1_irq SISR 120 SIER 180100 fifo_errs=1 We've seen these before, although much less often that the ALSA under-runs that the modified -jive_alsa- eliminates. So, still not 100% effective. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=104141 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bpa wrote: > I think we should lob the issue to Ralphy and the community radio thread > and get their opinion - if only to be able to better instrument > "audio_thread_execute" line 849 and 1053 and paths to those lines. Thanks for Icy comments. The error messages that you describe are emitted by jive_alsa, in response to its discovery that its parent process, jive, is already dead. So nothing to be gained there, I think. I'm considering what trace debug lines might be added to jive itself to assist. drbob49 wrote: > Switched the radio to : > > http://media-ice.musicradio.com/ClassicFMMP3.m3u > > earlier this morning, logged in via ssh and recorded the following from > /var/log/messages. The radio crashes/rebooted at 13:55 but did not > resume the stream (which is what usually happens): > By contrast, the LBC stream that started at 04:56:41 yesterday continued unimpeded for about 30 hours, without any interruption, until I turned it off this morning. I restarted later this morning, during which time the stream has restarted itself twice due to audio under-run, but without causing any issue. (Attempts at rebuffering failed, I assume that the remote server would have "gone away"). So this is not going to be easy to track down. Perhaps I'll switch from LBC to ClassicFM, at least that gives me soothing music. mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radios Reboots, with talk radio in the UK, cable connected , cable connect
bpa wrote: > I didn't like the look of the icy metadata as some of it seems a bit non > standard. IIRC There are 4 fields returned Title, Image, UTC and ??. I > thought they might have triggered the problem. Interesting that they are > processed - however Radio will be passed them back to LMS. Looks like > metadata is not the issue. I will look further at the processing. I was asking myself: "What might happen if the stream 'restarts from scratch' for some reason when we're in the middle of processing the icy metadata ? Could we end up breaking the icy metadata filter ?". Would require examination of the code. And understanding what icy is supposed to look like. The stream that started on or around 04:56 when the Radio last rebooted continues undaunted. So that's about 14.5 hours now. Doesn't make failure easy to catch. And, if your log is growing with debug traces, then 'tailing' stops being effective when the log is rolled over... mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113309 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
