Kodi Protocol Buffers Server disappearing in high frequency causes flickering

1st Official Post

    Hello & good evening,


    I'm just discovering this interesting project, want to say thank you for all the efforts so far, but just stumbled upon a problem.


    While using no external USB-grabber und trying with the KODI-Addon as a software grabber, the protocol buffers server is disappearing frequently (one ore twice a second), which can be observed in the web configuration tool "remote control", causing the WLED to flicker extremly.


    At the same time, these messages are appearing in the data logger in infinite repetitions:

    "

    2024-12-26T21:14:09.343Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:178:registerInput()) Register new input 'Proto@::ffff:127.0.0.1/PROTOSERVER' () with priority 100 as inactive

    2024-12-26T21:14:09.343Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:422:updatePriorities()) Set visible priority to 100

    2024-12-26T21:14:09.343Z [IMAGETOLED|First LED Hardware instance] (DEBUG) (ImageToLedsMap.cpp:112:ImageToLedsMap()) Total index number is: 810 (memory: 810). Reduced pixel set factor: 0, Accuracy level: 0, Image size: 64 x 36, LED areas: 270

    2024-12-26T21:14:10.270Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:371:updatePriorities()) Timeout clear for priority 100

    2024-12-26T21:14:10.270Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:422:updatePriorities()) Set visible priority to 250

    2024-12-26T21:14:10.271Z [IMAGETOLED|First LED Hardware instance] (DEBUG) (ImageToLedsMap.cpp:112:ImageToLedsMap()) Total index number is: 23520 (memory: 23520). Reduced pixel set factor: 0, Accuracy level: 0, Image size: 480 x 270, LED areas: 270

    "


    Could it be, that my home server is overloaded and if, could I adjust manually the internal timeout trigger, that seems to cause this effect ?

    I am grateful for every good advice. :thumbup:


    best regards & thank you

    Jan

    tl;dr: I am facing the same issue in a similar setup. I am regularly losing connection between Kodi and Hyperion after few seconds, and it get's re-established in ca 0.25s.


    Question: Is there any way to increase the timeout in Hyperion?


    Setup:

    - Kodi 21.2-Omega on Debian Bookworm via flatpak, with Hyperion Ambilight 20.0.2 add-on installed

    - Hyperion 2.1.1 on Debian Bookworm, installed via apt.

    Both running in an LXC on a proxmox environment (same host).


    In the Hyperion log I see that the input is dropped regularly. On the LEDs (wled) this causes the fallback to the default one (best case they all turn off, or they fall back to whatever was configured), but basically causing a quite noticeable visible disruption (blinking) every few seconds. This does not happen in a fixed interval.


    From the Hyperion log it seems like Kodi stops sending data every few seconds. However, I do not see any indications of a problem in the kodi.log file. The proxmox resource monitor shows that there is sufficient CPU and RAM capacity left, and the network load is quite low as well. From all that I can see there is no obvious reason why data would not be sent, or be delayed or dropped.


    Hyperion log (shortened to keep the message below 10k chars) with annotations:

    • Official Post

    Hyperion 2.1.1 unfortunately has problems, but 2.0.16 should work.


    Next time please attach a complete debug log as Hyperion-log.txt


    regards pclin

    Dreambox ONE / TWO

    dreamOS OE2.6

    Amlogic S922X - 53.000 DMIPS - 2 GB RAM - 16 GB Flash - Twin-DVB-S2X Tuner - HDR10 - HLG
    -
    AudioDSP: miniDSP 2x4HD - Amp: Pentagon - Lautsprecher ELAC / ARENDAL
    LG OLED65BX9LB (PicCap, hyperion.NG webOS)

    FireTV 4K max

    -
    hyperion (classic) & Plugin HyperionControl | hyperion-ng 2.0.16-beta.1 (dreamOS)
    Hyperion-ng (Debian bullseye)
    -
    6 x ESP32/Wemos D1 mini - WLED - SK6812 RGBW-NW 60 LEDs/m
    FeinTech VSP01201 - Grabber Macrosilicon

    LG TV Hyperion webOS & PicCap


    Ambilight for ever

    Thanks for the reply. Unfortunately 2.0.16 has exactly the same problem.


    - Ran `bash install.sh -r` and `rm -r ~/.hyperion`

    - Installed https://github.com/hyperion-pr…on-2.0.16-Linux-amd64.deb

    - Configured output for wled, picked my instance and configured the frame layout (178 LEDs 57x32, 5% corner distance

    - Set logging to Debug

    - Started videoplayback in kodi


    Again the input is getting lost for about a quarter of a second and then gets re-established. Log attached, looks the same to me as 2.1.1.

    • Official Post

    Is there anything in the Kodi log?

    I am not familiar with Promox nor LCX, but did you ensure that network traffic in both directions is feasible?

    It look like that the Hyperion response is not received by the Kodi add-on why the Next message is not send and then Hyperion drops the session because of timeout.

    I can ping and ssh in both directions between the two LXCs, and there is no firewall set up. To be really sure, I just installed Hyperion 2.1.1 onto the Kodi container directly and even configured 127.0.0.1 in the Kodi add-on, so all communication is local. This did not fix the problem.


    Enabling Kodi debug logging, there is not much output (except the usual noise).

    Code
    2025-08-23 07:54:18.370 T:82       info <general>: [Hyperion Ambilight] - Establishing connection to hyperion at 127.0.0.1:19445
2025-08-23 07:54:33.938 T:82      debug <general>: [Hyperion Ambilight] - Captured image is none or < expected. captured: 0, expected: 8192
2025-08-23 07:54:48.971 T:82      debug <general>: [Hyperion Ambilight] - Captured image is none or < expected. captured: 0, expected: 8192
2025-08-23 07:54:58.971 T:82      debug <general>: [Hyperion Ambilight] - Captured image is none or < expected. captured: 0, expected: 8192
2025-08-23 07:55:13.971 T:82      debug <general>: [Hyperion Ambilight] - Captured image is none or < expected. captured: 0, expected: 8192
2025-08-23 07:55:23.938 T:82      debug <general>: [Hyperion Ambilight] - Captured image is none or < expected. captured: 0, expected: 8192

    The "Captured image" error happens significantly less often than the flickering.


    I added some log output to the add-on code: to print something in the error and going to disconnected state, the time it takes to capture the image, the time it takes to get a reply, and output an error whenever the reply is not SUCCESS (never printed):

    Code
    2025-08-23 08:39:46.142 T:41       info <general>: [Hyperion Ambilight] - Image capture stats (last 5.0s): Avg: 100.12ms, Min: 100.12ms, Max: 100.12ms | Samples: 1
2025-08-23 08:39:51.112 T:41       info <general>: [Hyperion Ambilight] - Reply stats (last 5.0s): Avg: 40.23ms, Min: 6.28ms, Max: 42.26ms | Samples: 37
2025-08-23 08:39:51.170 T:41       info <general>: [Hyperion Ambilight] - Image capture stats (last 5.0s): Avg: 92.94ms, Min: 26.39ms, Max: 127.60ms | Samples: 38
2025-08-23 08:39:56.210 T:41       info <general>: [Hyperion Ambilight] - Reply stats (last 5.0s): Avg: 41.22ms, Min: 40.41ms, Max: 42.35ms | Samples: 36
2025-08-23 08:39:56.336 T:41       info <general>: [Hyperion Ambilight] - Image capture stats (last 5.0s): Avg: 102.08ms, Min: 58.25ms, Max: 126.23ms | Samples: 36
2025-08-23 08:40:01.245 T:41       info <general>: [Hyperion Ambilight] - Reply stats (last 5.0s): Avg: 41.22ms, Min: 40.38ms, Max: 42.26ms | Samples: 42
2025-08-23 08:40:01.436 T:41       info <general>: [Hyperion Ambilight] - Image capture stats (last 5.0s): Avg: 77.23ms, Min: 57.84ms, Max: 125.94ms | Samples: 43
2025-08-23 08:40:06.278 T:41       info <general>: [Hyperion Ambilight] - Reply stats (last 5.0s): Avg: 41.10ms, Min: 40.32ms, Max: 42.16ms | Samples: 38
2025-08-23 08:40:06.469 T:41       info <general>: [Hyperion Ambilight] - Image capture stats (last 5.0s): Avg: 92.28ms, Min: 66.52ms, Max: 124.69ms | Samples: 38
2025-08-23 08:40:11.310 T:41       info <general>: [Hyperion Ambilight] - Reply stats (last 5.0s): Avg: 41.18ms, Min: 40.25ms, Max: 42.24ms | Samples: 37

    So from the point of view of the add-on everything is fine. There are no errors at all. All sent images are getting a "success" response, and the time to send the image + getting/deserializing the response is 41ms +/- 1ms (no outliers). What's noticeable is that the image capturing is quite variable in time. Is this expected? Both assigned CPU cores are around 5% in use, so there doesn't seem to be any performance issue.

    I do wonder whether there is some expectation on Hyperion side on how quickly the next image comes? Again, what's noticeable on Hyperion log side is that the "Timeout clear" message is followed by "New connection" around 250ms later. There isn't actually a "new" connection, the socket from the add-on side remains the same and functional all the time. So I suspect maybe that every now and then the time between two images is too long and Hyperion drops the "connection"?

    Alright, seems the expectation on framerate is controlled by the add-on. It has a default setting of 10 Hz, which means it notifies Hyperion.ng that each image is only valid for 100ms (https://github.com/hyperion-pr…urces/lib/monitor.py#L153). Given that I see image capturing taking up to 130ms, this seems to explain the issue. I changed the add-on to send 3*sleep_time (= 300ms) and this seems to have fixed the issue (based on 10 minutes of watching a video). I guess it raises the question whether the frame grabbing should be more consistent in its timing, but as it doesn't seem to have any noticeable issues now I am happy :)

    Reducing the framerate to 5 and switching back to the original add-on code also seems fine.

    Edited 2 times, last by linisgre: Merged a post created by linisgre into this post. ().

    Just as a follow-up: have been using it for a while now and works fine at 5 Hz.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login