Beiträge von Awawa

remove console=serial0,115200
also put dtoverlay=disable-bt at the end of config.txt if it's missing (it was missing for some reason in your latest config so you had some difference from Rpi3 you must watch it)

Yes, the timeout is coming back.
On Rpi4 Bluetooth shouldn't be a problem according to the doc. So something else steal AMA0.
I suspect console so could you repeat that steps with editing config cmdline.txt (removing console0) and disabling serial-getty@ttyAMA0.service ?

Check again what I wrote: that part of the system grabber particularly. It works on Rpi3 but doesnt work on Rpi4 and it was enabled.

Yep, I noticed and replied as you wrote it

Strange, because there wasn't that error in the log before, maybe it was taken to soon before it occured.
Anyway it isn't fully log from Hyperion in DEBUG mode but a part of it.

Summarize:
1) you took full copy of working system from Rpi3 to Rpi4
2) Rpi4 doesnt work. In normal circumstances we can exclude Hyperion as a suspected because the config is the same and it works on Rpi3.
3) But it isn't that case as Alpha 8 has broken system grabber on Rpi4. And system grabber is enabled...
4) We try to overcome Serial port problem again but it's dead end as the Hyperion isn't working (didnt you notice it in the hyperion log?)
5) Now we have AMA0 in unknown state after some experiments. Not sure if it isnt problem but the path of changes to make it work was definitely wrong based on wrong diagnosis.

So I propose to disable system grabber on Rpi 3 then to make a full copy of that working system to another card and try to run it on Rpi 4 again

With your previos log you've got that error ('Timeout writing data to ttyACM0') only when the light-berry was disconnected. Did you connect it again and rebooted? PS: put debug level to DEBUG as now we can see only errors.

Yes, post logs from Hyperion after change

Zitat

[hyperiond DISPMANXGRABBER] (ERROR) Previous line repeats 200 times

Definitely not good. Forget for now about Lightberry. Did you disabled system/platform grabber as it's completely broken in Hyperion.NG alpha 8 on Rpi4?

OK, lets try this:

sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl mask serial-getty@ttyAMA0.service
sudo reboot

If it doesn't help could you provide output after reboot of:

ls -l /dev/ttyACM0
(try to execute it again with lightberry connected/disconnected to compare, reboot before each action)

and content of /boot/config.txt and logs from hyperion WWW page to check what's happening inside.

Post dmesg after changes

Read hyperion logs

https://www.circuits.dk/setup-raspberry-pi-3-gpio-uart/

These errors are specific for that system/config, if other things work on Rpi3 then you can ignore them on Rpi4 too.
Try remove console=serial0, console=ttyAMA0 and console=ttyS0 from cmdline.txt.
Seems that ttyAMA0 is taken over at start up again (not by bluetooth).

https://www.raspberrypi.org/do…ion/configuration/uart.md

It's highly problematic USB to lightberry converter, sorry.

Testing lag (1080p and 4k HDR):

[MEDIA=streamable]wyspuy[/MEDIA]

[MEDIA=streamable]nunadx[/MEDIA]

Smoothing was disabled for that test (I use it on daily base with settings 100/100/0 and disabled continues output).
No size decimation, I removed that option in my fork anyway.

Well, if that plugin is working for you then you could try to replace hyperiond executable with one from the extracted .deb archive on fork page and see what will happen. The .deb packages are related to Hyperion.NG ones beside new Raspbian Buster release. It's a rough ride and there's a lot of thing that can go wrong but shouldnt break anything (if you backup your hyperiond file first) so compiling from sources is recommended. I've got no idea how to build dedicated package for that system, sorry.

I'm not familiar with that setup/system but if it's based on screen grabber from Kodi output and you aren't using any USB grabber (v4l2 grabber interface) then my fork has no benefits over standard Hyperion.NG edition.

Glad it helped
For the flickering did you have Smoothing & continues output enabled on Hyperion.NG maybe? It gave me massive headache as it caused flickering in dark scene in my case. I almost endup with 3.3/5v level converter but it was totally unnecessary as it was caused by that plugin/settings.

The only thing that come to my head is higher FPS or/and lower CPU usage on fork for some reason helped with LED refresh and reduced flickering in your case.

Post dmesg from Rpi4 and make sure that the Hyperion is working on the correct port - just in case of auto-detecting something.

https://github.com/hyperion-project/hyperion.ng/issues/1007 ?

I prefer to shutdown whole LED&Rpi system with Power Cube Remote (my raspbian system is on the read-only image so it's safe). There is a signal detection in Hyperion but dont know how to setup it.