9.1.2 Observation - LocalUI.Service - Printable Version +- Moode Forum (https://moodeaudio.org/forum) +-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3) +--- Forum: Support (https://moodeaudio.org/forum/forumdisplay.php?fid=7) +--- Thread: 9.1.2 Observation - LocalUI.Service (/showthread.php?tid=6973) |
RE: 9.1.2 Observation - LocalUI.Service - 2800GT - 10-08-2024 I've now had chance to confirm my previous findings; 9.0.8 local display working as expected (RPiOS 12.6 and kernel 6.6.31) 9.1.0 local display working as expected (RPiOS 12.7 kernel 6.6.47) 9.1.2 local display not working when "log to RAM" enabled 9.1.2 local display partially working when "log to RAM disabled - playback and volume sliders not drawn but are working Cheers, Graham RE: 9.1.2 Observation - LocalUI.Service - TheOldPresbyope - 10-08-2024 Definitely, the more eyeballs on a problem the better. The "Failed to connect" error has long puzzled me. I have seen mention of it on the InterWeb but always in the context of Windows WSL. On a different front, I've made a little progress just now. Pi 3B+ with official 7" touchscreen and moOde r9.1.2 with log-to-RAM disabled: If I add the switch --disable-gpu to the chromium-browser invocation in /home/<user>/.xinitrc, I now see working progress and volume roundels and I don't see what I called "tearing" which may be the same as Tim's "partial backgrounds". Also, no "Draw call returned Invalid argument" error shows up in journal. No clue yet what log-to-RAM is causing. Also, no clue about the new ssl_client_socket errors which are appearing in r9.1.2 journal but not in previous. Presumably the new version of chromium-browser is doing something new. Regards, Kent RE: 9.1.2 Observation - LocalUI.Service - 2800GT - 10-08-2024 The "--disable-gpu" switch has worked for me too Is this draw error looking like a Chromium issue introduced into build 129 ? (9.1.0 had build 128) RE: 9.1.2 Observation - LocalUI.Service - Tim Curtis - 10-09-2024 Looks like a bug in the 129 build of chromium. If I apt upgrade a fresh 9.1.0 system with only the chromium packages marked as hold then no display issues. Code: pi@moode910:~ $ dpkg -l | grep chromium The remedy should be to go with < 129 build of chromium until testing indicates the bug in 129 or higher has been fixed. The question is what package versions are currently in the Debian archive pool, prolly not 128 yet. I'll do some investigation and post the results later today or tomorrow. For the log2ram issue try the following to reduce the amount of memory it uses. I see it's currently using a default of 128M and it should be 32M. Prolly a missing config edit in the moode-player package postinstall script. Code: # Update log2ram memory size (reduce from default 128M to 32M) RE: 9.1.2 Observation - LocalUI.Service - TheOldPresbyope - 10-09-2024 What a lot of bother just to have a local display Regards, Kent RE: 9.1.2 Observation - LocalUI.Service - Tim Curtis - 10-09-2024 lol, chromium giveth and chromium taketh away RE: 9.1.2 Observation - LocalUI.Service - Tim Curtis - 10-09-2024 Here's a procedure to downgrade chromium. Let me know how it goes. Chromium browser downgrade to 126 Code: # 1. Update package list Here's the before and after Code: # Before RE: 9.1.2 Observation - LocalUI.Service - TheOldPresbyope - 10-09-2024 @Tim Curtis - Pi 3B+/official RPi 7" touchscreen - fresh install r9.1.2 Ran your steps and ended up with mixed 126/129 dpkg output: Code: rho@mpi3bplcd:~ $ dpkg -l | grep chromium Not sure what happened there. I'll repeat with yet another fresh install just to be sure. --- Still, with what I have, the local display fails when log2ram is enabled but succeeds if it's disabled. If I also patch the log2ram config as you suggested earlier, the local display now succeeds with log2ram enabled. The roundels appear and are functional. However, I still see the partial background effect when selecting config screens. Really annoying 'cuz it interferes with choosing options onscreen. I traced the specific Xserver initialization fail to these lines in the Xorg.0.log file Code: [ 60.275] (EE) open /dev/dri/card0: No such file or directory When the Xserver intialization succeeds I see, instead, Code: rho@mpi3bplcd:~ $ grep card /var/log/Xorg.0.log It's not clear to me why the somewhat higher log2ram memory would cause this. Regards, Kent RE: 9.1.2 Observation - LocalUI.Service - Tim Curtis - 10-09-2024 It s prolly that without the size adjustment log2ram hogs 128M memory and on systems with only 1GB ram chromium prolly thinks it doesn't have enough ram to start? Just guessing... If you still get leftover 129 packages after the procedure, post back and I'll run some tests on my end. I haven't been tracking changes to chromium for a long while because it's just worked but now it's clear there were major changes with these latest releases. Most likely to better support DRM and stuff like that for the Pi Desktop environment. RE: 9.1.2 Observation - LocalUI.Service - 2800GT - 10-09-2024 I may be doing something wrong I manually edited the log2ram.conf to reduce the SIZE to 32M but after reboot it is still killing my local display when I enable log2ram option Out of interest, should I also be reducing the "LOG_DISK_SIZE=256M" parameter to something more like 64M (assuming 2:1 compression) or does that not matter ? Update - just spotted that zram is not being used to the log_disk_size is meaningless I've not tried to roll-back chromium yet |