[SOLVED] Hyperion.NG on Docker Hub for arm/Raspberry Pi

Hukuma1 commented 4 years ago

Feature request

I know there's containers for actually compiling/cross-compiling Hyperion.NG (https://hub.docker.com/u/hyperionproject), but can this official repository also please provide the current alpha releases for multiple platforms as well? There's a few (outdated) non-official Docker containers with Hyperion.NG out there, but not for all platforms. Currently there's no Raspberry Pi arm version for instance.

What problem does this feature solve?

Super easy installation for anyone running VM/RPi Hyperion setups.

What does the proposed API look like?

N/A

How should this be implemented in your opinion?

Official HyperionNG repo to add containers for all platforms of current pre-releases?

Are you willing to work on this yourself?

Yes, but I'm not a coder. Am able to happily test any RPi arm7 containers.

Paulchen-Panther commented 4 years ago

Do I get the question wrong? Screenshot

Hukuma1 commented 4 years ago

Hi. First off, big fan of the project so thank you and keep up the great work!

To clarify, yes, I am not talking about the actual releases that are now being compiled. This is a step further. For people using Docker Containers, it would essentially be a container with that release already installed.

An example of what I'm talking about is here: https://hub.docker.com/r/sirfragalot/hyperion.ng

However the issues with the above repository are: 1) it's outdated, so it's using a compiled version from source code of 3 months ago and 2) will only work on OS/ARCH linux/amd64. So people with Raspberry Pi's will not be able to use this Docker Container for example.

Edit: Just looked through the Docker Compose file and it seems to pull latest code possibly. But the issue of it not working on different arch stands. :(

Paulchen-Panther commented 4 years ago

Now I understand your question. :-) Hyperion analyzes the screen content, which is not possible or only possible to a limited extent in a Docker container. This is the reason why we do not deliver finished Docker containers with Hyperion.

That our Docker containers (for the production of our releases) are not up to date, is because we want to be backwards compatible. The releases have the necessary dependencies, which enables execution on upward systems.

Hukuma1 commented 4 years ago

Maybe I'm confusing myself and you at the same time. Does that mean the above docker hub by SirFragalot would not have a working hyperion executable for AMD64 systems? :(

Sorry just got exposed to Docker Containers and have everything running in one now. Home Assistant, Pi-Hole, etc. Wanted to add Hyperion NG to the stack. Is this something that may be possible later or a limitation of containers and screen capture? Could it work with elevated privileges or anything?

Paulchen-Panther commented 4 years ago

Does that mean the above docker hub by SirFragalot would not have a working hyperion executable for AMD64 systems? :(

It's already running. I only doubt that this Docker container can pick up the screen signal and forward it to Hyperion.

Is this something that may be possible later or a limitation of containers and screen capture?

Unfortunately it is limited to get signals from the host system in the Docker container

Could it work with elevated privileges or anything?

I do not think so

Shawn9347 commented 4 years ago

Hello,

I have a question about the releases. When I extract the file and run it on my coreelec device it doesn't say v2.0.0 alpha 4. It just says v2.0.0. Can you explain me why this is? I tried compiling my own tar.gz for amlogic but it still doesn't work.

Thanks in advance.

EDIT: I also don't have the latest features so it's actually a different version. No idea which one though just says 2.0.0

RickDB commented 4 years ago

Agree with @Paulchen-Panther that a docker wouldn't really work due to the nature of screen capture in general as that needs direct tie-ins with display and access to LEDS via SPI / USB serial.

It will work for some cases like AtmoOrb where you only need to receive and send TCP/UDP commands but we couldn't maintain a docker image just for those as it would create confusion for sure :)

For the CoreElec issue would create a separate Github issue so devs can have a look.

Hukuma1 commented 4 years ago

It will work for some cases like AtmoOrb where you only need to receive and send TCP/UDP commands but we couldn't maintain a docker image just for those as it would create confusion for sure :)

Now it makes sense! Thank you.

I am using a great utility for Android TV (https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber) which captures the screen and sends data to Hyperion. In my use case Hyperion would work just fine in a Docker since it does not grab the screen itself, correct?

Anyway, keep up the great work in Hyperion.NG! Really takes media to another level.

RickDB commented 4 years ago

I am using a great utility for Android TV (https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber) which captures the screen and sends data to Hyperion. In my use case Hyperion would work just fine in a Docker since it does not grab the screen itself, correct?

It would still need something that connects to the LEDs. That can be via Serial interface (COM port) as Docker can forward that to the container, not sure about performance though as there will be an added layer.

Hukuma1 commented 4 years ago

My setup is: Android TV -> Arduino Nano -> RPi4 -> Hyperion.NG

Would running HNG in Docker work for this scenario? Guess I could always try and see but I haven't fully learned how to create a Docker container yet. D:

I know it ran beautifully and fast directly off the RPi4 (no Docker).

RickDB commented 4 years ago

If the Arduino Nano is the one driving the leds and its connected to the RPi4 via USB that should work, you need to lookup the /dev/ttyXX serial device and forward that to the docker container:

https://stackoverflow.com/questions/24225647/docker-a-way-to-give-access-to-a-host-usb-or-serial-device

Then again running in natively on the RPi4 would probably be easier though unless you are gonna use the RPi4 for different applications which docker is great for.

Side note:

Recently went full Linux for my home server and 95% of my server applications run in Docker containers, manage everything with Portainer (web based Docker "interface") and can highly recommend that one as it beats tinkering with CLI commands :)

