Package Details: kodi-standalone-service 1.136-1

Git Clone URL: (read-only, click to copy)
Package Base: kodi-standalone-service
Description: Systemd services to run kodi in stand-alone mode without a DE
Upstream URL:
Licenses: MIT
Replaces: kodi-standalone-gbm-service, kodi-standalone-wayland-service, kodi-standalone-x11-service
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 64
Popularity: 0.008706
First Submitted: 2014-11-05 20:25 (UTC)
Last Updated: 2022-07-04 19:58 (UTC)

Latest Comments

graysky commented on 2021-08-15 18:20 (UTC) (edited on 2021-08-16 11:33 (UTC) by graysky)

@wooptoo - Are you using the latest version? This was fixed weeks ago:

Also, the ExecStop is needed or else kodi does not exit cleanly/you lose data. See commit msg:

wooptoo commented on 2021-08-15 15:32 (UTC) (edited on 2021-08-15 15:34 (UTC) by wooptoo)

The kodi-x11.service now fails since it can't find the kodi-x11 binary. Replacing the ExecStart directive with the following fixed it:

ExecStart=/usr/bin/xinit /usr/bin/kodi --standalone -fs -- :0 -quiet -nolisten tcp vt1

Also the ExecStop line is not necessary since systemd kills all processed owned by the kodi user.

Complete file here

francoism90 commented on 2021-08-04 13:05 (UTC)

@graysky Turns out I'm an idiot.. changing the target ( to fixed the issue. :)

graysky commented on 2021-07-19 14:12 (UTC)

Fixed in 1.132-2, thanks.

ghen commented on 2021-07-19 14:10 (UTC)

kodi-standalone-service-v1.132.tar.gz ... FAILED ==> ERROR: One or more files did not pass the validity check!

The current download file has a different checksum: b2sums=('29b0ace7b1519f25cf616f6c7aab2534aee2b3af92e702bb4bcaca054d4a1bb606b27c6a030edc6006b05464350eb67ad29de2693a088d0aac4881049e0c33a7')

francoism90 commented on 2021-07-17 08:24 (UTC)

@graysky Thanks for your reply. :)

I don't know to be honest, will try to find out.

Maybe it's not fscrypt, the only other thing I could think about is apparmor. I have enabled logging in Kodi, will report back if this shows something useful.

graysky commented on 2021-07-15 17:55 (UTC)

I have no experience with fscrypt. Does the service need to add something in the After= to capture your decrypted stuff?

francoism90 commented on 2021-07-14 06:46 (UTC)

@graysky When starting kodi-*.service (any variant), it mostly doesn't start for me - it also doesn't work on boot. It seems to be caused by fscrypt (ext4), starting kodi manually works, however it simple freezes.

I have done changes to the PAM modules:

Could this be the cause? Other things I could try?

Many thanks. :)

gkun commented on 2021-05-09 23:14 (UTC)

@graysky Thank you! I cleared yay's cache and everything worked.

graysky commented on 2021-05-09 12:08 (UTC)

@gkun - The checksum works for me. If you're caching your source somewhere manually delete it and try again?

gkun commented on 2021-05-09 10:18 (UTC)

Did anyone run into update issues with the newest version? For me it will not pass the b2sums validity check:

==> Validating source files with b2sums... kodi-standalone-service-v1.129.tar.gz ... FAILED ==> ERROR: One or more files did not pass the validity check! error downloading sources: kodi-standalone-service

khvalera commented on 2021-03-22 16:54 (UTC)

@graysky - I already saw that the kodi-rpi package was compiled in armlinux, it already has files, a conflict occurs.

graysky commented on 2021-03-21 22:22 (UTC)

I added it since some users built on Arch ARM and caused them problems. Are you experiencing an issue with it?

ghen commented on 2021-03-21 21:09 (UTC)

That's not really relevant. It doesn't make sense to "build" separate i686, x86_64, and soon maybe x86_64-v3 versions of this non-binary package.

graysky commented on 2021-03-21 20:58 (UTC)

why is the architecture x86_64 specified and notany? @khvalera - Arch ARM ships the needed files in the respective packages.

khvalera commented on 2021-03-21 20:23 (UTC)

why is the architecture x86_64 specified and notany?

francoism90 commented on 2021-03-02 07:50 (UTC)

Do you guys run kodi-wayland or kodi-x11 as standalone? I'm thinking of moving to Wayland as standalone.

graysky commented on 2020-12-14 20:37 (UTC)

@ghen - the issue we are running into here is complex for kodi-x11 due to systemd and/or my lack of mastery of all its myriad nuances. For one, we are starting xorg-server and then starting kodi within in one step which led to a bit of confusion and discussion to get it to both start and stop properly[1,2].

Beyond that, differences in systemctl stop kodi-x11 and systemctl reboot caused me to make the most recent change removing the PAMName= so I could get the entire thing under the system.slice and out of the user.slice[3].

I am open to suggestions to limit the kodi user to just the physical keyboard.


ghen commented on 2020-12-14 20:19 (UTC)

Thanks. Not sure it's a good idea to give kodi unrestricted access to all input devices though? (even if the user switches to another tty?)

graysky commented on 2020-12-14 19:58 (UTC) (edited on 2020-12-14 20:02 (UTC) by graysky)

@ghen - I think kodi may need to be in the input group now that the PAMName= directive is removed. EDIT: yep, I will fix and update. Thank you for the report.

ghen commented on 2020-12-14 18:51 (UTC)

I'm seeing the following in Xorg.log for all input devices, from power button to keyboard and mouse: (EE) xf86OpenSerial: Cannot open device /dev/input/event4 Permission denied.

ghen commented on 2020-12-14 18:37 (UTC)

Hmm, with this version, keyboard entry to kodi does not work anymore. Could it be that kodi no longer owns the tty?

graysky commented on 2020-12-14 16:18 (UTC)

@ghen - My bad, fixed in 1.117-2 thanks for pointing it out.

ghen commented on 2020-12-14 15:36 (UTC)

1.117-1 fails to build: install -Dm0644 "$srcdir/polkit.rules" "$pkgdir/usr/share/polkit-1/rules.d/10-kodi.rules". There is no file polkit.rules, should be 10-kodi.rules?

fattoony commented on 2020-11-08 20:18 (UTC)

@graysky I can confirm v1.116 has corrected the issue. Thanks!

graysky commented on 2020-11-08 13:45 (UTC)

@fattoony - Thanks for reporting. v1.116 should fix it.

fattoony commented on 2020-11-07 22:23 (UTC)

