Fairly ‘calm’ release with some fixes and improvements all over the place.
Most noteworthy is probably the support for the Raspberry Pi Compute Module 4 IO Board, which in turn makes RoPieee prepared for upcoming devices that make use of the CM4 module.
Obviously you can find the changelog on the webpage (https://ropieee.org), but here it is anyhow:
NEW: support for the Raspberry Pi Compute Module 4 IO Board
IMPROV: show link to the RoPieee’s Beginner Guide on the welcome page
IMPROV: show alert to think about the Roon extension when configuring a remote
IMPROV: show progress while updating
IMPROV: behave better on mobile screen dimensions
IMPROV: move ‘timezone’ setting from display tab to advanced tab
Why limited on board LAN interface to 100M?
My Ropieee connected with some others in a sub-switch (Netgear GS108Tv2)), due to this limitation, whole chain had be indicated as 100M in upper switch.
Will you think this is the cause or any specific reason that you config it on 100M?
config.txt:
dtparam=eth_max_speed=100
update:
Mounted the tf card to a ubuntu system, changed config.txt in boot partition and ntp.conf in else partition also. Upper switch speed LED indicated as green (1000M) now so far so good.
verified change implemented.
[root@Roon-bridge ~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: gs
Wake-on: d
SecureOn password: 00:00:00:00:00:00
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
I would still like to this on the main Roon tab at least if not in all the footers of all tabs as its a handy reference for anyone needing a recap on what is what - especially as Nathan updates along with pertinent changes to the releases as they come out.
Since the update I have the issue that my Roon remotes don’t find both of my RPi4s in the morning. Reboots fix it for the day. Is it possible there was some power management setting activated during the update? The temperature might be slightly higher (144F idle) than before, but not sure. So maybe also a networking issue.
Thanks
This is after reboot with everything working:
9f6afe2e108b05a6
This now before rebooting, not showing up in remote:
1fe9dfe1f44e67e3
I am having a similar situation as @idyllic_pushpin. I recently installed a touchscreen and upgraded to XL 3.107 - reflashed the sd card and reinstalled Ropieee. It seems that the pi loses connection to the Roon core and the dac after some period of time (I notice it when I try to play music in the morning). Airplay works fine and the pi is visible in Roon as an airplay endpoint, but it is not available as a Roon bridge endpoint. Turning the dac on and off has no effect. I end up rebooting the Pi and it seems to establish the connection again. I previously used a FLIRC case with no display and the previous releases with no issues.
Gerry
Reboots of Pi’s. I did reboot the core. This morning one of the two worked, so it is probably a networking issue on my side. Thanks for checking the logs!
I’ve been experiencing an issue after upgrading to 3.107, where Roon no longer recognises my USB DAC (a RME ADI-2 Pro FS R BE) as an output after I turn it off (usually in the evening) and then on again (the next morning).
I can only confirm that the issue isn’t present in 3.066 (the latest stable version I could find a SD image for), but I don’t recall it happening before 3.107.
I’ve sent you feedback (dfee5ede592aa517) straight after power cycling the DAC (when Roon fails to see the endpoint).
Please let me know if you need any further information.
Usb suspend feature doesn’t work anymore correctly since the latest stabel update 3.107, at least not with my Topping D50S: it goes to sleep and dissapears from Roon. Disabling Usb suspend in Ropieee solves this minor problem. (Airplay continues to work.)
Can you check for me, the next time this happens, if the device comes back after rebooting your Roon core?
I’m getting the idea that you are bitten by the issue that is still not 100% resolved that Roon core does not detect all available endpoints correctly.
On your RoPieee unit everything is peachy and shiny and your DAC is properly identified.
I’m not convinced this is a network issue on your end: I’m still suspecting that there are issues with Roon core not always detecting devices that come up correctly…
I see a clearer pattern now. Whenever I turn off the DAC, the temperature goes up, a mono-sgen process runs at 99% Pi CPU, and then it won’t show up again in Roon when I turn on the DAC. Reproducible on both of my DACs. Rebooting Core doesn’t bring it up, only rebooting the Pis.
That’s a Roon thing (mono-sgen is being used by RoonBridge).
I think it’s time to call in the Roon troops, but I’ll also (trying to) reproduce this by just pulling the plug (which would essentially mean the same thing).
I’m afraid rebooting the core (i.e. doing a systemctl restart roonserver.service) didn’t help. Roon only redetects the endpoint after rebooting RoPieee. FWIW, I sent you feedback again (618fddc699c5d41f) after I had rebooted the core.
