Stable release 386 (2019/12/14)

Hi Simon,

Yeah I’m familair with this article. Kernel is not the problem here (RoPieee runs a very recent kernel).
The problem is that something extra needs to be done for the firmware part.

I’ll look into this (i’ve got Pi 4’s myself) how we can do this.

1 Like

Great, thanks Harry, I’m happy to offer myself as a beta tester if that helps. I have only 1 Pi 4 though, the rest are Pi 3s.



This only applies to the Pi 4.
I’ve added this to the TODO list so this update can be triggered from RoPieee’s webpage in the future.

Thanks for reminding me!

The boot process used to be about one minute while using LAN.
The boot takes about four minutes when using wifi connections. (release 386)

I tried on other RPi4 with wifi connection, the boot process takes ten minutes.

Yes - we’ve been discussing this here Long reboot time in wi-fi compared the Ethernet new release should fix it :blush:

I don’t understand : on configuration webpage i have

linux-raspberrypi-dsd 4.19.80-3

And with ssh : uname -a

Linux ropieee 4.14.114-3-SPCKFSH #1 SMP PREEMPT Fri Dec 13 18:12:58 CET 2019 armv7l GNU/Linux

The package version is fake as we switched back to the 4.14 kernel on the pi 3

Stable 396 still have issue on wifi only. The boot up time of wifi only still takes a long long time. Its too long to wait, I plug a network on it and boots right away.

Thats weird.

Can you boot on WiFi and send me feedback?

Hi Harry,

Thanks for your response. The wifi boots up forever, even after 20 mins, RPi4 is still waiting. Now I gave up the wifi and connect via lan cable only. I remember a couple of release ago, the wifi connection was working fine. Any big changes on the code related to the wifi?

No. Have you tried reconfiguring it? So disable it in the web interface, enable it again etc.?

And can you still send me feedback?

Log b647190cd25f1db4

Reboot with wifi disabled, network cable connected, but still need about 7 minutes to boot up.
Now I re-flash the SD and reinstall the RPi4 again, and try.

Things back to normal with a re-installation from scratch.

More of an XL related question. The volume for Spotify playback appears to be dependent on the volume for ROON playback. Does ROON set the system volume and Spotify an application volume on top of that (meaning that ROON determines the max volume)?

It’s a matter of ‘who comes first’. If you play Roon first then Roon controls the volume.

The problem here is that there is no ‘switch moment’. If that would be the case we could reset the volume, but right now that’s not possible.

Good to hear. Was feeling sick yesterday so didn’t had the opportunity to look at it more.

Not sure that is what I observe: even if the unit has been power cycled, it appears that the last ROON volume determines the max for Spotify. Should this not be the case?

Yes. Sorry to mention that: the last volume is also stored. So even after a reboot/power cycle it uses the last known volume.

Interesting thing is I have to disconnect the USB to my DAC input when the RPi4 reboot, otherwise the boot up is hang. It seems the boot up process looking at the USB input for something. Once I disconnected the USB from the DAC, things are normal for both LAN or Wifi connections.

BTW, the USB device of the DAC is an Amanero chipset.