Hi, I have a problem since version 1.111 that I am unable to restart kodi using kodi's built-in function "RestartApp". Kodi quits fine but it does not restart, I must then systemctl start kodi.

1.109 was the last working version.

anatolik commented on 2020-10-13 23:09 (UTC)

@graysky thank you, it helps.

anatolik commented on 2020-10-13 23:09 (UTC)

@graysky thank you, it helps.

graysky commented on 2020-10-12 15:45 (UTC)

@anatolik - delete your source cache and try again. Current sum matches github tarball.

anatolik commented on 2020-10-12 15:35 (UTC)

==> Making package: kodi-standalone-service 1.107-6 (Mon Oct 12 08:34:07 2020)
==> Retrieving sources...
  -> Found kodi-standalone-service-v1.107.tar.gz
==> Validating source files with b2sums...
    kodi-standalone-service-v1.107.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Could not download sources.

ghen commented on 2020-09-14 20:09 (UTC)

1.105 tested and working fine!

graysky commented on 2020-09-14 19:56 (UTC)

You're welcome, thanks for the suggestion. Please try the formal v1.105 and report back.

ghen commented on 2020-09-14 19:53 (UTC)


graysky commented on 2020-09-14 19:46 (UTC) (edited on 2020-09-14 19:52 (UTC) by graysky)

Hmmm... I just pushed 1.105 but perhaps I can ship a commented /etc/conf.d/kodi-standalone containing a few you mentioned plus some commented text. That might be helpful for folks.

EDIT1: maybe the wiki is a better place. EDIT2:

ghen commented on 2020-09-14 19:42 (UTC) (edited on 2020-09-14 19:47 (UTC) by ghen)

Unfortunately not, it seems rather scattered.

I found KODI_DATA in /usr/bin/kodi itself (overridable), others can be found here and there on the Kodi wiki (or Arch wiki) discussing specific issues and workarounds, like KODI_AE_SINK, KODI_GL_INTERFACE, ...

Also several non-Kodi-specific variables can have effect on Kodi as well, like SDL_VIDEO_FULLSCREEN_HEAD (for multiscreen use), or LIBVA_DRIVER_NAME, VAAPI_MPEG4_ENABLED and others related to X11 direct rendering.

graysky commented on 2020-09-14 19:36 (UTC)

@ghen - Right, I am saying it might be nice to link to kodi-specific vars.

graysky commented on 2020-09-14 19:31 (UTC)

@ghen - Are you aware of a list of common environment variables kodi uses? Might be nice to provide some documentation.

ghen commented on 2020-09-14 19:27 (UTC)

Thanks! Maybe name it kodi-standalone rather than kodi, because it will be specific to the standalone invocation - running kodi directly will not involve this file.

graysky commented on 2020-09-14 19:24 (UTC)

@ghen - I'm thinking /etc/conf.d/kodi might be a more standard option. I'll go ahead and make the addition.

ghen commented on 2020-09-14 19:12 (UTC)

I verified with KODI_DATA=/tmp/kodifoo and it fired up a "new"/empty kodi instance. ;-) This allows me to move my kodi installation out of /var/lib/kodi without using symlinks.

graysky commented on 2020-09-14 19:08 (UTC) (edited on 2020-09-14 19:09 (UTC) by graysky)

@ghen - Have you verified that your proposed modification works? Is the contents of your /etc/default/kodi simply KODI_AE_SINK=ALSA? I would need to read up to verify that the file that the user would edit is working as expected?

ghen commented on 2020-09-14 18:18 (UTC)

Some low-level aspects of Kodi's behaviour (mostly hardware/driver workarounds, but also global paths like KODI_DATA or CRASHLOG_DIR) can be controlled through environment variables, it would be nice if the systemd unit could include an EnvironmentFile to put such settings in, rather than having to override the unit with individual Environment= flags, or worse, editing the /usr/bin/kodi-standalone script as suggested in

Just add to each .service file something like:


(The leading dash implies the file is not required, so no need to supply a default empty file.)

Not sure if /etc/default/, /etc/conf.d/ or even /etc/sysconfig/ is preferred...

graysky commented on 2020-09-08 15:06 (UTC)

@jimbob - that is a mistake

jimbob commented on 2020-09-08 13:30 (UTC)

The wiki specifically says to use the standalone service if you want to start kodi with an ir remote button press and you can quit/exit Kodi manually, so I don't really follow your argument.

graysky commented on 2020-09-08 13:24 (UTC)

jimbob - The goal of this service is 24/7 standalone. check the wiki for other options. Remember, you are using systemd to start kodi. That is a decision a root level user makes. See my previous comments regarding this.

jimbob commented on 2020-09-08 10:44 (UTC) (edited on 2020-09-08 10:46 (UTC) by jimbob)

I don't want to have Kodi running 24 hours a day. Ideally I would like to start it with a remote control key press and have it automatically exit after an hour or so of inactivity. Thanks.

This reply looks useful.

graysky commented on 2020-09-08 10:34 (UTC)

@jimbob - My bad, yes, I am referring to options under the "Power Options." I only have two under Settings>System>Shutdown functions as well. I am not sure how to modify this without further study.

What is your use case? You want the system (root user) to enable the service via systemctl but you want the unprivileged user (kodi) to be able to stop it dropping back to the TTY/login screen?

jimbob commented on 2020-09-07 22:32 (UTC) (edited on 2020-09-07 22:45 (UTC) by jimbob)

No I only have Shutdown and Suspend. The Kodi wiki says Quit, but Exit, Quit and systemctl stop surely all do the same thing. I was wondering if the missing options were a deliberate design choice for the standalone service so as not to logout leaving the device in a potentially unusable state. Looking at the options you've listed I wonder if you're talking about the general power menu, whereas I am talking about the Power Saving -> Shutdown function menu?

graysky commented on 2020-09-07 21:36 (UTC)

You should have 5 options, exit, power off system, custom shutdown timer, suspend, and reboot. There is not an option to quit. You do that on the terminal via a call to systemctl like any other service.

jimbob commented on 2020-09-07 20:45 (UTC)

In Settings -> System -> Power Saving -> Shutdown function I only have Shutdown and Suspend, ie, no Quit. Is this expected?

graysky commented on 2020-08-27 09:07 (UTC)

@zynex - As ghen pointed out, that can lead to a loop. Plus, if the user selected "exit" from the GUI, it would force a restart of kodi.

ghen commented on 2020-08-27 08:35 (UTC)

That's not very nice when kodi fails to start for some reason, causing a loop.

