Posts by bnealon

    I have made a few changes. Can this deb file be installed without errors?

    @Paulchen-Panther thanks very much for the build, doesnt seem to have changed much sadly :o(

    I made a fresh install of Raspbian Buster, then SSH'd in from another machine as the default user 'Pi' and this was the first thing i did after that:

    Heres my download and install output:

    I then restarted the service, and here's the logs. It appears to keep cycling the service due to a failure for user `pix0apix0api`, is this user correct?


    What kind of RPi do you use?

    3 model b+

    Is it a mistake that the service references the pi user twice? I’m SSH’d into the RPi btw when im installing, as the default user ‘pi’. Im not too familiar with services taking usernames in, if i run without a user it complains also.

    @Paulchen-Panther i wondered if you could help me out please?

    I've just made a install of raspbian buster on my rpi, compiled latest with your buster image:
    `wget -qN…scripts/ && chmod +x *.sh && ./ -t rpi-raspbian-buster`

    Then from within the deploy directory i ran:
    `sudo dpkg -i Hyperion.NG-Beta.1.0.0-Linux-rpi.deb`

    I get the following output:

    As instructed i then run:
    `systemctl status hyperiond@pi\x0api\x0api.service`

    and i get:

    If i restart the service and tail the logs i get:

    Any idea what i am doing wrong?
    How come the service is now called 'hyperiond@pi\x0api\x0api.service` whereas when i built this back in march this year, it was only `hyperiond@pi\x0api.service`?
    I control my hyperion setup using ssh commands to start/stop the service, so it would be perfect if you knew what the correct commands to start/stop are.

    Do i need to install a config somewhere for this to start maybe?

    Thank you!

    Does anyone have a fully functional solution to this problem yet? I've already got a HDMI 1.4 -> CVBS splitter, which goes into a video grabber, then into my Pi running
    I thought i'd found the ideal solution to this problem, which was a 4K HDR splitter/downscaler combo box from clearvisionsystems over in the UK (https://www.clearvisionsystems…er-18gbps-hdr-4k-1in-2out). The little box proved perfect, ideal infact, and i could connect this onto the output of my Onkyo amplifier, and split the signal into my 4k Samsung TV, and the other side downscaled into my HDMI->CVBS device.

    However, I've sadly had to return this: as there was what appears to be an incompatibility with my Onkyo amplifier which caused corruption to intermittently appear on my TV output (YMMV). clearvisionsystems were superb, and i highly recommend them - they sent a replacement to me initially as we thought it was possibly a faulty box, but the problem persisted :o(

    Anyway, like everyone else in here i'm looking for the holy grail: a HDCP 2.2 compliant downscaler/splitter that will allow my UHD 4k HDR TV signal to pass through to my TV, and then downscale this to HDMI 1.4 spec (1080p signal ideally) to be passed through to hyperion.
    The only other issue i noticed with the device from clearvisionsystems, was that the 1080p downscaled signal still contained HDR colour space, so the colours were washed out (again another topic discussed in here).

    Currently im considering a Lightberry HDMI kit 5, but wondered if anyone else had alternatives from elsewhere that solve this problem? Ideally i would like the ability to return if my problem isnt solved, and im not sure whether lightberry would accept returns unlike amazon etc...

    if you install with `apt-get install <file-name-here>.deb` that should do it. It will assess your dependencies and if they need updating let you know.

    Incase you're not aware, docker allows a specific virtual-environment to persist, in the case of compiling, they allow the developers to specify the exact dependencies and requirements needed to compile the code. Called containers, they are loaded into docker and the compilation is executed within the virtual container, once compiled, the artifacts (binaries etc..) are exctracted back out onto your host machine (rpi in your instance).

    I'm using a mac, and didn't want to compile on my rpi as it can take a while, so for me - i used a lightweight virtualbox VM for Ubuntu 16.04 (one of the suggested compatible OS's for compilation), ssh'd into the virtual machine, installed docker-ce (command line version) using this guide:…se-docker-on-ubuntu-16-04

    I then ran the cross-compile for rpi command from the compile instructions above. then once that was finished SFTP'd into my RPI (running raspbian stretch), copied ONLY the .deb, and installed using the apt-get command from above.

    Hyperion is then installed as a service, it auto starts on boot, and you can restart/stop etc.. via service commands.
    Hopefully this helps, or if not helps someone else!

    @Braulio when i compiled mine, one of the artifacts in the /deploy directory was a .deb, which is a debian RPM, installing this will do everything you need. It deploys the code in the correct directories, along with adding the correct services you require. I would highly recommend, unless you need to manually compile the code - installing docker and running the command in the compile instructions, its super simple and 'just works'. :)

    @b1rdhous3 this might sound really stupid, but where are the logs for hyperion and on raspbian stretch? I'm trying to tail the logs for another issue, the wiki just talks about using hypercon, but i cant use that for

    Just for confirmation now that this is resolved, I'm using the same hardware and configuration values for my v4l2 configuration, therefore the sizeDecimation value of 8 is perfectly fine, as since the code internally doesnt look to be blurring on downsample, just removing some of the pixels - everything seems to work just as well with a value of 8 OR 2, and therefore the overall colours from the grabber are unadjusted.

    Just a quick update, this issue does not exist on the latest compiled version of Apart from the outstanding issue of switchOffOnBlack=true not working, the colours and functionality .ng provides is a vast improvement over the current version of Hyperion.
    I gather than the issue i was seeing could be fixed with calibration, however with .ng i do not need to calibrate the colours of the bulbs as they work perfectly.

    if you're a smart phone user, your could create and save 2 ssh commands:

    sudo systemctl start hyperion.service


    sudo systemctl stop hyperion.service

    Im on iOS and use the native 'shortcuts' app to do just this, i then have these SSH scripts set as two widgets on my smartphone that are quick to access.

    having recently compiled myself as a first-timer, my best advice would be to use the docker container method, as this has all of the necessary environment setup you require, including all dependencies.

    Install docker-ci using the instructions from their website and go from there. I didn't compile on the Pi however, i used a VM with Ubuntu 16.04 and cross compiled for Pi. Afterwards, i just FTP'd onto the Pi and copied the .deb file and then installed using apt-get :)

    I might have spotted a possible cause, but i've currently not got the correct tool chain to change and test, would someone else be able to maybe try?

    The theory here is that Turning the light off, then changing the colour presumably will turn it back on?

    LedDevicePhilipsHue.cpp (Current code)

    LedDevicePhilipsHue.cpp (proposal)

    Hiya Guys,

    Resurrecting this old thread as i've just move from Hyperion -> with my Hue Colour bulbs i am seeing the same issue as OP.
    `switchOffOnBlack` works really well on Hyperion, but the functionality appears broken on, my lights just go really dim and never ever turn off on black screens. I'm using a vl42 USB input, with 4 Hue Colour bulbs, which otherwise work perfectly in both versions of Hyperion.

    I've been looking through the code and there was a recent change (after OP's original post) which fixes something to do with brightness, but the version i am running contains this and i'm still seeing issue.…1d3bd69c0d9504b08590a53c0

    Can anyone confirm if this is an issue with my setup or the code please?

    After using, it has so many nice improvements over Hyperion that i'd like to not have to go back.

    My config is as follows:



    I'm running Hyperion on a Raspberry Pi 3 B+ running raspbian-stretch with 4 philips hue bulbs in my living room (one in each corner of the room). I don't have any LED's around the screen at the moment, and have been trying to configure Hyperion to produce a nice subtle ambient affect, without flickering and sporadic changes in colour.

    I'm fairly happy with my config, and have had to introduce smoothing (suggested workaround) for the open issue HERE.

    The only issue i continue to have is during low light scenes, where the lights are getting close to turning off - the lights get sent either a bright blue or red colour (colour depends on the nature of the video input). I spent a while testing my setup with Game of Thrones last night, re-playing certain tricky scenes to fine tune my config. Whenever there is a low light scene with candlelight, or yellow light/skin tone the hue bulbs will glow red. I managed to capture a screenshot from the USB videograbber and the video signal is perfect, has no visual red present and i would expect the lights to turn more yellow than red here:

    Alternatively, any of the GOT scenes that have snow in tend to turn to blue before turning off.

    Is this a known issue, or is there a workaround?

    I spent a while experimenting with both the, along with the blackborderdetector.threshold values. I've also followed the blackborderdetector.threshold tutorial by using a colour picker on the screengrab to get the correct value, which gave me ~8% and still did not fully correct the issue.




    OK, i didn't realise when HyperCon does its video grab: it uses different frameDecimation/sizeDecimation values than the default 2/8. Therefore when i have the strange red/blue lighting, and i've been grabbing the USB grabber through HyperCon - that Hyperion will actually be seeing a different resultant image, i'm assuming the image will be considerably reduced down and colours averaged out - which might explain what i'm seeing. Hyperion uses barely any CPU on my Pi ~1%, are there any better values to use here instead?
    How can i manually obtain the same image that Hyperion will see with my current vl42 settings? ssh command?


    If i was to use a 4k HDR scaler to produce 1080p output, What expectations should i have around an SDR vs HDR signal, should the output video signal contain the same same colour palette - and therefore the scaler is just omitting the HDR meta, or does the HDR video signal need some sort of conversion to reduce the colour space. I've seen other posts with washed out colours and not sure if this is something that can be fixed.