Wrong image encoding (green/pink colors) on signal detection using USB grabber

[newkind]

• I confirm that this is an issue rather than a question.

Bug report

I'm using a Hyperion.ng with external USB grabber based on MS2130 chipset and sometimes when I watch something else for a while ie. from the apps built-in into TV and switch back to the source that's using the grabber and Hyperion.ng the image encoding is wrong. Everything is green/pink - please see attached screenshots. It looks like Hyperion.ng upon detecting the signal again doesn't set the proper image format (or something like that)? It happens every couple days and the only way to solve this is to restart the Hyperion/device.

Debug logs from Hyperion.ng: https://pastebin.com/raw/h97ZpAza

---

EDIT:
Happened again just after couple of hours - new log: https://pastebin.com/raw/RSswbW58

Screenshots:

Steps to reproduce

1. Switch the watching source to built-in TV app so the Hyperion.ng will disable the grabbing/LEDs
2. Watch it for an hour or so
3. Switch back to the previous source (with Hyperion.ng and USB grabber) and the LEDs will be green/pink because of the image Hyperion sees internally.

This doesn't happen everytime, just every couple days, but its annoying to have to restart the device everytime.

What is expected?

Hyperion.ng should correctly set encoding/color space for the USB grabber and display proper colors.

What is actually happening?

Everything looks green/pink and that's causing wrong LED colors.

System

Hyperion Server:

• Build: (HEAD detached at a93d79b) (Paulchen-Panther-cb85d2d/a93d79b-1705568419)
• Build time: Jan 28 2024 10:21:59
• Git Remote: https://github.com/hyperion-project/hyperion.ng
• Version: 2.0.16
• UI Lang: pl (BrowserLang: pl)
• UI Access: expert
• Avail Screen Cap.: dispmanx,framebuffer,qt
• Avail Video Cap.: v4l2
• Avail Audio Cap.: audio
• Avail Services: boblight,cec,effectengine,forwarder,flatbuffer,protobuffer,mDNS,SSDP,borderdetection
• Config path: /root/.hyperion
• Database: read/write
• Mode: Non-GUI

Hyperion Server OS:

• Distribution: Debian GNU/Linux 12 (bookworm)
• Architecture: arm64
• Kernel: linux (6.6.31-current-sunxi64 (WS: 64))
• Root/Admin: true
• Qt Version: 6.4.2
• Python Version: 3.11.2
• Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:130.0) Gecko/20100101 Firefox/130.0

[Paulchen-Panther]

For some reason, your HDMI grabber changes the output format.
I have seen that you are using signal detection to turn off your LED when you are not using the grabber.
Hyperion turns off the LEDs but does not disable the V4L2 device. The data is continuously converted to the appropriate format in a thread but not processed further.
See here: https://github.com/hyperion-project/hyperion.ng/blob/master/libsrc/grabber/video/v4l2/V4L2Grabber.cpp#L1082-L1093

Possibly your MS2130 switches off the processing internally and when a signal is reactivated it sets it to a default format which does not correspond to the format set in Hyperion.

Can you show us the output of v4l2-ctl --device /dev/video1 --all

Thank you very much.
Greetings Paulchen

[newkind]

@Paulchen-Panther I'll be glad to help you with everything you need in order to help to solve this. Here's the v4l2-cli output: https://pastebin.com/raw/HaWsJ6m0

I can see the default format for the device is Pixel Format: 'YUYV' (YUYV 4:2:2) and that's exactly the same format I have set in the Hyperion configuration.

The output was read when everything was working properly - should I catch another one when it will break again?

[Paulchen-Panther]

The output of dmesg might be of interest. Of course only after you notice that the colors are no longer correct.

[newkind]

@Paulchen-Panther ok, just happened again.

Hyperion.ng log: https://pastebin.com/raw/UYMhdmBh
v4l2-ctl: https://pastebin.com/raw/q2edsfp8
dmesg: https://pastebin.com/raw/t88r58mS

Please let me know if you find something or you need anything else.

[Paulchen-Panther]

Do you use a USB hub? If so, passive or active?
What does your setup look like (USB devices, power supply, LEDs + power supply etc.)?

[newkind]

Yes, I use USB hub. Its a passive USB 2.0 hub as I had some issues with 3.0 hub (both passive and active) in the past. I even reported it here as I thought there was some other kind of bug, but after changing the USB hub to the current one, the disconnects stopped but these weird colors appeared instead (#1759).

My setup is - Orange Pi Zero 3 (4GB version) + USB 2.0 hub + MS2130 USB Grabber + Arduino Uno used to control the WS2812b LEDs. Both MS2130 and Arduino are connected to the USB hub.

Orange Pi Zero 3 is powered by its original adapter 5V 3A and the LEDs have their own, separate power supply 5V 10A.

[Paulchen-Panther]

Possibly the kernel sets the USB capture device to suspend mode and this causes problems. Can you please disable this behavior using udev rules and see if it works?
Here are a few links:
https://hamwaves.com/usb.autosuspend/en/
https://wiki.archlinux.org/title/Power_management#USB_autosuspend
https://www.kernel.org/doc/Documentation/usb/power-management.txt

[newkind]

Thanks for those links. I have made the changes and I'll be testing it now. I'll report when something happens. Thank you!