zynex commented on 2020-08-27 04:31 (UTC)

Just a thought, but shouldn't the systemd service have Restart=always instead of Restart=on-abort? Sometimes you want to restart kodi without restarting the computer itself. Quitting Kodi won't restart the app if you have "on-abort".

Renfield commented on 2020-06-30 22:59 (UTC)

I have added "-s 0" to the Xorg options directly in the kodi.service file and it seems to be working now.

Renfield commented on 2020-06-30 22:24 (UTC)

First off, I discovered that I did not have xset installed. I have installed it and I see that it is in /usr/bin/xset.

Now, I have tried using both a .xprofile and a .xinitrc file in /var/lib/kodi. I have also tried with giving the full path to xset. Nothing so far has worked, and after some time the TV declares that there is no signal. If I hit a key or wiggle a mouse then the video comes back.

graysky commented on 2020-06-30 19:59 (UTC)

@Renfield - The kodi user has a home dir, you mentioned it, /var/lib/kodi/

Renfield commented on 2020-06-30 19:46 (UTC)

How do I prevent the TV from losing the HDMI signal after about five minutes unless I press a keyboard key? I thought perhaps adding the following lines to /var/lib/kodi/.xprofile would do it:

xset -dpms xset s off

But it did not. Since the kodi user does not have a home directory, where would Xorg look for such configuration?

blinx commented on 2020-05-26 21:50 (UTC)

@elParaguayo nice to find another paraguayo around here!

elParaguayo commented on 2020-05-02 18:49 (UTC) (edited on 2020-05-03 17:27 (UTC) by elParaguayo)

uid=974(kodi) gid=974(kodi) groups=974(kodi),995(audio),990(optical),987(uucp),986(video)

Happy to send comments on the github issues page instead of filling up comments here.

Yes - on x86_64. This is in VirtualBox (I wanted to check whether Arch could work for my HTPC) but I had the same issue on my laptop.

EDIT: I wonder if this is dbus related... I'll post an issue on your github page.

graysky commented on 2020-05-02 18:43 (UTC) (edited on 2020-05-02 18:49 (UTC) by graysky)

@elParaguayo - You are on x86_64 not ARM right? What is the output of id kodi?

elParaguayo commented on 2020-05-02 17:58 (UTC) (edited on 2020-05-02 18:24 (UTC) by elParaguayo)

I'm having issues exiting the program. I've enabled the service so it boots into Kodi but selecting Exit, Powerdown, Suspend etc just causes Kodi to hang. I need to switch to another terminal and login in order to reboot.

When running Kodi as a normal user from a graphical environment, this doesn't happen. Is this a permissions issue for the kodi user? There were some comments on the kodi forum (for the Arm package) about needing a polkit file. Don't think there's one here - I tried creating one manually with no change, but I could have got it wrong!

graysky commented on 2020-02-02 19:54 (UTC)

@ghen - Good idea,

ghen commented on 2020-02-02 18:39 (UTC)

Hi, could you add StandardOutput=journal to the unit file, to avoid it to inherit from StandardInput=tty and print xinit output on the screen? (which no other unit does) This allows to get a :)

graysky commented on 2020-01-12 11:47 (UTC)

@asm0dey - If you want to override the package provided files, place your own in /etc/sysusers.d/ ... see man sysusers.d

asm0dey commented on 2020-01-11 22:07 (UTC)

@graysky I mean mark .conf and .service files as backup, please

graysky commented on 2020-01-08 23:53 (UTC)

Arch ARM is not Arch. They are not the same platform and within Arch ARM there are different platforms. Arch ARM kodi packages ship with their own kodi.service that works on it.

stuartiannaylor commented on 2020-01-08 21:17 (UTC) (edited on 2020-01-08 22:44 (UTC) by stuartiannaylor)

Thats a shame then as need a common install across platforms. I will go back to creating my own service prob then, just noticed you in the Arch Linux Arm forum in the kodi section so was wondering if that was your intent.

The update works fine though but for some strange reason fails on first reboot then works :)

graysky commented on 2020-01-08 19:28 (UTC)

This package is NOT for any Arch ARM kodi. x86_64 only!

stuartiannaylor commented on 2020-01-08 19:02 (UTC)

I will give it a go the install is trashed at the moment with windows as it turned out to be lack of signal on a dvb.

I did do a fresh install of just xorg normal kodi and the startx worked for me but will try yours again. Prob be a couple of days as playing with the Pi4. Are you trying the same with Pi4? as interested?

graysky commented on 2020-01-08 13:27 (UTC)

@stuart - I updated to 1.98-1 a few min ago. Try this:

# systemctl stop kodi (or kodi-gbm)
# userdel kodi
# groupdel kodi
# rm /etc/X11/Xwrapper.config
# pacman -Rs kodi-standalone-service (or gbm if you use that)

Reboot, then build/install 1.98. Does it work as intended?

stuartiannaylor commented on 2020-01-08 12:24 (UTC) (edited on 2020-01-08 12:28 (UTC) by stuartiannaylor)

Nope Graysky apols as haven't played with Arch for over a year and its like starting anew so just getting up to speed. I am not sure what it is maybe its my EFI arch install but even with a pacman -U it just hands at reached graphical target. 2 days ago it just installed no problem think that was without a EFI boot part but only difference.

Anyone done a fresh install in the last day or so?

Also did the /etc/X11/Xwrapper.config which should contain the following:

needs_root_rights = yes

stuartiannaylor commented on 2020-01-08 12:18 (UTC)

Just me doing makepkg -si which is my usual also the likes of yay does the same. I will let it fail and then just do pacman -U

graysky commented on 2020-01-08 12:05 (UTC)

@asm0dey - I don't understand your request. @stuartiannaylor - Try 1.97-2 but you shouldn't need both installed at the same time. You're either running kodi-x11 or kodi-gbm.

stuartiannaylor commented on 2020-01-08 11:28 (UTC)

:: kodi-standalone-service and kodi-standalone-gbm-service are in conflict

Seems 20.01.01 something has changed as makepkg -si just produces the above x86_64?

asm0dey commented on 2020-01-08 07:47 (UTC)

Could you please mark all .service files as config? I'm running kodi from another and every upgrade breaks this service

webdawg commented on 2019-05-20 21:26 (UTC)

I just posted something in the forum:

I am just trying to understand what the deal is with this package, and why we are doing some of the things we are doing.

graysky commented on 2019-05-13 23:34 (UTC)

@achilleas.k - thank you for the suggestion.

