This freezes you in the past. It was only really to test where the issue arose. You can stay there until we fix this but you won’t see the benefits of development and I may be asking for more diagnosis help as I cannot reproduce on my hardware.
A better approach to solving this would be to submit a PR with your changes, rather than patching it live.
Thanks @riban, I’ll do all testing you need to fix it.
2 Likes
Good, thanks. Thus I will update the Waveshare kit, and later will check the result also on the Raspberry Pi500+. 
1 Like
Do I need to fork the project to PR?
Yes - you fork so that you have a repo from which to make the request. You clone your repo, make the changes, commit and push then you have the option to pull request against the zynthian repo. It may seem like a bit of a faff (and I don’t like having lots of forked repos on my account) but after a PR has been accepted you can always delete the fork.
OK, I never did that….it’s time to learn something new.
1 Like
Now the Waveshare setup seems locked in a perpetual update request cycle, apparently without actually adding or changing any code after the third update process.
UI Log in debug mode, after the last update and reboot:
Apr 29 16:49:49 zynthian startx[10531]: INFO:zynthian_gui_admin.reboot_confirmed: REBOOT
Apr 29 16:49:49 zynthian startx[10531]: INFO:zynthian_state_manager.save_snapshot: Saving snapshot /zynthian/zynthian-my-data/snapshots/last_state.zss ...
Apr 29 16:49:49 zynthian startx[10531]: INFO:zynthian_gui.exit: STOPPING ZYNTHIAN-UI...
Apr 29 16:49:49 zynthian startx[10531]: INFO:zynthian_gui.osc_end: ZYNTHIAN-UI OSC server stopped
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor zynaddsubfx:part0/
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor zynmixer_chan
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 0 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 8 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging chain 1 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor LinuxSampler:out0_
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor zynmixer_chan
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor YK_Chorus-01
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'LS' ...
Apr 29 16:49:50 zynthian startx[10531]: INFO:zynthian_engine.stop: Stopping Engine LinuxSampler
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'JV/14' ...
Apr 29 16:49:50 zynthian startx[10531]: INFO:zynthian_engine_jalv.stop: Stopping Engine Jalv/YK Chorus
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 1 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 9 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 4 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging chain 2 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor Noize_Mak3r-01
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor zynmixer_chan
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'JV/15' ...
Apr 29 16:49:50 zynthian startx[10531]: INFO:zynthian_engine_jalv.stop: Stopping Engine Jalv/Noize Mak3r
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 2 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 10 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging chain 3 from ZS3 zs3-0
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor zynaddsubfx:part1/
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor zynmixer_chan
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor YK_Chorus-02
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'MI' ...
Apr 29 16:49:50 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'ZY' ...
Apr 29 16:49:50 zynthian startx[10531]: INFO:zynthian_engine.stop: Stopping Engine ZynAddSubFX
Apr 29 16:49:51 zynthian startx[10531]: INFO:zynthian_engine.osc_end: OSC server stopped
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'JV/16' ...
Apr 29 16:49:51 zynthian startx[10531]: INFO:zynthian_engine_jalv.stop: Stopping Engine Jalv/YK Chorus
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 3 from ZS3 zs3-0
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 11 from ZS3 zs3-0
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 5 from ZS3 zs3-0
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging chain 4 from ZS3 zs3-0
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_chain.remove_processor: Removing processor SC4-01
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_chain_manager.stop_unused_engines: Stopping Unused Engine 'JV/17' ...
Apr 29 16:49:51 zynthian startx[10531]: INFO:zynthian_engine_jalv.stop: Stopping Engine Jalv/SC4
Apr 29 16:49:51 zynthian startx[10531]: DEBUG:zynthian_state_manager.purge_zs3: Purging processor 7 from ZS3 zs3-0
Apr 29 16:49:51 zynthian startx[10531]: ERROR:zynthian_chain_manager.remove_processor: Chain None doesn't exist!
Apr 29 16:49:51 zynthian startx[10531]: INFO:zynthian_gui.stop: All threads finished normally
Apr 29 16:49:51 zynthian startx[10531]: INFO:zynthian_main.<module>: Exit with code 100 ...
Apr 29 16:49:51 zynthian startx[10531]: zynmixer ended
Apr 29 16:49:52 zynthian startx[10531]: zynmixer ended
Apr 29 16:49:52 zynthian startx[10531]: libzynaudioplayer exiting
Apr 29 16:49:52 zynthian startx[10500]: *******************
Apr 29 16:49:52 zynthian startx[10500]: EXIT STATUS => 100
Apr 29 16:49:52 zynthian startx[10500]: *******************
Apr 29 16:49:52 zynthian startx[10958]: /zynthian/config/img/fb_zynthian_message.jpg is a 1920x1080 JPEG image, color space Grayscale, 1 comp, Huffman coding.
Apr 29 16:49:52 zynthian startx[10958]: Zooming image by 100%...done
Apr 29 16:49:52 zynthian startx[10958]: Merging...done
Apr 29 16:49:52 zynthian startx[10958]: Building XImage...done
Apr 29 16:49:52 zynthian startx[10491]: xinit: connection to X server lost
Apr 29 16:49:52 zynthian startx[10491]:
Now I have to leave home for some errands, and will get back here later.
Many thanks for the time being @riban 
PR created https://github.com/zynthian/zynthian-ui/pull/564
Thanks.
Hi @riban and @smespresati 
,
The roll-back trick worked also on the Raspi 500+ with mouse and HDMI screen (Arzopa 15.6").
I applied:
git checkout 58814e8126f3ba0c340f0f36089a0083e0a672a8
and this system too went in a state of infinite update request cycle. I attempted to force-update both setups with:
/zynthian/zynthian-sys/scripts/update_zynthian.sh
but the recycle symbol signalling an available system update remains.
For the rest, both custom installations work exactly in the same way, meaning that the GUI freezing issue on triggering Chain Manager wasn’t strictly related to touchscreen operation.
Cheers
1 Like
I don’t quite understand. You say that the roll-back worked then say it is in a state of infinite update request… Do you just mean that there is an indication that updates are available? This is because the git command has put the local copy into a detatched state, i.e. it is fixed on the old version and will not update. In fact it may break the system to try to do an update because other repos will update but the ui repo won’t. This was only to help diagnose where the problem is. It is not a fix.
It is odd that you get the problem with RPi500 + mouse. Have you applied config with vc4-kms-v3d or some other config that may also have changed behaviour? (We could be chasing different issues with similar symptoms.)
Hi @riban, maybe I wasn’t clear enough in my wording. I meant that the roll-back patch worked like a charm, and that now I have full GUI operation also on the Pi 500+ with mouse.
As per your advice, I updated both systems in order not to let them frozen in the past, like you commented. But perhaps I misunderstood. No big deal anyway, since even after the updates both setups work. 
Let me know what you possibly suggest to do further.
Cheers
Hi @riban , What you say about KMS driver is correct in Vangelis (on pi 5). By putting this driver in Webconf I can get resolution 1920x1280 that matchaes my touchscreen, but appears touch issue. If I remove driver KMS from webconfig I only can get 1920x1080 resolution but touch interface works properly. I can live with that suboptimal resolution. Keep in mind I’m testing with the previous Vangelis version we talked about yesterday.
Anyway, kms driver works pretty well with my V4 kit (pi 4) configured to use my HDMI+USB touchscreen.
It’s really surprising that the modern KMS driver fails on pi 5 and works on pi 4. I guess Oram and Vangelis are both Bookworm based.
If you need other testing I’ll be available to do it.
Thanks
Correct
I realised that, one the conclusion of my testing is Oram works on pi 4 and pi 5, so do kms works on pi 5? Does this means that something has changed in Vangelis code affecting only some types of display/touch models? Or…I know that kernel and other packages were updated in Vangelis, may this changes affect the display/touch behaviour?
What It’s clear is that, between Vangelis versions, the behaviour has changed (in a previous version Chain Options worked). New features (what means new code) were added and, perhaps, kernel/packages updated?
I’m not by far a Linux expert, so I cannot answer these questions and, of course, I’m not so skilled to investigate further to find a solution.
Best regards
Upon updating a vangelis zynthian I have been consistantly failing on .
May 05 09:43:24 zynthian-cajon3 zynthian_webconf.sh[1789]: error: failed to open file /usr/local/lib/lv2/TheUsualSuspects.tar.xz.1/manifest.ttl (Not a directory)
May 05 09:43:24 zynthian-cajon3 zynthian_webconf.sh[1789]: lilv_world_load_file(): error: Error loading file `file:///usr/local/lib/lv2/TheUsualSuspects.tar.xz.1/manifest.ttl’
May 05 09:43:24 zynthian-cajon3 zynthian_webconf.sh[1789]: lilv_world_load_bundle(): error: Error reading file:///usr/local/lib/lv2/TheUsualSuspects.tar.xz.1/manifest.ttl
I have removed the last_State.zss and this has, at least, allowed the machine to boot to something that allows selection of an engine and a chain, but webconf resolutely refuses to start complaining of the above error.
ZynthianOS ORAM-2409
Timestamp: 2024-10-02
Built from RaspberryPiOS Bookworm (aarch64)
Kit: Custom
Display: Generic HDMI Display
Soundcard: HifiBerry DAC+ ADC PRO
Wiring Layout: DUMMIES
zynthian-ui: vangelis (439cce)
zynthian-webconf: vangelis (f55fba)
zyncoder: vangelis (a4b603)
zynthian-sys: vangelis (3acc7d)
zynthian-data: vangelis (32d5cc)
I can load an audio chain and I can hear the effects but the GUI is crashed.
Been kicking it around for a day or so but it is pretty resolute in it’s failure.
Updated from the command line several times.
Anyone any ideas?
I don’t know if this helps, but TheUsualAspects should point to a plugin from TUS: Osirius, Ostrius, Vavara, Xenia, JE8086…
Yes, I’ve been following the birds and butterflies down the meandering path and it does all seem to beheading into Privateer ROM territory.
Seems a fairly heavy dependence pretty high up in the lv2 gathering, so perhaps I’m being punished for using a concept name, frequently, without digging down to the bottom of it.
I’m not sure if I understood the flowery language. 
So I might be guessing. The TUS plugins require the original software of the respective synthesizers; perhaps uninstalling these plugins will help.
1 Like
Oh, it’s just my way.
That’s an idea but webconf resolutely refuses to kick into life.
I really need to write up some lv2 stuff to get my head around the order things get done in round there.
Time for cajon3.local to become cajon4.local
Time for a new 32G SSD methinks.