Another Sunny Saturday… time for a release!
This is a pretty small release with some improvements on the Spotify functionality (XL) and some other minor improvements (wifi in particular) all over the place.
The biggest ‘not-visible-but-cool-anyhow’ item is the switch to 64-bit on Pi 4 hardware. Not visible, because you shouldn’t notice it at all (expect maybe that the user interface ‘feels’ a little bit snappier).
Anyways, I hope you’re all enjoying the summer. Here’s the changelog for completeness:
- NEW: switch to 64-bit environment on Pi 4 family
- NEW: show update available notification on devices tab
- NEW: [XL] librespot (spotify): provide normalisation pregain setting
- IMPROV: [XL] librespot (spotify): slightly rearrange the logic wrt “none”/“fixed” volume setting
- IMPROV: update WiFi controller
- IMPROV: better region code detection (needed for WiFi regulatory domain configuration)
- IMPROV: bump Linux kernel
I have not reverted to previous version to compare, but boot time seems a little shorter with 64 bits evolution. As I turn on/off my RPI4 at each listen session , this is a welcome evolution.
I assume we need to switch from Beta to Stable first. When I did this, my RPi4 went through some gyrations, then turned off and did not come back on. I finally unplugged the power and plugged it back in and all is good now. Just waiting for the update.
EDIT: Updated. All is good.
At least 2 of my setups are stuck in reboot loops with displays since the update. No chance to get them into a state to send feedback. The last thing I see before it reboots but in device list it’s obviously been updated to 513
The other 5 are sitting at install update buttons showing. The 2nd unit stuck with showing build 514 but in the devices when it’s detected restarting…here shows ping the 513 version
And now after 7 hours of being stuck rebooting loop it’s suddenly up
cfbdbf4781a665fc So here is a feedback for what it’s worth.
As your logs show, NTP syncing is failing. Hence it fallbacks to HTTPS.
And then something strange occurs… it jumps to 28th of may.
Next is that you have set your daily reboot…
Next ‘real time sync’ jumps in, and brings your unit to august. Resulting in a reboot because of your daily reboot…
It is a mystery to me why it jumps to May, while the servers clearly report August.
I will investigate this.
Hi @wizardofoz ,
Found the issue. The ‘sync-over-https’ tool has a bug. Good news is that it is already resolved, not so good news is that the bug has made it into this release.
I’ll release a patch release shortly to fix this.
I don’t understand why NTp doesn’t work for Ropieee when every other device in my network uses ntp without issues.
What ntp server entries are you using? Google has several and there many other publicly available options.
Let’s hope I don’t have to reflash a lot of internally housed rpi sd cards
Who said that NTP is not working for you?
It is, except the initial setup. That’s the reason why it (eventually) comes up.
Via ntp it’s failing but https it’s perhaps working
That’s what I said.
Initially it needs to ‘jump’ to the current time and for that it uses NTP as well.
And for some reason it fails, hence falls back to HTTPS.
And unfortunately there is a bug in the HTTPS tool.
But besides that, it should not even fallback to HTTPS.
That’s what I’m investigating now: on your units it should not need HTTPS for syncing.
Updated three devives (two Bridges, one with added DAC PRO+ HAT) - updated and running w/o any issues!
Chapeau + Thanks a lot!
Hi. I have 2 RopieeeXL installations: one is fine but the other plays for 1-2 minutes then drops off the network (reboots?) then reappears. This is a continuous cycle.
Both are connected via my Unifi Mesh 6 wi-fi and the problematic one is running RoPieeeXL 2022.08.1 (0524). Log reference is c80a567a9bd782b5
RAAT shows dropouts. No reboot involved.
This is usually a network issue.
OK Thanks - I investigate network.
I think I have identified the reason. My wi-fi is a mesh system with 2 access points.
When initially setting up the 2 Pi end-points, the wi-fi scan and relevant password entry was done close to access point 1.
The network name and password is the same for both mesh access points.
Pi #1 is located near access point #1 and has worked flawlessly from the time of the OS upgrade.
Pi #2 is located near access point #2.
I had assumed that when powered-up Pi #2 would connect to the access point with the strongest signal (#2) - it didn’t - it only wanted to connect to the more distant access point.
Reinstalled the OS in Pi #2 and moved it adjacent to access point #2 for the wi-fi set-up.
All good so far…