I happen to have lost the usability of the VNC-engines server on my custom Pi5, after the latest Oram update.
I wonder if I can force somehow the reset or reinstall of just the VNC component, of the 2024-09 Oram release.
I will raise a specific issue ticket.
Thanks 
Sorry, i can’t reproduce the issue. AFAIK, VNC is working OK in all 3 versions: stable, staging and vangelis (although you don’t say what version are you using).
You should try to reproduce the issue before raising an issue ticket. Also, you should include hardware and software version, steps to reproduce the issue, other context info, etc.
Regards,
Yes @jofemodo, you are right in reminding me to attach full contextual references to an issue report.
I indeed thought to let this to the issue button in webconf, as soon as I get my hands on the Pi5 custom Zynth.
There seems to be no problem of sort with VNC on my V 5.1, arguably running the same stable Oram release (latest), but I will check this details thoroughly before raising a ticket.
I would tend to rule out that the problem is hardware-related, since the VNC-Engines server worked normally on the custom Pi5 kit before the latest update.
I will get back here with more details. Thank you for the time being
Hi @jofemodo,
Now, apparently without any rational reason, the VNC-engines server is alive and kicking again on my custom Oram Pi 5.
The only possible culprit to point the finger at might be the LAN interface driver of my Mac, because the VNC-engines server re-started to load, once activated, after a session on the same external computer with my official V 5.1 upgraded kit.
Any relationships between the two facts?.. Hard to say.
Anyway, all is well what ends well!
All best regards 
From time to time, maybe due to sunspots 
, after executing an update via webconf it happens that VNC-UI (=vncserver0) doesn’t restart successfully, resulting in an errormassage by noVNC.
If you don’t want (or aren’t able) to restart the whole thing, there’s a workaround on the console:
The following command shows the current state:
systemctl status vncserver0.service
And to start it again this one’s sufficient:
systemctl start vncserver0.service
vncserver1 would be the relevant daemon if VNC-Engines should throw errors.
Have fun and keep on rocking!
Hi @Tithrion, that is extremely useful, for possible strange behaviours of a custom Zynth. It goes straight away in my workarounds secret list.
All best regards, and of course have fun!
Hello, I can confirm that VNC only works when a physical screen is applied.
Status without physical screen connected:
Status with screen connected:
I veryfied this behaviour a dozen times.
Bye.
Thorsten
Please use webconf’s “Report Issue” button to add a ticket to the issue tracker. We will take a look.
You must configure HDMI display.
Cannot confirm this.
Neither chosing “Generic HDMI/DSI” nor “Generic 4k HDMI” nor “Custom Device” solves the behaviour.
Have you used the “WaveShare 5 HDMI+USB” configuration? (The name in webconf, not the actual adapter.) I had that setup when RPi5 was running headless.
I can gladly confirm, that choosing “Waveshare 5 HDMI+USB” as well as “Waveshare 7 HDMI+USB” leads to positive VNC-support.
Thank you so much to all.
Peace on earth.
Thorsten
