[SOLVED] Why does kodi run only under root?

[tarazed]

This is really two problems but I don't know how to decouple them. The information on the web is utterly confusing - most of it is "preaching to the converted".

The need to install vdr and kodi came up recently in QA testing of imagemagick. vdr installed OK. It started fine as a service. Stopped it and used w_scan to generate a channels.conf in vdr format (112 channels). My problem now is where to put this data and I am also totally confused about how to configure vdr. From what I have been reading it appears that vdr has to be run as a service. The man page lists configuration settings but how can these be passed to vdr when it is running as a daemon? My guess is that it would have to be through a system configuration file, in /etc for instance but all I can find there is /etc/vdr/themes.

Trying a command found at LinuxTV improved things slightly; it suggested that channels.conf be copied to /etc/vdr and that I should invent /var/spool/video and then

Code: Select all

# vdr --video=/var/spool/video --epgfile=/var/spool/epg --config=/etc/vdr --lib=/usr/lib64/vdr
vdr: error while reading '/etc/vdr/sources.conf'

and there it hangs. Have no clue about what sources.conf is.

kodi sounded like a popular frontend for vdr so I installed it, started up vdr, then ran kodi as a user. This failed with a strange message about needing hardware accelerated OpenGL rendering, which my nvidia GTX770 certainly provides. Running kodi as root shows no such message and it is pretty certain that it was never meant to be run as root. It is a user application.

[doktor5000]

kodi runs fine for me under a normal user, without showing that message. That is with an nvidia card ...
You might need to provide some more details, like what nvidia driver you're using, glxinfo output and such.

[tarazed]

The driver is nvidia 352.79
<user>
This is what happens when LIBGL_DEBUG is set to verbose:

Code: Select all

$ glxinfo > glx.user
libGL: screen 0 does not appear to be DRI3 capable
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/lcl/.drirc: No such file or directory.
libGL: Can't open configuration file /home/lcl/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL: screen 1 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:0412, driver i965
libGL: OpenDriver: trying /usr/lib64/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL: Can't open configuration file /home/lcl/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/lcl/.drirc: No such file or directory.
libGL: Can't open configuration file /home/lcl/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Error: couldn't find RGB GLX visual or fbconfig

Start of glx.user:
name of display: :0
display: :0  screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
......


<root>

Code: Select all

# lsmod | grep nvidia
nvidia               8540160  33
drm                   352256  7 i915,drm_kms_helper,nvidia
# kodi
Error: couldn't find RGB GLX visual or fbconfig           <kodi runs fine>
# glxinfo > glx.root
Error: couldn't find RGB GLX visual or fbconfig
# less glx.root
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
.......


The user output is very strange. This machine has one screen and all other graphics
applications run happily under nvidia although vlc points out that:

Code: Select all

Xlib:  extension "XINERAMA" missing on display ":0".

[tarazed]

Curiouser and curiouser. I have a dummy user called zack who uses bash as his login shell. zack can run kodi without any problem and glxinfo reports that direct rendering is enabled. Tried switching my login shell from tcsh to bash and ran kodi again. It came up immediately and glxinfo shows that direct rendering is enabled. Tests on two other Mageia 5 machines exposed the same failure of glx with tcsh. Two other machines running Cauldron with a tcsh login had no problem with glx direct rendering. All these machines have nvidia graphics cards.

So, whatever the cause of this problem, it does not manifest itself in Cauldron and only occurs in Mageia 5 with the tc shell. It is not solved yet but I guess we can say it is resolved in the sense that there is a workaround.

[tarazed]

Marking this as solved because the subject line poses an invalid query. It should be rephrased as: why does kodi run only for bash users in Mageia5? or perhaps more to the point, why is nvidia direct rendering unavailable for tc shell users in Mageia5? Anyway, I am dropping this because Mageia 5 shall soon be EOL. Thanks for pointing me in the right direction doktor5000.

[doktor5000]

You should still report it against cauldron that it doesn't work with tcsh ...

Unrelated question, why do you change away your login shell from the default?

[tarazed]

It is a historical thing. I have been using tcsh for 25 years. At work, when we moved from VAX/VMS to Unix the organisation Starlink, which supported our astronomical software, recommended tcsh, because they preferred it I suppose. bash was to be used by system administrators. At this late stage in my life (77) I do not relish the prospect of yet another change to my set routine. Converting my tcsh aliases and scripts to bash would take more time than I am willing to afford. I had thought about it.

[tarazed]

Sorry doktor5000: I had started to report the tcsh problem on Bugzilla but found that with a later kernel on other machines the fault had disappeared and kodi, for instance, ran successfully. So I am not going to pursue the bug any further; too many inconsistencies and I have to get back to QA work.