Docker has a very bright future and makes for easy managing of just about everything you can think off so it's worth investing time into for sure.

Hukuma1 commented 4 years ago

Recently went full Linux for my home server and 95% of my server applications run in Docker containers, manage everything with Portainer (web based Docker "interface") and can highly recommend that one as it beats tinkering with CLI commands :)

Docker has a very bright future and makes for easy managing of just about everything you can think off so it's worth investing time into for sure.

Yep! Exactly got this right now. DietPi + Home Assistant + Portainer = unlimited possibilities.

So this is why I was hoping someone could create a Docker container for Hyperion.NG. The few I found were not for arm architecture.

RickDB commented 4 years ago

Too bad this one didn't publish the source code as that way we could try and run a test build on an ARM device:

https://hub.docker.com/r/sirfragalot/hyperion.ng

However you could mail him and ask to compile an image on a Raspberry or publish the Docker code to Github at least:

LABEL MAINTAINER=jonwilliams84@gmail.com DESCRIPTION=Docker container for Hyperion-NG IMAGENAME=hyperion.ng OS=linux VERSION=0.1.0

Hukuma1 commented 4 years ago

https://hub.docker.com/layers/sirfragalot/hyperion.ng/0.1.0/images/sha256-c11bd96d1799ff631f1dcbffd2e9c5af7947b6e561cff7bffee87eacfcd26db6?context=explore

Does this show us the code? It's the makeup of the file.

RickDB commented 4 years ago

Partially yes, missing a few definitions but in theory can reverse engineer it off that. Here's an example of valid DockerFile:

https://github.com/RickDB/Docker-PlexAniSync/blob/master/Dockerfile

bradsjm commented 4 years ago

This is a very simple Dockerfile for the PI if no local system is needed (e.g. using network video capture and WLED etc.)

FROM balenalib/raspberrypi3:run

RUN install_packages \
    libpython3.5 \
    libjpeg62-turbo \
    libavahi-compat-libdnssd1 \
    libdbus-1-3 \
    libqt5sql5 \
    libqt5serialport5 \
    libqt5network5 \
    libqt5widgets5 \
    libqt5gui5 \
    libqt5core5a

ENV RELEASE 2.0.0-alpha.5/Hyperion-2.0.0-alpha.5-Linux-armv7hf-rpi

RUN curl -fsSL https://github.com/hyperion-project/hyperion.ng/releases/download/${RELEASE}.deb > /tmp/hyperion.deb && dpkg -i /tmp/hyperion.deb && rm -f /tmp/hyperion.deb

EXPOSE 8090 8091 19333 19400 19445
VOLUME /config

CMD hyperiond -u /config

Build with: docker build -t hyperion.ng .

Run with: docker run -d -v /path/on/host:/config --network host hyperion.ng

Hukuma1 commented 4 years ago

Thank you very much for this, @bradsjm!

Edit: It works! I got accustomed to using bridge mode for networking in Portainer. Had to switch it to host like your example shows. For anyone else reading this later, make sure to set message priority from 250 (default) in Hyperion grabber setting to 100-199 range and make it match in the Hyperion Android Grabber app.

Hukuma1 commented 3 years ago

