Problem with RooScreen - rooExtend not appearing as available display

I don’t know.
Works for most customers but issues seem to have ROCK users only. As read above a popper update seems to solve this :thinking:

Best DrCWO

Hello,

I have run through the proper update path from scratch and am still stuck with the same problem. The Roon-web-controller works fine though on the latest version.

Please let me know if there is anything I can do to debug.

Thanks!

:sleepy_face:

Hi Paul,
have youe ever tried to reboot your Roon Core and if it is up and running again power on the Pi with rooExtend?

Please try this again.

Best DrCWO

Hi @DrCWO last night I sent the logs to you, please let me know if I can do something else. I think this the issue “Feb 17 19:17:51 rooExtend rooExtendUpdater[113751]: ***** Error with: apt-get -y install rooextend=3.5.3, Error: Command failed: apt-get y install rooextend=3.5.3 Feb 17 19:17:51 rooExtend rooExtendUpdater[113751]: E: dpkg was interrupted, you must manually run ‘dpkg --configure a’ to correct the problem.”

Hi again @DrCWO do you have any update on this ? Currently I have to SDs with Rooextend installed, one stuck in 3.4.4 and the other stuck in 3.4.3 both with the same error. ( the one in my previous post). Thanks for your support

Hi Cesar,
sorry for the delay but I was out of office for some days.

This error means you have interrupted the update process probably by powering off during the update.

Sorry, but this cannot be fixed. You have to do a fresh install starting with the ARMv8 image and the hotfix.

Best DrCWO

Ok thanks, you mean starting at 3.4 and progressively upgrade to 3.5.3 ? If that’s the case can I do it in less steps? I mean.can I do it in the same day and not waiting overnight? Thanks again. (…but i don’t think I powered it off before the process ends)

  • Please make sure If v3.4.0 is up and running
  • Find out the IP-Number of your rooExtend Box at the end of the settings dialog of the License Manager
  • Open the Service Page with http://[IP-Number you found] and nstall the hotfix.
  • Close the browser and again open the Sevice Page
  • Find the button “Look for software updates” and confirm
  • Now wait this can take a long time.

After that you should be at v3.5.x

Good luck
DrCWO

Hi @DrCWO , i´m finally back on 3.53. But I’m also back to the original problem, no available display (see the screenshots) . If this give you a clue, yesterday I could see the display available but last night rooextend rebooted unexpectly and after that reboot the display is no longer available, I can send you the logs if you need them. Thanks again for your support.

So it works and after next boot no more???

No idea at the moment…

Best DrCWO

1 Like

My guess is that is an issue related to a WiFi network ipoor performance because of the Pi3 limitations . I’m considering migrating this to a Pi5. Is the current rooExtend DIY image compatible with Raspberry Pi 5?

Thanks again

Hi Cesar,
According to me, RPI5 has never been an option for rooExtend. It is RPI3 or RPI4.
rooExtend is not too CPU-power consuming, so RPI4 or even RPI3 should be sufficient. But if you are not confident about your RPI3, just step-up to RPI4.
Be sure that the power-supply of the RPI is powerful enough.
Kind regards, Frank.

1 Like

Thanks! I think it has to be more with the WiFi throughput than CPU speed.

Pi4 is supported Pi5 not yet.
If you use WiFi I don’t wander about the issues you got :innocent:
Roon uses UDP and therefore lost packages that can happen with WiFi kill communication.
Please use wired Ethernet and your Pi3 will work fine.

Best DrCWO

Hi DrCWO,

A pure technical remark, I know that for RAAT, Roon is using TCP already since a long time. In the beginning of Roon, they started with UDP, but now it is TCP (which should be more stable).
Perhaps for ARC, they are using UDP. So I am a little bit confused with your remark that Roon is using UDP. Can you explain where I am wrong?
Kind regards, Frank.

Hi @Frank_M,
I know UDP is used for the discovery of the playback devices. If RAAT uses UDP for data transport I don’t know.

What I know is that using the Roon API via WiFi you I often often saw that the Roon Core terminates the connection. This nearly never happens with wired Ethernet. So my guess is that UDP is used here as via TCP packet loss should be avoided.

Also Roon says that they don’t recommend using WiFi for what reason ever.

Best DrCWO

I have done this multiple times. Is there anything else I can try?

@DrCWO my RooExtend-RPi4B is connected bz Ethernet. As you remember, rooScreen was running. Today I recognised, that it doesn’t work anymore (didn’t check the last days). The clock is showing up, but no more album covers.

In Roon/Extensions/licence manager I can see that the TV-Screen is recognised, but it is not available in Roon/Web-Display and also not when pushing the loudspeaker-button in Roon.