achilleas.k commented on 2019-05-13 23:29 (UTC)

Awesome. Thanks @graysky!

graysky commented on 2019-05-13 23:23 (UTC)

@achilleas.k - Let me read the man page for usermod based on your suggestion. Thanks.

achilleas.k commented on 2019-05-13 21:30 (UTC)

Newer versions of the post_upgrade() hook in the readme.install file have been messing with my Kodi user permissions.

Since 1.95-1, the line usermod -g kodi -G audio,input,network,optical,video kodi has been removing the kodi user from manually assigned groups that I keep to give access to media directories. Wouldn't it be friendlier to custom setups like mine to use usermod -g kodi -aG audio,input,network,optical,video kodi?


SpaceAgeHero commented on 2019-03-15 18:58 (UTC)

Yes I can also confirm this issue. Gladly it can be fixed by enabling the "dim" screensaver add-on in KODI settings ...

hillbicks commented on 2019-03-01 08:25 (UTC)

Anyone else having problems with the display turning off after 10 minutes? I already made a thread here

graysky commented on 2018-06-10 12:58 (UTC)

@Ranjak - Please see your BBS thread and comment there (ie confirm that no changes are needed to this package).

Ranjak commented on 2018-05-27 17:17 (UTC)

@ajdunevent You're not alone, I opened a thread here :

Also, I'm on nvidia (dedicated desktop), which seems to hint that this isn't a vendor-specific problem since you're on intel apparently.

Maybe you could post your failing xorg log (it should be in /var/lib/kodi/.local/share/xorg) on the thread I linked above.

ajdunevent commented on 2018-05-23 00:36 (UTC) (edited on 2018-05-23 00:37 (UTC) by ajdunevent)

The upgrade to xorg 1.20 seems to have broken this for me. I rolled back the following packages:

xorg-server-1.19.6-2-x86_64<br> xorg-server-common-1.19.6-2-x86_64<br> xorg-server-devel-1.19.6-2-x86_64<br> xf86-video-intel-1\:2.99.917+829+gd7dfab62-1-x86_64

Hope I'm not the only one facing this issue. Let me know if there is anything more useful I can provide to help.

graysky commented on 2018-04-14 17:59 (UTC)

@graysky - Most of the platform-specific builds of Kodi for ARM (such as kodi-rbp) already include a service file, so this package is unnecessary on ARM generally.

@rpcameron - There is no documentation advising ARM users to install it. 1) arch='x86_64' not arm-x 2) comments on line 7 and 8 of the PKGBUILD itself 3) warning on the kodi wiki page

Not sure why you posted...

rpcameron commented on 2018-04-14 17:04 (UTC)

@graysky - Most of the platform-specific builds of Kodi for ARM (such as kodi-rbp) already include a service file, so this package is unnecessary on ARM generally.

graysky commented on 2018-03-28 17:45 (UTC)

@khvalera - This package causes problems with Arch ARM... best to at least discourage those users away from it.

khvalera commented on 2018-03-28 09:44 (UTC)

replace arch = ('x86_64' 'i686') with arch = ('any')

mr_nuub commented on 2018-02-15 06:41 (UTC)

Sorry, it was my fault. xkbcomp does not know about de_nodeadkeys and does NOT load the layout if the variant is wrong - it just loads the default english layout. Using only "localectl set-x11-keymap de" or using the right variant will solve this issue.

graysky commented on 2018-02-10 22:30 (UTC)

I never tried changing the default layout... is there a setting at a deeper level in the system for this?

graysky commented on 2018-02-10 22:30 (UTC)

I never tried changing the default layout... is there a setting at a deeper level in the system for this?

mr_nuub commented on 2018-02-10 20:58 (UTC)

How do I set the keyboard laout? I used "localectl set-x11-keymap de pc105 de_nodeadkeys" to set it to german, but it is still english. I also switched over to the kodi user and displayed the current configuration with "DISPLAY=:0 setxkbmap -print -verbose 10". Everything says "de". Even the file "/etc/X11/xorg.conf.d/00-keyboard.conf" point to "de". But in kodi it's english. What else should I try?

kuch3n commented on 2017-04-09 08:05 (UTC)

fails to start :( 09:47:13.744 T:140299952466048 ERROR: CWinSystemX11::XErrorHandler: BadValue (integer parameter out of range for operation), type:0, serial:91, error_code:2, request_code:155 minor_code:3 09:47:13.744 T:140299952466048 ERROR: GLX Error: Could not create context

graysky commented on 2017-03-11 09:49 (UTC)

@Hell-G - That's fine. I was mistaken, it's not display.service, it's display-manager.service which should be a symlink to whatever you're using, gdm in your case, lxdm in mine: ls -lh /etc/systemd/system/display-manager.service lrwxrwxrwx 1 root root 36 May 11 2016 /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/lxdm.service In any case, yeah, if you want to use the box for things other than kodi, this is probably not for you.

Hell-G commented on 2017-03-11 08:49 (UTC)

Thank you graysky for all the work you have put in and for all your replies here and in the forums! I do not have a display.service, I can only find gdm.service on my system. Reading your last sentence, I think that "kodi-standalone-service" is not the right thing for me after all. I still want to be able to login as a different user and therefore, getting rid of my display manager is not what I want. I am sorry, that I did not understand this earlier and bothered you here.

graysky commented on 2017-03-10 22:33 (UTC)

@Hell-G - disable display.service (should be symlinked to gdm on your system) and enable kodi.service. "kodi-standalone-service" is for systems that want to use the GUI exclusively for kodi.

Hell-G commented on 2017-03-10 22:24 (UTC)

Thank you for your replies! 1)$ id kodi uid=420(kodi) gid=420(kodi) groups=420(kodi),90(network),91(video),92(audio),93(optical) 2)$ grep kodi /etc/passwd kodi:x:420:420:kodi user:/var/lib/kodi:/usr/bin/nologin 3) It has never happened, that my computer booted directly into Kodi. Very interesting. I did not install GDM nor Gnome for Kodi, I use those for when I am doing other stuff than using Kodi. The service is started and enabled, so I don't see what I am doing wrong. Is GDM and Gnome in the way of kodi-standalone? $ sudo systemctl status kodi ● kodi.service - Starts instance of Kodi using xinit Loaded: loaded (/usr/lib/systemd/system/kodi.service; enabled; vendor preset: disable Active: active (running) since Thu 2017-03-09 21:36:14 CET; 1 day 1h ago Main PID: 10557 ((xinit)) Tasks: 1 (limit: 4915) CGroup: /system.slice/kodi.service └─10557 (xinit) Mar 09 21:36:14 hostname systemd[1]: Started Starts instance of Kodi using xinit. Thanks again!

