Beiträge von osen

    What settings are you using for capture resolution, picture decimation and so on? With platform capture on Raspberry Pi there seems to be a bug with picture decimation causing stuttering at the moment, I have no idea if this affects platform capture on PC too.


    You could try using no decimation (1) or exporting the configuration, edit the values manually (just input the values after decimation, for example 1920x1080 with 8 decimation would be 240x135) in the JSON file and import it again just to test this, like this:



    I have now watched a couple of hours of material that was very problematic before and the stuttering seems to be completely gone with the trick above. Everything is butter smooth with zero missed vblank updates using 235x180 capture resolution and no decimation. I cannot tell any difference in the backlight granularity or fidelity.


    I played around a bit more with the decimation setting for 1920x1080 and I find it a bit odd that there seems to be no performance (or visible) difference between 1 and 30. Maybe the decimation setting is bugged and isn't applied, and that could cause these performance issues ...? Just an amateurs' guess.

    Any updates on this? I'm wondering if this is the same performance issue I'm experiencing on a RPi3B. System load is very low, but no matter what picture decimation and update frequency settings are being used I get severe stuttering as soon as the grabber is enabled.


    EDIT: Tried the trick of editing the exported JSON with very good results, but leaving me a bit confused.


    Using 1920x1080 with 8 picture decimation gave me about 40 dropped frames in a 30s 50Mbps test clip, while using an edited JSON with 240x135 and no decimation (1) resulted in 0 dropped frames and butter smooth playback. The latter also seemed to incur less system load, even if both are low.


    Shouldn't these two result in the same capture resolution?

    Seeing as the transitions between solid colour and platform capture works without a hitch I tried another workaround: using a solid colour with zero brightness ("black") between the transition (effect - > 3s delay -> black -> 3s delay -> platform capture and other way around).


    This did not improve the situation sadly, still the same issue.

    Didn't have time yesterday, sorry. I think it's running as a custom component with the edited light.py but I'm not 100% sure as I don't know how to verify that HA uses those files for the integration rather than the core ones. It is indicating that the integration is a custom component with it though. I simply removed the following:


    Code
    if not await self._client.async_send_clear(
                    **{const.KEY_PRIORITY: self._get_option(CONF_PRIORITY)}
                ):
                    return

    Was that correct?

    Anyway it seems to have made things even worse. Now the transition effect to platform capture never works. Here's a log.


    Adding a delay in the automation going light.turn_off -> 3s delay -> light.turn_on did not work either, log here. Using the original light.py did not change this.

    I haven't tinkered with automation in a long while but I think it should be possible to add a delay between dual actions (turn off effect -> delay -> turn on other effect) instead of just having a single action changing effect. I don't know when the clear command is sent though.


    I'm running Home Assistant Operating System, which I believe uses nestled Docker containers, making accessing the actual files complicated (especially when you're not very tech savvy like me ...). It may be possible to use custom components for this and "sideload" and edited version of the integration (never done it). I'll look into it tomorrow.

    I just tried changing manually between random different effects in HA and I run into the same issue sometimes, but it's very inconsistent:



    On the last lines the source is removed/cleared instead of changing effects. Then when trying to run a new effect in this state (after the above):



    And then again switching effects:


    Code
    2022-09-22T19:47:53.159Z [MUXER|First LED Hardware instance] (ERROR) Previous line repeats 200 times
    2022-09-22T19:47:54.655Z [MUXER|First LED Hardware instance] (ERROR) Previous line repeats 99 times
    2022-09-22T19:47:54.655Z [EFFECTENGINE|First LED Hardware instance] (INFO) Run effect "Fire" on channel 128
    2022-09-22T19:47:54.655Z [EFFECTENGINE|First LED Hardware instance] (DEBUG) (EffectEngine.cpp:206:runEffectScript()) Start the effect: name [Fire]
    2022-09-22T19:47:54.655Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Reuse input 'Home Assistant@::ffff:192.168.1.4/EFFECT' (Fire) with priority 128
    2022-09-22T19:47:54.682Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:422:updatePriorities()) Set visible priority to 128
    2022-09-22T19:47:55.180Z [EFFECTENGINE|First LED Hardware instance] (INFO) Effect [Breath] finished


    Here the effect runs normally again.


    Thank you very much for the help so far, let me know if there's anything else I can do.

    Lord-Grey


    Yes, it's running:


    Version2.0.14-beta.1
    Buildmaster (LordGrey-525e3537/9d23d9e2-1662531133)
    Build dateSep 21 2022 18:47:16


    Right now I'm running Home Assistant Core 2022.9.6 but I had the same issue in earlier versions. I ran a super old version when this issue started alongside Hyperion 2.0.0-alpha.9 which worked fine before I moved (if it ain't broke, don't fix it and all that). I'll try downgrading to 2022.8.6 and report back.


    Followup: did not make a difference unfortunately.

    The problematic transition is from (any) effect to platform capture and back. When platform capture is triggered from HA it tries to clear the source from Hyperion and only leaves:


    SystemCapture Screen: (Dispmanx)250Select Source


    This interaction works without issues when using a solid colour but not when using effects it seems. Looks to me like it isn't cleared properly in the latter case. But this may be an issue with the HA integration rather than Hyperion, I'm not qualified to assess that.


    Looking through the source it seems that there is some workaround in place for clearing effects.

    Thank you very much :) That went way over my head so I just used your tar.


    Unfortunately I still run into the same issue. I just tested solid colours instead of effects due to what you thought the issue was and that seems to work without issues (i.e. properly transitions between solid colour and platform capture on playback start/stop in my case) or inconsistencies.


    I also dug deeper into the HA logs and found that it sometimes throws the following error when using effects:


    WARNING (MainThread) [hyperion.client] Failed Hyperion (192.168.1.3:19444) command: {'command': 'clear', 'error': 'Errors during specific message validation, please consult the Hyperion Log', 'success': False, 'tan': 0}


    Looking at the Remote Control section of Hyperion there are a lot of weird things going on when using effects in the automations. Sometimes there is no change at all (effect still present and active), sometimes Origin and Type fields are empty while Priority remains and source is still active (blocking platform capture due to higher priority), sometimes it's properly cleared and works as intended and sometimes LED output is turned off completely.

    Lord-Grey That looks promising :) How would I go about testing this fix, I'm guessing building from source? I'm using Hyperion on a RPi3B running LibreELEC which complicates things a bit and I'm not very good at these things unfortunately.


    I tried cross compiling for Buster using WSL2 and the provided Docker script but unfortunately it fails halfway through with the following error:



    Building for Bullseye worked but I don't think those files are compatible with LibreELEC 9.2.8, I will try though.

    This is a bit of a weird one. I've had 2.0.0-alpha.9 up and running for a long time controlled by HomeAssistant automations (using Kodi and time triggers) and it's been working flawlessly.


    Now after moving I ran into issues, without changing any software, where calls from HA automations only work about 50% of the time. I've updated to 2.0.13 and latest HA but the same issue remains.


    The problem seems to be that priority handling is very inconsistent and the HA source randomly getting removed for no apparent reason. For example I have an automation that turns screen capture on when starting playback in Kodi and then turns on an effect on stop. This is what happens when starting playback:


    Code
    2022-09-20T20:16:50.582Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:359:updatePriorities()) Removed source priority 128
    2022-09-20T20:16:50.582Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:422:updatePriorities()) Set visible priority to 250
    2022-09-20T20:16:50.583Z [SMOOTHING|First LED Hardware instance] (DEBUG) (LinearColorSmoothing.cpp:683:selectConfig()) [0] - type: Linear, pause: false, settlingTime: 100ms, interval: 25ms (40Hz), delay: 0 frames
    2022-09-20T20:16:50.792Z [EFFECTENGINE|First LED Hardware instance] (INFO) Effect [Sea waves] finished


    Source priority 128 is set in HomeAssistant (in this case Sea waves was running before starting playback).


    On stop (when it works as intended):


    Code
    2022-09-20T20:14:12.362Z [EFFECTENGINE|First LED Hardware instance] (INFO) Run effect "Sea waves" on channel 128
    2022-09-20T20:14:12.362Z [EFFECTENGINE|First LED Hardware instance] (DEBUG) (EffectEngine.cpp:206:runEffectScript()) Start the effect: name [Sea waves]
    2022-09-20T20:14:12.362Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Reuse input 'Home Assistant@::ffff:192.168.1.4/EFFECT' (Sea waves) with priority 128
    2022-09-20T20:14:12.583Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:422:updatePriorities()) Set visible priority to 128
    2022-09-20T20:14:12.584Z [SMOOTHING|First LED Hardware instance] (DEBUG) (LinearColorSmoothing.cpp:683:selectConfig()) [6] - type: Linear, pause: false, settlingTime: 200ms, interval: 40ms (25Hz), delay: 0 frames


    Here the effect is restarted again on stop and everything works as expected. But now about 50% of the time instead I get:

    Code
    2022-09-20T20:12:58.536Z [EFFECTENGINE|First LED Hardware instance] (INFO) Run effect "Sea waves" on channel 128
    2022-09-20T20:12:58.536Z [EFFECTENGINE|First LED Hardware instance] (DEBUG) (EffectEngine.cpp:206:runEffectScript()) Start the effect: name [Sea waves]
    2022-09-20T20:12:58.536Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:182:registerInput()) Reuse input 'Home Assistant@::ffff:192.168.1.4/EFFECT' (Sea waves) with priority 128
    2022-09-20T20:12:58.582Z [MUXER|First LED Hardware instance] (DEBUG) (PriorityMuxer.cpp:359:updatePriorities()) Removed source priority 128


    Here the source is immediately removed again and I have no idea why. It seems completely random.

    Hi,


    I have the same problem concerning near dark scenes with flickering LEDs. Can't get rid of this behavior. I think the better option would be a percentage under which LED stays off.


    Agreed, I would also much rather have a setting like this. Seems like it would be an easy fix to have a threshold value under which the LEDs stay completely off. I also wonder if it would be possible to have several points of gamma correction instead of just one. Just two would be much better I imagine, one for low light conditions and one for bright.


    if you adjust backlight treshold to 4 and colour tresholds to 10 it should help already.
    also boosting gamma values to 2.5 each channel.


    thats how i set it.
    i post some settings of my setup


    It seems these values are only available when using a hardware grabber? There's no such settings for platform capture, at least not in the web config. I wonder if it would be worth getting a hardware grabber just for this. The backlight threshold option seems to be "inverted" from what I'm looking for; it adds a minimum brightness level instead of ignoring values below the threshold. Cranking gamma kind of works, but you still get the flicker when the LEDs are turning on. This effectively "moves" the issue to slightly brighter scenes. Even if this is slightly less distracting, for me I feel like cranking gamma takes away more from the overall experience than the flickering in dark scenes does.

    My setup is the following:


    RPi3B running LibreELEC 9.2.6 and Hyperion-ng 2.0.0-alpha.9 (dispmanx platform capture)
    Arduino Nano w. adalight sketch
    WS2812B LEDs


    I've spent quite a bit of time calibrating and I would say I'm about 80-90% happy with medium bright to bright scenes. I don't think it's going to get much better with these LEDs. Fully dark (black) background scenes with defined light sources are OK but what I can't figure out how to fix is dark, low contrast scenes with a lot of near black colours. I get a lot of "threshold" flickering (which smoothing doesn't seem to be able to get rid off) and very inaccurate colours here. Often very saturated green on brownish colours and saturated blue on dark grey, for example.


    I can't seem to get rid of these "artifacts" no matter how much I tweak gamma and brightness settings and they are very distracting. Do I need to change something in my hardware setup to fix this or is it possible to fix with calibration? I would rather the LEDs stayed off completely under a certain threshold but there doesn't seem to be such a value? Only way seems to be to crank the gamma values up or cut the brightness massively but this causes all sorts of different issues and lower quality experience overall. Can't seem to find a balance here.


    The second thing I'm having an issue with is blackbar detection. As of now I'm using the letterbox mode and while it works very well for detecting black bars, the issue is that on static scenes it seems to keep going indefinitely until it finds a light source. So if a scene is "static" for more than a second or two, it will set a ridiculous blackbar and LEDs can go from fully off to very bright in the middle of such a static scene and it's super distracting.


    I have tried setting "Inconsistent frames" to extremely high values but it doesn't seem to make a difference. Maybe I'm not understanding what this value does? I've also tried all the different detection modes but they seem to behave more or less the same in regards to this particular issue.