I tried rebooting Chrome, rebooting RooExtend and even rebooting my Roon Rock (NUC 8th generation), nothing helped.

The If I can send you any log files or if you have any other questions, don’t hesitate to contact me!

But it is not a big issue for me, it won’t sound better with rooScreen working. :wink: It’s just a feature.

Hi @DrCWO,

I wanted to give you a comprehensive update on my ongoing rooScreen issue, including all the steps I’ve taken since my last post.

Hardware change: migrated from Raspberry Pi 3 to Raspberry Pi 4

Following the discussion about potential WiFi limitations with the Pi 3, I decided to migrate to a Raspberry Pi 4 Model B Rev 1.5. The Pi 4 has WiFi AC (802.11ac), which provides much better throughput and stability compared to the Pi 3’s WiFi.

Fresh installation on Pi 4

I performed a completely clean installation on the new Pi 4:

  • Flashed the ARMv8 rooExtend image to a new SD card
  • Applied the hotfix as instructed
  • Let it update to v3.5.3 without interruptions
  • All extensions are running correctly: rooDial 1.5.7, rooPlay 1.1.0, rooWatch 1.1.1, rooControl 1.1.0, rooScreen 1.0.0

Current system state:

  • rooExtend release: v3.5.3
  • Device: Raspberry Pi 4 Model B Rev 1.5
  • IP number: 192.168.1.128
  • Memory usage: 548Mb
  • USB audio interface: Behringer UFO202, Multi-Channel
  • TV Screen: DWE-HDM
  • Internet connected: Yes
  • Temperature: 60.3°C
  • Connection: Wired Ethernet (also tested on WiFi AC)

Roon Core:

  • ROCK (RoonOS 2.1 build 271 production) on GMKtec G10 Mini PC
  • Roon Server version 2.59 (build 1625) earlyaccess
  • IP: 192.168.1.155
  • Port forwarding configured for ARC (port 55002 TCP/UDP)

What happens:

  1. After the fresh install, rooScreen initially worked — the display appeared in Roon and everything was fine.
  2. Then ROCK (Roon Core) rebooted overnight (i do it once per week).
  3. After that reboot, the display disappeared from Roon — “No hay pantallas disponibles” (No displays available).
  4. I restarted the Pi 4 (with ROCK already running) — the display did NOT come back.
  5. The rooExtend service page (http://192.168.1.128) is accessible and all extensions show as running.
  6. However, trying to access the rooExtend web interface initially returned ERR_CONNECTION_REFUSED from Chromium, though the service page itself works.

Ethernet test: in my opinion, WiFi is NOT the cause

Following your suggestion about WiFi and UDP packet loss, I connected the Pi 4 via wired Ethernet directly to the router. The issue persists exactly the same way — Roon still does not show the Chromium display. In my opinion, this rules out WiFi as the cause of the problem.

What the logs show:

The rooExtend log confirms that on the Pi side everything starts correctly:

  • rooScreen starts and gets paired with CORE
  • Chromium launches successfully (after a few checks, goes from “Check chromium running: false” to “true”)
  • The WebSocket client connects
  • The screen resources (HTML, CSS, JS) are served correctly

So the rooExtend/rooScreen side is working as expected. The problem is that Roon (ROCK) does not register the Chromium browser as an available display, despite rooScreen being paired and Chromium running.

Summary of all troubleshooting steps taken:

  • :white_check_mark: Migrated from Raspberry Pi 3 to Raspberry Pi 4 (WiFi AC)
  • :white_check_mark: Connected Pi 4 via wired Ethernet — same issue, in my opinion rules out WiFi
  • :white_check_mark: Complete fresh install of rooExtend v3.5.3 (ARMv8 image + hotfix)
  • :white_check_mark: Restarted router
  • :white_check_mark: Restarted rooExtend / Pi multiple times
  • :white_check_mark: Restarted ROCK and then the Pi (in correct order)
  • :white_check_mark: Verified rooExtend service page is accessible
  • :white_check_mark: Verified all extensions are paired with CORE in logs
  • :white_check_mark: Verified Chromium launches and WebSocket connects in logs
  • :white_check_mark: Tried both LAN and WiFi connections (on the Pi 3 and Pi 4)
  • :white_check_mark: Confirmed displays from other devices (PCs, smart TVs) work fine in Roon
  • :white_check_mark: Previously confirmed that rooScreen works on v3.4.0 (as Aaron_Lang also reported)

This confirms the pattern you identified: the issue seems specific to ROCK cores and the v3.5.x branch. The rooExtend side is doing its job — the problem appears to be on the Roon/ROCK side not recognizing the Chromium display. In my opinion, it is definitely not a network issue.

I can provide the full log file if needed. Please let me know if there’s anything else I can test.

Best regards,
César