Hi Harry 4 devices updated and all good so far.
Back in December I had a couple of devices that did not reboot properly after updates and needed the power cable pulled out, but the recent 3 or 4 updates have been perfect across all devices.
Hi Harry 4 devices updated and all good so far.
Back in December I had a couple of devices that did not reboot properly after updates and needed the power cable pulled out, but the recent 3 or 4 updates have been perfect across all devices.
All good 5 updates one rpi4 and the rest displays all 3b’s
Hi Harry-
Thanks so much!
I’ve downloaded it. On reboot it goes into the WiFi selector behavior, even though it is wired (I didn’t attach to the Ropieee access point, I just went to the wired IP address). I don’t mind using WiFi per se, but I’d just as soon use it wired and keep WiFi off. I’m guessing this is an unanticipated consequence of the ipv6 work around. Not sure if it matters, I’ll keep you updated on how it goes from here!
Edit: actually the Roon endpoint is now visible in Roon/Settings/Audio on the WiFi address (192.168.1.134) and not on the wired IP address (192.168.0.202) even though I can navigate to the Ropieee admin page on both of those addresses. I’m not going to change anything else pending your ok.
In case you need it, feedback is here: f26b2e4ee2adfcb4
John
new beta (2059), still all good here
same details as always (pi4, wifi, roon, airplay2, plexamp)
All units updated with no issues here.
New Beta 2059, works well wih NAA, thanks Harry
We’ll see next stable update. BTW a last element, which may give a hint : back to the stable channel, and in 2024.12 (1994), I have an update notification for… 2024.12 (1994). Feedback id : 9328e56c0fda97bb
That is expected behavior: if you change the update channel the unit will always download the latest version. Even if you’re already running it.
My advice: if you switch to beta, stay on beta. That means accepting that things are potentially broken.
Hi John,
The good news is that the ‘wait-for-we-are-online’ is working now properly.
The weird thing is (and that’s why the WiFi AP kicked in): the delay before the unit gets an ipv4 address from the router is rather extreme: we’re talking about 1.35 after the wifi interface get’s an address.
As RoPieee’s timeout for a connection is less than the 1.35 (exactly 1 minute) the issue appears.
Question is here what to do: I’m pretty sure if I set the timeout to 2 minutes everything works as expected, also on wired.
Let me sit on this for a while. I need to do some research on best practices here. The thing is that the default timeout is 2 minutes (I changed to 1), so you could argue that the 1.35 on your unit is not that extraordinary…
To be continued.
I try beta 2025.01.0 [2059]
My Unit:
Hardware: Raspberry Pi 4 Model B Rev. 1.5
RAM: 4 GB
ROM: 32GB microSD Samsung
Network: WiFi
Audio: USB DAC → Yamaha R-N1000
Display: No
Remote: OSMC
Beta version works perfect!
Thanks Harry. Totally get that this is nonstandard. I would hazard a guess that because my Unifi router prefers ipv6 it’s waiting to see if it can force the issue. Networking is not my forte. Having ipv6 has been overall worthwhile for me, but it’s had a few hiccoughs. If you tell me to try reducing lease time or something I’m happy to do that, but I’d prefer not to get rid of IPv6 since I’ve otherwise got it working well. Anyhow, appreciate it - last thing you should be worrying about is non standard networking setups.
I’m running a Unifi setup myself as well. Including ipv6.
So no worries, I really think that your setup should work.
I’ll do some digging and if I can’t find any valid reason not to, I’m going to increase the time out. That should solve your issue without any negative side effects…
Five RPIs updated. All went again fine.
Thank you Harry.
An alternative is that I could use a static IP address for the Ropieee instead of DHCP and turn off wireless. Just because I have an IP reserved for the RPi in Unifi doesn’t mean I have to use DHCP, I can just use the same address statically. That said I don’t like having devices use static addresses in general (other than my router I don’t thing I have anything on my network using static), but if this is easier for you I’m totally fine with it.
Nope. Made up my mind. I’m going to increase the time out. AFAICS there are no negative side effects of this change, and it fixes your issue. And I don’t see any reason why you should be the only one: it seems perfectly legit that a network dhcp setup can take quite some time.
Well thank you @spockfish. I actually have what is likely a related issue setting up a different machine…
I have an old RPi 3 A, and I decided to at the same time try to install on it. It gets to … waiting for internet connection… then a minute later … CONNECTION FAILURE… then it gets to … Setting up WiFi AP … then a few seconds later it reboots and goes through the same loop again and again. I can’t see the WiFi network appear during the time that it’s booting, so I can’t see the admin page and try to get feedback. Have tried refreshing multiple times, I’m using a 5V power supply. so am hoping it’s not that activating the AP causes voltage to drop or something.
I have a USB/Ethernet dongle, which I tried to attach, but it is timing out on getting a connection (likely for same exact DHCP slowness reason). So I’ll wait until you get the timeout extension to the stable branch and give it another try - with the ethernet dongle - unless there’s something obvious that occurs to you about the WiFi reboot doom loop.
Of course, many thanks as always.
No, it’s activating the AP because it doesn’t get an internet connection.
So when we increase the timeout, this also will not happen.
Right now the planning is to release this weekend-ish, but I’ll prepare a final beta image tonight, so this issue is solved for you before the weekend starts.
I get why it’s activating the AP, and agree that getting it an IP over the ethernet dongle could avoid it getting that far. My question (which should be irrelevant) is why the RPi3A is rebooting immediately after activating the AP. Let’s not worry about that for now!
Thanks,
John
I’ve just pushed out another beta build. It contains only 1 change: it increases the network connection timeout a bit. With that change the issues from @Johnny_Ooooops should be addressed.
Let me know how things are working out for you @Johnny_Ooooops
Thanks
Fabulous, many thanks. The Pi2AES got a wired IP, woke up and did its thing just like you & I were hoping it would! Feedback is here, but I doubt it will tell you anything you don’t know: 6c7e235e28f2ba48
Now I’ll wait for this change to hit production so I can try to flash the Pi3A and get a wired IP via the dongle, since the act of creating the wireless AP seems to make it reboot. Not worth chasing down why.
John