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
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
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 ?
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
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
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
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
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
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
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
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
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:
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
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
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
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
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:
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
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.
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:
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
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:
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
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?
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
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
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:
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.
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
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
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 l
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
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
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
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
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:
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 !
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 :) :
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
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
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:
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:
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
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... :)
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
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
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
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
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.
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
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
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,
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
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
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:
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 !
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:
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
>
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
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
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
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.
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
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
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
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
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
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
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
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:
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
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
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
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.
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
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"] =
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:
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?
>
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
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
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
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
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
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)
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,
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
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
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
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 remin
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
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
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
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 attem
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
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:
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:
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'
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
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
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.
1 - 100 of 253 matches
Mail list logo