redbaron commented on 2017-03-10 19:38 (UTC)

This package is for booting (not logging) directly into Kodi. You don't need GDM or Gnome, just X, all the dependencies are listed in this package.

graysky commented on 2017-03-10 19:35 (UTC)

What is the output of: 1) id kodi 2) grep kodi /etc/passwd

Hell-G commented on 2017-03-10 16:22 (UTC)

Sorry guys, I have a very basic question. Although I installed kodi-standalone-service a long time ago and I think I was using its functionality, now I am not sure anymore, if I really understand it. What is the main purpose of this package? My interpretation was, that it offers the possibility to run Kodi without loading a DE. I am using GDM and Gnome and in the past, I had the Kodi user listed on my login screen and I set up passwordless login for it (sorry, I don't remember how I actually did it). So as soon as I select this user, I go directly into Kodi. Since the last time I updated my system, the Kodi user is no longer shown. So I started digging. The Arch Wiki says: "Note: kodi-standalone-serviceAUR creates a user named kodi, which is not permitted to login, thus autologin will fail with this user." So if the user is not permitted to login, how is it possible, that I used to be able to login in GDM and have Kodi started right away? Looking at the UID of the Kodi user (420), it makes sense now, that the user is not listed at the login screen, because the ID is <1000. So it is a system user and not supposed to login. But why did it show it for me before? Or is the package meant to directly boot into Kodi without any further user interaction? But if this is the case, this has never worked for me and I would not know what to adapt to make this work. I basically just want to be able to go directly into Kodi from the login screen (preferably without password) and don't have a full blown DE running in the background. Thank you for your help!

graysky commented on 2017-03-04 14:19 (UTC)

Bump to v1.90-1 Changelog: Run on vt1 not vt7 for increased compatibility. Commit:

graysky commented on 2017-03-04 14:17 (UTC)

@red - good point!

redbaron commented on 2017-03-04 10:34 (UTC)

Dual monitor is possible but for standalone HTPC it's not usual. And mostly this package is used on systems when KODI is started upon HTPC startup without any additional DE.

graysky commented on 2017-03-04 09:33 (UTC)

@redbaron - This is how it was originally setup by our team.[1] I think vt1 is the default for greeters. I can confirm that lxdm uses it anyway. Is it possible to have a box that drives both TV (HDMI1) and a monitor simultaneously (HDMI2 or DVI or DSUB, etc)? 1.

redbaron commented on 2017-03-03 21:20 (UTC) (edited on 2017-03-03 21:23 (UTC) by redbaron)

I am using nvidia 378.13-3, but same problem. I think main problem is better described here Why not to use vt1 by default?

graysky commented on 2017-03-03 21:06 (UTC)

@red - Yes, on a box that needs the 340xx drivers, I too have to remove the vt7. Dunno if there is a fix in the works or not, see:

redbaron commented on 2017-03-03 19:16 (UTC)

I have same problem as @ricrogz, removing vt7 helped but then shutdown function disappeared from kodi's "power options", changing vt7 to vt1 worked.

graysky commented on 2017-02-21 23:15 (UTC)

Does that series of nvidia cards use the 340xx drivers? Best to continue this in the thread you started[1]. 1.

invik commented on 2017-02-21 22:46 (UTC)

@graysky -- sorry, forgot to mention: the card is an Nvidia GT 610. Also, I am not running kodi as root: observe the "-u kodi" after the sudo. I have been looking around the problem for several days now, and just a few minutes ago I made some progress: The problem seems to be the "vt7" option at the end of the command line. Somehow, it looks like systemd dislikes it, and, if I lower the number (i.e. vt2 or vt3), or even remove the parameter, the errors in the Xorg log are gone, and kodi starts again (but takes a while to do so, but this seems more related to some issues with pulseaudio, which, despite all my attempts to disable it, still spawns every time I start kodi).

graysky commented on 2017-02-21 22:09 (UTC)

@ric - What hardware? Also, never run kodi as root. It's unsafe and potentially changes the permissions on /var/lib/kodi so that the kodi user cannot write to it and subdirs. What I can tell you is that after an update a few days ago, my nvidia-340xx machine stopped running as the kodi user via the service. I enabled [testing] and updated and everything works again.

invik commented on 2017-02-21 22:03 (UTC)

I'm unable to start kodi by using the service file from this package, but I still can start it without any problems by issuing (as root): sudo -u kodi /usr/bin/xinit /usr/bin/kodi-standalone -- :0 -nolisten tcp vt7 I always get this line in my Xorg.0.log file: [ 31.070] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 1 [ 31.070] (EE) Error systemd-logind returned paused fd for drm node And, after that, the wrong "glx" driver gets loaded (the default one in the xorg package), and kodi dies out in a black screen, spitting out crashlogs in user kodi's home directory. Does this happen to anyone else? any ideas on how to fix this? (I'm not claiming this package is broken, just asking for help...)

gsstratton commented on 2017-02-07 21:03 (UTC)

my apologies. Was my config. Did a factory reset and it worked. There was just absolutely nothing in my journalctl or service status. Sorry for shooting from the hip like that.

graysky commented on 2017-02-07 20:08 (UTC)

@gss - Works fine on several different machines. You haven't provided any debugging info to help you.

graysky commented on 2017-02-07 20:08 (UTC)

@gss - Works fine on several different machines. You haven't provided any debugging info to help you.

gsstratton commented on 2017-02-07 19:32 (UTC)

No longer working with v17.0

Hell-G commented on 2017-01-12 20:24 (UTC)

Thank you guys! I tried it with the /etc/X11/Xwrapper.config, but it did not change anything. @graysky: Thank you, I will change this and see, if I like the behavior better this way! @francoism90: Starting Kodi is no problem, getting out of it is more difficult. Kodi keeps restarting, when I want to exit. Thank you for your help anyways!

francoism90 commented on 2017-01-12 19:24 (UTC)

@graysky: Remembered I'd needed to enable this on a previous build with an Intel GPU. Think it depends on the hardware and setup. @Hell-G: Thought your problem was starting Kodi, think indeed this bug is something else as describe by graysky.

graysky commented on 2017-01-12 19:13 (UTC)

@Hell-G - The restarting when you exit from the GUI is a bug I have not been able to squash. We want the service to restart if kodi crashes, ie, an unclean signal. The problem is that exiting from the GUI causes systemd to think it was unclean. You can remove the restart= line in the service if you want, but know that it won't restart if kodi crashes if you do so. See the systemd.service man page for more. The /etc/X11/Xwrapper.config shouldn't be required for most systems... I believe some users of on of the radeon video chips needed it. Intel and nvidia should not need this.

francoism90 commented on 2017-01-12 11:50 (UTC)

@Hell-G: Correct, see

Hell-G commented on 2017-01-12 10:54 (UTC)

@francoism90: No, I did not do anything else than install the package. You mean needs_root_rights = yes in /etc/X11/Xwrapper.config ?

francoism90 commented on 2017-01-12 10:29 (UTC)

@Hell-G: did you enable to need_root flag for Xorg?

Hell-G commented on 2017-01-12 09:37 (UTC)

Kodi-standalone has been working well for me, but I am having a problem when I try to exit it. Most of the time, it directly starts Kodi again and I end up at the home screen and not at the login screen. Sometimes it does exit properly, but unfortunately most of the time I try many times and always end up back at the Kodi home screen. Any one else seeing this problem? Any ideas how to debug this? Thanks!

graysky commented on 2016-09-17 15:29 (UTC) (edited on 2016-09-17 15:30 (UTC) by graysky)

@elimpfor - That is how the current version is shipped.. you should not need to modify it: % grep ExecStart /usr/lib/systemd/system/kodi.service ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone -- :0 -nolisten tcp vt7 EDIT: I have tested the out-of-the-box version with the nvidia-340xx drivers and the Intel drivers (separate machines) and both work just fine.

ncoder-2 commented on 2016-09-17 15:21 (UTC)

Just wanted to say that for nvidia driver, it is still required (at least in my case) to modify /etc/systemd/system/ to have: ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone Or else X doesn't start.

graysky commented on 2016-09-11 01:25 (UTC)

@zofiel - I am not an expert, but removing it seems to have no ill-effects and solves problems for others.

zofiel commented on 2016-09-10 09:09 (UTC)

so usr/bin/dbus-launch --exit-with-session si no longer necessary? To modify the kodi wiki.

graysky commented on 2016-09-08 19:49 (UTC)

Bump to v1.81-1 Changelog: Increased compatibility with new dbus package. Commit:

graysky commented on 2016-09-08 19:17 (UTC)

Replied in the bbs thread you linked.

zofiel commented on 2016-09-08 11:34 (UTC)

Since DBUS update, Kodi standalone doesn't works properly. Press home button and kodi freezes. Looking for a solution, I found this post: Deleting /usr/bin/dbus-launch --exit-with-session solved the issue I don't know If this option is not longer necessary

graysky commented on 2016-06-21 00:35 (UTC)

Good catch, thank you.

bananabrain commented on 2016-06-20 23:48 (UTC)

minor syntax error in readme.install, lines 61, 73

Tetz commented on 2016-06-10 04:19 (UTC)

I have to change all the tty7 references in the kodi.service file to tty1 to make it work on my system.

CandyAngel commented on 2016-04-06 22:24 (UTC)

@graysky: This occurred (on the same machine) on two successive fresh installations from the 2016-03-01 media (with both of those drivers). The change was not required when using the nouveau module. Kodi would also start with nvidia and the original ExecStart when the 'kodi' user was 'sudo su -l'd to. When starting kodi.service "as-is" with the nvidia or nvidia-340xx drivers, Xorg.0.log contains: [ 14.098] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c1 [ 14.100] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 8 paused 1 [ 14.100] (EE) Error systemd-logind returned paused fd for drm node [..snip..] [ 14.258] (==) Matched nouveau as autoconfigured driver 0 (and the nvidia driver is not matched at all) However, with the modification, systemd-logind is only mentioned once: [ 13.368] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration It may be important that this line is also included in my working Xorg.0.log: [ 13.367] (--) using VT number 2 Let me know if there is anything I can do to help isolate the problem! :)

graysky commented on 2016-04-05 19:03 (UTC)

@candy - That shouldn't be necessary. I have tested this on several boxes with the nvidia drivers installed (nvidia and nvidia-340xx) and it behaves as expected for me.

CandyAngel commented on 2016-04-04 22:31 (UTC)

I've found that, with the nVidia driver installed, this service won't start Kodi as systemd-logind will interfere and make X think the nVidia driver isn't viable (then X won't find any screens). I had to override ExecStart with the below to get it to work with nVidia: /usr/bin/xinit /usr/bin/dbus-launch --exit-with-session /usr/bin/kodi-standalone (removed everything after '--' in the original). Credit (and thanks) to grazzolini in #archlinux for this solution.

