Question: running kodi with detachable output as system service

[Uatschitchun]

Hi, I've got a question and am misusing the issues on that, hope you don't mind!

Atm I've got a docker running a kodi headless for serving as centralized kodi to sync the library and to serve as main instance for yatse on a headless server. So far so good.

What I'm trying to achieve now is to have kodi running with "suspended" head (like with xpra) from a docker container started on system startup without the need to be logged in. So it mainly is like I have it now.

Right now I'm not able to get audio output and configuration of kodi is tricky as there is no UI, but only config files and web-ui.

So if I would use x11docker (tested it with xpra) I get sound and am able to attach and detach the "head" from localhost or via ssh.
That setup was a little unstable and xpra doesn't clean up nicely if quit (port already in use). I used your xpra via ssh example from the wiki.

So now my question:
What would the best way to realize such a setup?
Guess xpra or nxagent are the way to go or are there other/better solutions?
The server is able to provide gpu acceleration (i965), so it would be nice to render the head in hardware.
What would a systemd unit would look like?

As my server has got a monitor now...
If that kind of setup would work, I have the central kodi instance for maintenance starting on system startup, just like the headless docker is now, but with attacheable UI if I log in on the desktop, am able to play audio on the server from a remote app like yatse without the need to be logged in and it would only need a xpra client for to have the UI on every PC via ssh.

Any tips on a setup like this would be awesome!

[mviereck]

Hi, I've got a question and am misusing the issues on that, hope you don't mind!

I am happy to help, and this is the right place for questions.

So if I would use x11docker (tested it with xpra) I get sound and am able to attach and detach the "head" from localhost or via ssh.
That setup was a little unstable and xpra doesn't clean up nicely if quit (port already in use). I used your xpra via ssh example from the wiki.

This sounds like you basically got what you want, but some issues remain. Can you explain further what has been wrong?
You could show me the commands you have used and the error messages you got.

The server is able to provide gpu acceleration (i965), so it would be nice to render the head in hardware.

That might be a bit tricky, but should work. Is the monitor always attached to the server?

What would a systemd unit would look like?

What exactly do you want to achieve? If it is only an autostart of x11docker on boot, I would just create a regular script setting up x11docker and xpra server, and run it from /etc/rc.local.
A real systemd unit should be possible, too. I have to think about how to set it up.
Basically it would do the same: Just run a script like rc.local would do.
Something like this might work:

[Unit]
Description=x11docker start service 
Wants=multi-user.target
After=systemd-user-sessions.service
After=rc-local.service getty-pre.target
Before=getty.target
[Service]
ExecStart=/usr/local/bin/x11docker-kodi
[Install]
WantedBy=getty.target
WantedBy=multi-user.target

[Edit:] You can store it as /etc/systemd/system/x11docker-kodi.service and enable it with systemctl enable x11docker-kodi. To test it immediatly: systemctl start x11docker-kodi. To check its status: systemctl status x11docker-kodi.
/usr/local/bin/x11docker-kodi would be an executeable script that sets up x11docker and xpra (chmod +x /usr/local/bin/x11docker-kodi).
Note that I am not an expert in systemd services and that this unit probably is not the best possible one. It likely works for --xvfb or --xdummy, but might fail with GPU setups using --xorg.

If that kind of setup would work, I have the central kodi instance for maintenance starting on system startup, just like the headless docker is now, but with attacheable UI if I log in on the desktop, am able to play audio on the server from a remote app like yatse without the need to be logged in and it would only need a xpra client for to have the UI on every PC via ssh.

I am not entirely sure if I understand right. However, I see one problem:

• For GPU acceleration x11docker must claim the GPU and the monitor. In that case, you cannot log in later and run a desktop. Though, you could switch to another tty, log in there and run a desktop. But the X server with kodi would be frozen meanwhile and could not be used. Attaching with xpra would likely fail. The reason is that only one X server at a time can claim the GPU and must release it on tty switch.
• Without GPU acceleration x11docker can run an invisible X server and could run entirely in background. You can log in, run a desktop and attach with xpra.

Edit: a general recommendation: If you encounter issues with xpra, install xpra from www.xpra.org. The distribution packages are often out of date and have heir own issues.

[Uatschitchun]

I'm trying different containers atm to see which one would be appropriate for my needs.
I'll report back!

[mviereck]

Have a look at https://github.com/ehough/docker-kodi

[mviereck]

I just found an interesting systemd unit example at ehough/docker-kodi#29:

[Unit]
Description=Dockerized Kodi
Requires=docker.service
After=network.target docker.service

[Service]
# Pulling the docker image before every service startup is not required as we've already pulled the image once. This also allows to fix the kodi-docker version, but also avoids that updates are pulled automatically.
#ExecStartPre=/usr/bin/docker pull erichough/kodi
ExecStart=/usr/bin/x11docker --xorg --pulseaudio erichough/kodi
# I've decided to disable the restart option as long as I need to make changes to the service as kodi will always restart when you try exit it. You can enable this option if you got everything set up.
#Restart=always
KillMode=process

[Install]
WantedBy=multi-user.target

[Uatschitchun]

Hi, sorry for not reporting back...

I gave up :-)
I couldn't get it to work reliably...

My idea of starting kodi with an xpra instance that one is able to connect to if wanted didn't work well.
The other idea, having kodi running headless (compiled with headless patch) even didn't work out, as I wasn't able to get a pulseaudio device within docker that kodi recognizes.
My idea with the headless kodi was to have it output audio to a pulseaudio fifo and install a snapcast server into the container as well that reads the fifo and sends out a network stream.

Don't know, maybe my knowledge and experience with creating docker containers is lacking the needed expertise or/and kodi is just a diva... :-)

Nevertheless, if there's someone who is liking my idea of either solution (a container running kodi with a detachable head or a headless kodi with snapcast server), I'm willing to take it further...

[mviereck]

Thanks for reporting back!

If you want to give it another try, you could show me what you did and tell me what fails. Maybe I would have an idea.

[Uatschitchun]

In regards to running kodi-headless, I took linuxserver/kodi-headless as a base, installed pulseaudio in the container and changed the build instructions to enable pulseaudio for kodi.
Problem is, kodi needs to find audio "hardware" (alsa or pulseaudio), but I couldn't get the container to provide audio for itself. Even with providing pulseaudio from the host, kodi did not find any audio ;(

So my idea was to setup kodi-headless in the container, provide a "virtual" audio-out within kodi is able to find and connect that to a snapcast-server, so it's only one or 2 ports more to open for snapcast, no fiddling around with pulseaudio from the host and being able to setup s snapcast-client on the host or somewhere else...

[Uatschitchun]

Ah, just found this one:
https://superuser.com/questions/1223118/emulating-microphone-input-to-chrome-inside-docker-container

[Uatschitchun]

To resume:
2 options:
A) running kodi against a virtual output, like xpra, with local audio or snapcast
B) run kodi headless together with local audio or snapcast

Just to clarify :-)

A) has the advantage of easier configuration as there's a head available, if needed, even throughout the local network
B) has the advantage of being less resource intensive

[mviereck]

https://github.com/ehough/docker-kodi is known to work well with ALSA and/or pulseaudio.
You could check with this if sound works.

If you have issues with xpra, use the latest version from www.xpra.org. The xpra packages shipped with the distributions can have issues.

Edit:
I recommend to begin with a simplified but working setup. Than extend and change it towards your desired goal step by step. If an issue occurs in one step, we debug and fix it. Than we go one step further.
For example, start with x11docker --pulseaudio erichough/kodi and check if sound works.

[mviereck]

Closing due to inactivity.
If you want to go step by step, I am happy to help.