docker-kodi

docker-kodi copied to clipboard

You could develop some sort of GUI, for example with dialog on a terminal base, or with x11docker/kaptain on a GUI base.

Unpolished example:

Code for this example:

#! /bin/bash

echo '#! /usr/bin/kaptain
start "Configure erichough/kodi-standalone" -> mainframe buttons;

  mainframe:framed -> tag kodihome kodishare options;
    tag "Choose kodi image" -> taglatest | tagalsa | tagkrypton | tagkryptonalsa;
      taglatest      "erichough/kodi:latest -> Pulseaudio and ALSA support"   -> "tag=latest " ;
      tagalsa        "erichough/kodi:alsa -> ALSA support (smaller image)"    -> "tag=alsa " ;
      tagkrypton     "erichough/kodi:krypton -> kodi krypton with pulseaudio and ALSA"  -> "tag=krypton " ;
      tagkryptonalsa "erichough/kodi:krypton-alsa -> kodi krypton with ALSA"            -> "tag=krypton-alsa " ;
      
    kodihome "Choose kodi home directory" -> "kodihome=\"" @directory="/YOURCOMPUTER'$HOME'" "\" ";
    
    kodishare "Additional directories to provide to kodi" -> sharedir1 sharedir2;
      sharedir1:beside -> "sharedir=\"" @directory="/YOURCOMPUTER'$HOME'/Videos" "\" " | ! "";
      sharedir2:beside -> "sharedir=\"" @directory="/YOURCOMPUTER'$HOME'/Music" "\" "  | ! "";
      
    options "Options" -> gpu ;
      gpu "GPU hardware acceleration" -> "gpu=yes" | "" ;
  
  configonly -> "configonly=yes " mainframe;
  buttons:beside -> @dump(mainframe)=" Run kodi now!" @dump(configonly)="Store config" @dump("cancel=yes")="Cancel" ;
' > $HOME/kodiconfig.kaptn

{ read -r containerID ; read -r kodioptions ; } < <(x11docker --hostdisplay --no-init --gpu --silent --stderr --stdout -- \
                                                   "--volume=$HOME/kodiconfig.kaptn:/kodiconfig.kaptn:ro --volume /:/YOURCOMPUTER:ro" \
                                                   x11docker/kaptain /kodiconfig.kaptn)

echo $kodioptions

Your kodi startup could than detect on itself if pulseaudio is running on host and decide whether to use --alsa or --pulseaudio. It could detect whether it runs on console or in X and decide whether to use --xorg or --weston-xwayland or --xephyr.

Only an idea to provide a simple plug&play interface for users, not a mandatory feature. :-)

This kaptain stuff is like wizardry! Quite impressive how it can create a GUI with such little code.

I like this idea of providing a helper script, GUI or otherwise, that can help users figure out the x11docker invocation that would work well on their system. I'll start to tinker. Really appreciate the inspiration and pseudo-code. Thanks!

It could detect whether it runs on console or in X and decide whether to use --xorg or --weston-xwayland or --xephyr

This is a little out of my area of expertise. Do you think that if I study x11docker's code I could learn ways to detect these environments? Any pointers would be appreciated.

Do you think that if I study x11docker's code I could learn ways to detect these environments? Any pointers would be appreciated.

You can look at #### part: check multiple option interferences begining at line 1746 where x11docker tries to autodetect the best available X server. But be warned: It is a quite confusing spaghetti part of the script. (At least there is no GOTO inside ... cough).

I'll open a new ticket #3 for possible X server options and their pitfalls and dependencies.

Thoughts for automated decision:

Sound: Check the output of pax11publish -d. If that is empty or fails, use --alsa. If it contains keyword Server:, use --pulseaudio.

X server: Check for availability of weston and Xwayland. If yes, use --weston-xwayland. Otherwise, check for environment variables DISPLAY and WAYLAND_DISPLAY. If empty, use --xorg. If DISPLAY is set, use --hostdisplay.

Wayland: If WAYLAND_DISPLAY is set, but DISPLAY is empty, best choice is --weston-xwayland. (Note: --fullscreen fails here, seems to be a weston issue). --xwayland is possible, but can look improper with panels. If none of this works, order the user to either install weston and Xwayland or to switch to console for --xorg.

GPU: Check for files /dev/nvidia*. If they exist, don't use --gpu, blame the user for using proprietary crap and recommend free nouveau driver. Otherwise: enable --gpu.

Thank you! I'll start digging in over the next few days.

Note to --gpu: You can enable it always. If hardware acceleration fails, software rendering will be used automatically. Latest x11docker master supports automated install of nvidia closed source drivers if the user provides the binary. x11docker gives instructions for this in terminal output if it detects closed source nvidia driver on host.

Latest x11docker master supports automated install of nvidia closed source drivers if the user provides the binary. x11docker gives instructions for this in terminal output if it detects closed source nvidia driver on host.

I recommend to install kmod and xz-utils in erichough/kodi. It significantly speeds up container startup if someone provides an nvidia installer to x11docker.

I recommend to install kmod and xz-utils in erichough/kodi. It significantly speeds up container startup if someone provides an nvidia installer to x11docker.

Interesting. Thanks for the tip! I looked through the source of x11docker and indeed see that kmod and xz-utils are needed for the closed-source Nvidia installer. I'm going to create a separate issue to ensure that these are installed in the image ahead of time.