graysky commented on 2016-02-01 20:33 (UTC)

I will add a post_install message to users of the open source ATI driver but I need to know: is it the xf86-video-ati package that provides this driver?

graysky commented on 2016-01-17 13:54 (UTC)

I can't comment since I do not have ATI hardware for testing. Is the use of the open source ATI driver true for everyone who has experienced this problem? Are there any users of the open source ATI driver that do NOT need to create this file?

Kalq commented on 2016-01-16 22:18 (UTC)

Confirming that I too need the Xwrapper.config file. I'm using the open source ATI driver. When I was using the Catalyst driver I didn't need it.

graysky commented on 2016-01-02 19:12 (UTC)

@epinephrine - That is not needed. Confirmed on a fresh install just now. Upon rebooting into it, I was greeted with kodi with no additional setup. I suspect you are missing something with regard to your ati drivers... unless the ATI drivers for some reason require that file which would surprise me. I have not ATI hardware for testing. mount /dev/sda4 /mnt/mini pacstrap -i /mnt/mini base xf86-video-intel kodi kodi-standalone-service echo "LABEL=mini / ext4 defaults,relatime 0 1" >> /mnt/mini/etc/fstab echo mini > /mnt/mini/etc/hostname sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /mnt/mini/etc/locale.gen echo "LANG=en_US.UTF-8" > /mnt/mini/etc/locale.conf arch-chroot /mnt/mini /bin/bash passwd sed -i '/^MODULES/ s,"","i915",' /etc/mkinitcpio.conf mkinitcpio -p linux locale-gen systemctl enable kodi exit reboot

sebstar commented on 2016-01-02 17:07 (UTC)

Just want to mention that I also needed the Xwrapper.config file with 'needs_root_rights = yes'. I use the ati drivers and have a minimal X installation, i.e., the only xorg related software that I installed is kodi. Maybe this package should include the Xwrapper.config file or at least a post-installation comment that this file might be needed.