FROM balenalib/raspberrypi3:run

RUN install_packages \
    libpython3.5 \
    libjpeg62-turbo \
    libavahi-compat-libdnssd1 \
    libdbus-1-3 \
    libqt5sql5 \
    libqt5serialport5 \
    libqt5network5 \
    libqt5widgets5 \
    libqt5gui5 \
    libqt5core5a

ENV RELEASE 2.0.0-alpha.7/Hyperion-2.0.0-alpha.7-Linux-armv7l

RUN curl -fsSL https://github.com/hyperion-project/hyperion.ng/releases/download/${RELEASE}.deb > /tmp/hyperion.deb && dpkg -i /tmp/hyperion.deb && rm -f /tmp/hyperion.deb

EXPOSE 8090 8091 19333 19400 19445
VOLUME /config

CMD hyperiond -u /config

Trying to run new container with updated alpha 7 build and get an error "cannot read property 'url' of undefined". Any ideas why? I only changed the env from alpha 5 to alpha 7 in the above code. Thanks in advance, @bradsjm!

Hukuma1 commented 3 years ago

Nevermind. Looks to be a Portainer bug with Home Assistant. Probably works just fine once it gets fixed. Sorry for the commotion. :) Will leave this here in case anyone has similar issues. https://github.com/portainer/portainer/issues/4125

Lord-Grey commented 3 years ago

@Hukuma1 I assume you get the error from hyperion's UI,correct? I suggest you remove cookies and remove the browser cache.

panec commented 3 years ago

Had anyone had any problems with exposed ports? While the 8090 works fine, the 19333 19400 19445 cannot be accessed at all (tested from an android phone using Android grabber & Hyperion app)?

panec commented 3 years ago

I still have no clue why it is not working. This is a netstat from the running container with hyperion.ng

root@dba1ceb5-hyperion:/# netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.11:40097        0.0.0.0:*               LISTEN      -                   
tcp        0      0 172.30.33.5:40174       151.101.0.204:80        TIME_WAIT   -                   
tcp        0      0 172.30.33.5:37554       151.101.62.132:80       TIME_WAIT   -                   
tcp        0      0 172.30.33.5:37524       151.101.62.132:80       TIME_WAIT   -                   
tcp6       0      0 :::19400                :::*                    LISTEN      196/hyperiond       
tcp6       0      0 :::19444                :::*                    LISTEN      196/hyperiond       
tcp6       0      0 :::19445                :::*                    LISTEN      196/hyperiond       
tcp6       0      0 :::8090                 :::*                    LISTEN      196/hyperiond       
tcp6       0      0 :::8092                 :::*                    LISTEN      196/hyperiond       
tcp6       0      0 172.30.33.5:8090        192.168.1.110:61592     ESTABLISHED 196/hyperiond       
tcp6       0      0 172.30.33.5:19444       192.168.1.75:51028      ESTABLISHED 196/hyperiond       
tcp6       0      0 172.30.33.5:8090        192.168.1.110:61587     ESTABLISHED 196/hyperiond       
tcp6       0      0 172.30.33.5:8090        192.168.1.110:61586     ESTABLISHED 196/hyperiond       
tcp6       0      0 172.30.33.5:8090        192.168.1.110:61585     ESTABLISHED 196/hyperiond

172.30.33.5 - is hassio IP address 192.168.1.75 - is host machine IP address 192.168.1.110 - is the address of the PC from which I access the web GUI

Any suggestions why I cannot connect to 19444 or 19445?

BurninTurtles commented 3 years ago

I just want to throw this out there. I was able to get some dockerfile (I wish I could find it again) for this running and by docker-compose by using the below elements in the compose file. So a docker setup is totally possible.

Devices: /dev/video0:/dev/video0 /dev/spidev0.0:/dev/spidev0.0 /dev/spidev0.1:/dev/spidev0.1

my only issues were related to my capture device at video0 which I'm 95% sure are an artifact of my setup and cheap hardware. I recently rebuilt my pi and neglected to make a backup, so I will update this once I find the dockerfile I used.

Tatoo974 commented 2 years ago

hi, i have a pi4 with home assistant on docker. i have installed portainer . i have tried to install hyperion with the dockerfile above but that didn't work... i'm not used with docker. Could someone help me in my setup ? Thanks

hyperion-project / hyperion.ng