Same here.
In the recent update, the file /etc/X11/xorg.conf.d/99-vc4.conf disappeared. The result of this action is the boot messages showing, a login prompt and a black screen blip repeating every second.
Regenerating the file via SSH instantly started the Zynthian UI.
The file has to contain:
Section "OutputClass"
Identifier "vc4"
MatchDriver "vc4"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection
to be functional for HDMI display. The name of the file can also be 99-v3d.conf to render a functional result. The contents of the file created by the update does not work for HDMI.
1 Like
What display option have you selected in webconf?
Have you tried to choose the “Generic HDMI Display”?
Regards
Chosing “Custom Device” (display) allows the Zynthian UI to come up if it’s stuck at the text “zythnian login:” prompt. Generic HDMI Display does not seem to get you to the UI. The problem with Custom Device is the the text is rather small.
I had the same problem yesterday after reflashing my USB (custom Pi5) and this fixed it.
I thought I could rely on the hotspot starting up at first boot but it didn’t do anything, even after I ran the hotspot script file. After plugging via ethernet I was able to access webconf and plug in all my settings that I had noted down before overwriting the old installation.
So far my screen Waveshare DSI 7" C won’t light up using the same settings that worked before Trixie. It does register touch input though as I can see things being affected when logged in via VNC. I’m shifting into a new case so I’ll get a chance to replace cables with some fresh ones.
Edit: I should add that the encoder drop out that occurred on my previous install has now resolved. Issue: V4 with RPi5 - encoders and S1.. buttons do not work · Issue #1736 · zynthian/zynthian-issue-tracking · GitHub
1 Like
Fine, but perhaps it is better not to put factory settings for pre-installed engines in zynthian-my-data. Then you wouldn’t have to worry about my ‘major tweak’ (nor about people making a backup of zynthian-my-data and restoring it, because that has the same effect).
I am pretty sure that happened with the latest beta. I pointed out that there were things in my-data that were being backed up and @jofemodo moved them to data. Are there more things that we missed or are these historical things from pre-beta?
Apart from lv2 only these:
ls presets/mod-ui/pedalboards/
Clavinet_AutoWah.pedalboard Crazy_Kalimba.pedalboard Rhodes_Vintage.pedalboard
Crazy_FX_Chain.pedalboard default.pedalboard
ls presets/TAL-U-No-LX
Default.pjunoxl 'FMR Presets Bank' 'FN Presets Bank' 'Juno Factory Bank A' 'TAL Presets Bank'
For the rest only the (empty )directory structure.
And while I’m at it, when the my-data is not present Zynthian startup hangs. Following in journal:
FileNotFoundError: [Errno 2] No such file or directory: '/zynthian/zynthian-my-data/snapshots'
Is that really necessary? Perhaps proceed with empty mixer if no snapshots are found?
Prehaps not, but we do certain checks to make decisions on various things and we can’t imagine how users might abuse the filesystem, especially the core data directories that one might make a reasonable assumption that users will stay away from… but we know users!!! 
I think what’s a little tricky might be the engine json, because it restores an outdated set maintaining abandoned engines and discarding new ones (while the latter might or might not be restored on engine database refresh).
Also i’m not sure about the zynswitch assignments in wiring config. I also didn’t restore config backup because I wanted to rule out that outdated switch assignments are restored. This could be a minor issue because you could change and revert the wiring profile to get the indended one.
unfortunately I only manually backed up zynthian-my-data selectively and forgot what was in there what I discarded.
Still curous about the xserver issue (solved by this config file mentioned above or respectivly installing this gldriver-test package), which according to the report above might vanish during update. The more precise question would be if solved by any of the fixes above a new image would be good or if I can go on with this.
Yes, I’ve tried different settings that used to work in Bookworm, noting worked without a conf file
After installing apt install gldriver-test and manually deleting 99-v3d.conf and 99-vc4.conf, the file 99-v3d.conf is regenerated at reboot and the system works perfectly.
The launcher screen builds up bit by bit within a second, when changing via keypress from Main Menu to Mix and then to Pad.
All other screen switches seem to work instantly.
There seems to be a difference with gldriver-test active and manually creating the 99-v3d.conf. With manually creating the file, the Launcher screen always build up within a second, with gldrvier-test, ist seems to be longer when switching from Main to Mix and then Pad, but faster with other screen switches. Changing from Pad to Mix and back to Pad builds up in a quarter of a second. Very strange. There is still something wrong in GPU.
I moved just the collection folder, although i’m pretty sure that some users would prefer this is stored in the zynthian-my-data
Well, it’s more complex than you would think … as you know, devil live is the little details!
There are a bunch of plugins (JUCE ones) that need we generate LV2 presets for them. The LV2 presets are generated dynamically, from the “native preset file list” that we need to parse. The JUCE framework doesn’t offer a mechanism for this.
We have specific scripts to dynamically generate presets for each plugin, like:
- generate_lv2_presets_DrMr.py
- generate_lv2_presets_hydrogen2fabla.py
- generate_lv2_presets_TAL-U-NO-LX.py
- generate_lv2_presets_vaporizer2.py
- generate_lv2_presets_VirtualJV.py
First, you must understand that it’s difficult to make a difference between vaporizer factory presets and vaporizer user presets, because the JUCE plugin internally generates a flat numbered list of presets and nothing more. We could try slicing the list, etc, but it would complicate things with little benefit. At the end we must parse all vaporizer presets and generate all LV2 presets dynamically. So, for zynthian all vaporizer presets are just this, vaporizer presets. No distinction between factory and user ones.
The zynthian-data directory is a git repository, and the presets subfolder already contains a bunch of static factory presets, under version control, so, generating the dynamic preset list into this folder doesn’t seem a good idea.
For this reason, we chose to generate dynamic factory presets in “zynthian-my-data/presets”. But this seems to not be good neither. At least for some users.
Currently we don’t have any other location to generate these LV2 presets, so we need to think for a while and find a good solution. Probably we have to add a third location for dynamically generated presets.
Regards,
1 Like
It’s supposed to be fixed, but i can’t test on other users hardware. It would be nice that users will check the first boot following these steps from terminal:
update_zynthian.sh
set_first_boot.sh
=> when the script finishes and the terminal disconnects, wait 10 seconds
=> power off (or unplug the cable)
=> wait 5 seconds
=> power on
=> verify first boot process
Thanks!
1 Like
@fussl please, follow the exact steps specified above and send feedback.
If you installed any package by hand, please uninstall it before. The set_first_boot.sh script won’t uninstall any package. Indeed, it would be better if you start with a fresh burned SD image just to be sure.
Thanks
Thanks for the explanation.
From my point of view, every preset that is pre-installed is a ‘factory’ preset. I don’t know if they are generated or deployed so from my end-user view they are all the same and I expect them to be in zynthian-data.
A ‘user preset’ is one that I made myself or that I found somewhere on the net. In any case, one that is not included in the installation. Those I expect to be put in zynthian-my-data.
Maybe it doesn’t work that way; if so, I would be happy to adjust my view.
2 Likes
I understand your POV, and it’s for this we are looking for a better solution that aligns with user expectations. The real problem is when some users expectations diverge from other users expectations. Or when user expectations are simply misaligned,
You shouldn’t expect this. Zynthian-data is a git repository with SOME factory data, but not ALL factory data is inside it.
Why should you assume that ALL factory presets are stored in zynthian-data?
As you stated above, factory presets are presets that the user doesn’t install by himself. The system will store factory data as convenient. Please, don’t make assumptions about where factory data is stored. The only valid assumption you could do is that factory data is not stored inside zynthian-my-data. We (the developers) accept this as a valid assumption and we are working on a good solution for this.
As i told you, things are normally more complex than you would expect, specially from the developers POV, and devil lives in the little details that most users ignore. We do our best, but increasing complexity is difficult to manage.
Regards,
The Beta Image is the same, so it will have the same desastrous auto-config and your fix has not been applied before the first_boot happens.
I’ll make a full backup with Clonezilla of the updated Zynthian and try the first_boot on this update.
Zynthian code assumes zynthian-my-data and some of the underlying subfolders do exist.
If your external storage is not mounted, you should have an alternate local subfolder.
It’s really easy to configure things like this, so please, don’t ask to change the code to support your specific tweaks when it’s a easier to solve with a few commands.
Regards,
I wasn’t clear enough in my previous post, but this is exactly what I mean. And that is also the only thing I need to know. As long as I can use zynthian-my-data and don’t disrupt the workings of the device by doing this, it’s fine for me.
As far as the other directories (including zynthian-data) are concerned, I agree with @riban 's comment:
So I will stay away from anything not my-data. Is that OK with you?
Hi @fussl !
Please, follow the exact steps. Don’t change any thing.
=> Fresh burn the BETA SD image
=> First boot (it will fail, of course!!!)
=> Access from terminal and run:
update_zynthian.sh
set_first_boot.sh
=> when the script finishes and the terminal disconnects, wait 10 seconds
=> power off (or unplug the cable)
=> wait 5 seconds
=> power on
=> verify first boot process
Thanks a lot!