tetris11 commented on 2015-12-17 15:40 (UTC) (edited on 2015-12-17 15:41 (UTC) by tetris11)

After uninstalling and reinstalling I can't seem to recreate the error message. Sorry, ignore please. Works well, as expected.

graysky commented on 2015-12-17 12:33 (UTC)

@tetris - Shouldn't have anything to do with deps as everything it needs is already a dep. Not sure why you have an error... is the error keeping kodi from launching since you say, "kodi.service itself seems to run fine" I do not understand. Error = break ; warning = still runs.

tetris11 commented on 2015-12-17 12:26 (UTC)

Upon starting the service I'm getting: Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) The kodi.service itself seems to run fine. My desktop is literally just xinit and metacity, so maybe it's just a complaint about not finding gnome/kde?

graysky commented on 2015-11-21 12:53 (UTC)

@hendry - Your log shows you're running this on an ARM processor. I implicitly defined only i686 and x86_64 for this package because kodi on Arch ARM has its own implementation of the standalone service. Recommend that you remove this package on that device.

hendry commented on 2015-11-21 10:51 (UTC) On my alarm rpi2: 10:44:38 T:1945907792 ERROR: Failed to choose a config 12288 10:44:38 T:1945907792 ERROR: Failed to query native visual id 10:44:38 T:1945907792 ERROR: Failed to find matching visual Any ideas what's that about?

graysky commented on 2015-10-18 19:49 (UTC)

I can't explain. I just tested on a new partition (with kodi-standalone-service in a local repo). After configuring the root passwd, network, etc. and enabling kodi.service, it booted right into it. # pacstrap -i /mnt base sudo kodi-standalone-service xf86-video-intel

bananabrain commented on 2015-10-18 18:47 (UTC)

Sorry for the delay in replying. I still have this problem of being unable to start the kodi service without an Xwrapper.config file in place. Yes, I have the xf86-video-ati driver installed and have used this machine with an X environment in the past without issue. It would be good to know what's missing from a machine with just the basic xorg system and graphics card driver that prevents the kodi service from working as expected, but I haven't been able to work this out for myself. Manually running "systemctl start kodi" puts the following into the journal (time stamps and hostname removed): polkitd[434]: Registered Authentication Agent for unix-process:444:5962 (system bus name :1.6 [/usr/bin/pkttyagent --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) systemd[1]: Started Starts instance of Kodi using xinit. polkitd[434]: Unregistered Authentication Agent for unix-process:444:5962 (system bus name :1.6, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus) systemd[450]: pam_unix(login:session): session opened for user kodi by (uid=0) systemd[1]: Created slice user-420.slice. systemd[1]: Starting User Manager for UID 420... systemd-logind[313]: New session c3 of user kodi. systemd[1]: Started Session c3 of user kodi. systemd[453]: pam_unix(systemd-user:session): session opened for user kodi by (uid=0) systemd[453]: Reached target Timers. systemd[453]: Listening on D-Bus User Message Bus Socket. systemd[453]: Reached target Sockets. systemd[453]: Reached target Paths. systemd[453]: Reached target Basic System. systemd[453]: Reached target Default. systemd[453]: Startup finished in 48ms. systemd[1]: Started User Manager for UID 420.

graysky commented on 2015-09-21 21:44 (UTC)

No, that isn't it. I see on some other minimal boxes that particular driver is not installed. Have you installed a video driver?

graysky commented on 2015-09-21 10:31 (UTC)

Works for me in a fresh VM with just base and the deps plus I had to install a driver. For the VM I used xf86-video-fbdev only. Perhaps this needs to be added to the deps array? Is it present on other full desktops?

OlafLostViking commented on 2015-09-21 09:42 (UTC)

@graysky Unfortunately I have the same problem as @bananabrain. But I can start an X-session as non-root with startx, with xinit it only works as root. So probably the reason for the failure lies "deeper". Some setup steps or packages are missing, perhaps. As I only installed kodi on this system and no other desktop or graphical packages (despite xterm to test X).

graysky commented on 2015-09-20 17:43 (UTC)

@bananabrain - Do you have the needed drivers for video? On my intel system I needed to install xf86-video-intel to get it to work.

bananabrain commented on 2015-09-15 22:22 (UTC)

For no reason I can work out, I can't get this to autostart without the presence of /etc/X11/Xwrapper.config containing "needs_root_rights = yes". Error grep from /var/lib/kodi/.local/share/xorg/Xorg.0.log shows: (EE) Error systemd-logind returned paused fd for drm node (EE) (EE) AddScreen/ScreenInit failed for driver 0 (EE) (EE) (EE) Please also check the log file at "/var/lib/kodi/.local/share xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. I can live with this, but it concerns me that it's clearly stated here that since 1.8-1 the Xwrapper.config file should no longer be needed, which makes me think I've done something wrong. Does anyone have any idea what that might be? Is there any other helpful information I can provide?

graysky commented on 2015-06-04 17:38 (UTC)

It was setup for any but that lead to confusion by ArchARM users since they provide this functionality in their package. The post install scriptlet here will run into problem when the kodi user is on the system already so I gate that by defining the arch as I have.

bjo commented on 2015-06-04 10:01 (UTC)

Please change arch to 'any', because it's only a service file.

gonciarz commented on 2015-04-25 08:54 (UTC)

(1/1) installing kodi-standalone-service [################################################################] 100% groupadd: GID '420' already exists useradd: group 'kodi' does not exist passwd: user 'kodi' does not exist chown: invalid user: ‘kodi:kodi’ error: command failed to execute correctly That may help: usermod -l kodi xbmc groupmod -n kodi xbmc

maggie commented on 2015-04-01 19:31 (UTC)

Works for me.

graysky commented on 2015-04-01 08:45 (UTC)

There is nothing to patch in the package. I think you are confused over what that link means.

graysky commented on 2015-03-24 18:53 (UTC)

@jolan - Which file in this package are you proposing I patch?

graysky commented on 2015-03-15 19:44 (UTC)

If you don't need dhcp for the box, I highly recommend a static configuration. % systemd-analyze blame ... 232ms netctl@wired.service ...

Kalq commented on 2015-03-15 18:25 (UTC)

20.166s dhcpcd@enp1s0.service Yeah, it appears to be a problem with my network and not anything to do with Kodi. Everything else was well below a second.

graysky commented on 2015-03-15 17:55 (UTC)

@Kalq - I haven't seem this before... is the hardware very slow and are you loading up others services that might be taking priority and causing slow booting? Post the output of: systemd-analyze blame

Kalq commented on 2015-03-15 17:12 (UTC)

So for some reason, when I enable kodi.service and reboot. It takes me directly to my login screen on TTY1. At first I thought it wasn't working but after about 30 seconds it automatically switches to Kodi on tty7. Anyway to switch to Kodi immediately on boot?

bjo commented on 2015-03-13 22:04 (UTC)

Permission problems on /var/lib/kodi, added kodi to input. Works again now.

bjo commented on 2015-03-13 21:42 (UTC)

Mär 13 22:39:58 cardium systemd[1]: Starting Starts instance of Kodi using xinit... Mär 13 22:39:58 cardium systemd[1]: Started Starts instance of Kodi using xinit. Mär 13 22:39:58 cardium systemd[23167]: pam_unix(login:session): session opened for user kodi by (uid=0) Mär 13 22:40:13 cardium systemd[1]: kodi.service: main process exited, code=exited, status=1/FAILURE Mär 13 22:40:13 cardium systemd[1]: Unit kodi.service entered failed state. Mär 13 22:40:13 cardium systemd[1]: kodi.service failed.

graysky commented on 2015-03-13 21:38 (UTC)

@bjo - It's a systemd solution... you need to start/stop the service, not the application.

bjo commented on 2015-03-13 21:36 (UTC)

The service doesn't work here any more. Running kodi manually as kodi results in /usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server Putting "allowed_users=anybody" in Xwrapper.config leads to "no permission" on vt7

graysky commented on 2015-02-19 20:06 (UTC)

I will change the arch=any to arch=('x86_64' 'i686') to prevent this from ARM users.

thealchemist commented on 2015-02-19 10:56 (UTC)

Sorry for removing the latest comment, yeah I will go for it :)

thealchemist commented on 2015-02-19 10:54 (UTC)

Ok, now I got it (after comparing both packages "kodi" and "kodi-rbp"myself). And it is not as easy as I hoped in the beginning. So some more testing leads to: - the kodi packages do the same things (concerning no user creation) during install on x86 and ARM and look to be compatible with the package. - on my Rasberry Pi kodi + kodi-standalone-package do not work out of the box (failed with systemd). Did not test on x86. - kodi-rbp works flawless on the RBP - kodi and kodi-rbp both do not depend on xorg-server - installing kodi-standalone-service package above kodi-rbp is possible after removing its integrated kodi.service (it recognizes kodi-rbp as kodi for some reason) - installing it on top of kodi-rbp messes the installation (as said before). - the package does not install if the makepkg file contains "conflicts=('kodi-rbp')" Ok, i think I have learned my lesson, but I think it should be Arch x86 != Arch ARM Arch x86 package == Arch ARM package (roughly, concerning compatibility) kodi-rbp != kodi (!)

graysky commented on 2015-02-19 10:42 (UTC)

Yes, you understand correctly. Also, it's a wiki, go for it.

graysky commented on 2015-02-18 20:37 (UTC)

Arch != Arch ARM. Arch ARM ships their kodi package with, in effect, this already mixed in. Best advice is not use AUR packages on Arch ARCH without understanding if they are supplying similar functionality or identical files.

thealchemist commented on 2015-02-18 15:51 (UTC)

@graysky: I can confirm this, kodi.service works flawless without kodi-standalone-service but I did not get it running with the package. I'm completely new to kodi (only did some research and testing yesterday), but I at the time of writing I cannot find the advantages of this package. I found it as solution in the Wiki. I believe it was needed with previous xbmc but my current kodi-rbp installation (Rasberry Pi 2) works out of the box if I enable kodi.service in systemd. On the other hand I was not able to install this package without messing in my setup manually (removing /usr/lib/systemd/system/kodi.service and setting suid mount option in /var). While installing kodi a user and group named kodi were added (ID 997:997) After installing kodi-standalone-service kodi.service was broken (kodi ID 997:420) and login group was kodi (420) I also do not understand in which way the package is different to the current out of the box behaviour (and maybe outperforms it). But honestly for me it looked like its messing my fresh kodi installations rendering it unusable. Now I do not want to correct the Wiki entry of Kodi, because of my very limited knowledge and because I really respect your work, but I think the Wiki is misleading. I am willing to do some more testing if it is needed.

graysky commented on 2015-01-20 23:50 (UTC)

@Bc - Not sure why. Works fine without that package for multiple systems.

BcTpe4HbIu commented on 2015-01-20 23:29 (UTC)

Could not get it working without xorg-server-utils package. Maybe it should be in dependencies?

graysky commented on 2015-01-11 15:04 (UTC)

Sorry, but I have no experience with Steam to know why that might be happening... this package is functionally no different from the old xbmc-standalone-service. It really just renamed the user xbmc->kodi and the homedir from /var/lib/xbmc->/var/lib/kodi.

rsalvador commented on 2015-01-11 14:29 (UTC)

Hi guys, First of all, great work on this package ;). I have a small issues after updating from the old XBMC to Kodi, I used a Steam Launcher addin and it now it is not working. The plugin has two options, either kill Kodi and Lauch steam or leave Kodi open an just open steam over it. The first option causes Kodi to restart over steam, the second option Steam start correctly but it does not have keyboard focus, it is still on Kodi. Do you guys have any suggestions? Thanks a lot!

graysky commented on 2015-01-04 20:29 (UTC)

Bump to v1.8-1 Changelog: Now, kodi.serivce no longer requires /etc/X11/Xwrapper.config to function. Commit:

graysky commented on 2015-01-04 00:30 (UTC)

Bump to v1.7-1 Changelog: Kill xbmc.service if running or else removal of xbmc is not possible. Commit:

graysky commented on 2015-01-03 15:10 (UTC)

Bump to v1.6-1 Changelog: Removed unneeded workaround for pulseaudio to init (release kodi seems to have fixed it). Commit:

graysky commented on 2014-11-22 08:44 (UTC)

I think that's best left to the user. The wiki is inconsistent on this point anyway.

jswagner commented on 2014-11-22 04:21 (UTC)

Can this also provide the systemd .socket file, as documented here?:

graysky commented on 2014-11-15 10:21 (UTC)

I just took that dep out all together. No big deal for now.

jswagner commented on 2014-11-15 07:46 (UTC)

I made this work with 'kodi-beta' by changing "kodi>=14.0-1" to "kodi-beta>=14.0b2-1". I'm sure there's a more elegant way to make do that, but it was enough to get me going. It doesn't seem like this will work for either 'kodi-devel' or 'kodi-beta', since both provide "xbmc", not "kodi".