+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: Headless Kodi (/showthread.php?tid=212061)
RE: Headless Kodi - isamudaison - 2016-08-09
I've set this all up and have tried running headless kodi with the 'autoupdate' add-on, but in the kodi log this appears:
Log
I've copied the .kodi data from a working instance (with the auto update plugin) so I'm not really sure what to look for here... Any suggestions? (Also, Kodi doesn't appear to actually be running in the docker container).
[Edit] Well that's weird, I tried restarting it and now it's working... *shrug*
RE: Headless Kodi - shred00 - 2016-08-10
Is there any reason an external patch is being maintained for headless mode rather than just having that merged into the official Kodi repo?
That way everyone can have headless mode if they want without having to patch and build from source every time.
RE: Headless Kodi - marantz - 2016-08-11
the patch from master doesnt apply to kodi master (krypton) anymore
RE: Headless Kodi - sparklyballs - 2016-08-11
(2016-08-11, 23:08)marantz Wrote: the patch from master doesnt apply to kodi master (krypton) anymore
give this a try, it's a bit rough and ready, i just manually made the changes to an existing patch.
https://github.com/sparklyballs/docker-kodi-headless/blob/Krypton/patches/Krypton/headless.patch
RE: Headless Kodi - marantz - 2016-08-11
(2016-08-11, 23:11)sparklyballs Wrote:(2016-08-11, 23:08)marantz Wrote: the patch from master doesnt apply to kodi master (krypton) anymore
give this a try, it's a bit rough and ready, i just manually made the changes to an existing patch.
https://github.com/sparklyballs/docker-kodi-headless/blob/Krypton/patches/Krypton/headless.patch
wow, that was Lucky Luke fast, worked fine. Thanks
RE: Headless Kodi - shred00 - 2016-08-12
(2016-08-11, 23:08)marantz Wrote: the patch from master doesnt apply to kodi master (krypton) anymore
This would be another good reason to get the patch upstream. Changes to the code around it would take into consideration the headless code.
It has been said elsewhere that the patch is just a hack and that a more proper solution needs to be developed.
I would suggest that perhaps that is the case, but until the more proper solution comes around, surely the hack is sufficient for the time being, not letting the perfect become the enemy of the good. It doesn't look very invasive after-all and should be easily maintainable until the more proper solution is developed.
The patch is clearly useful for a subset of people or it wouldn't exist nor would this thread with 23 pages in just a year and a half. It would be useful to see it upstream I think.
RE: Headless Kodi - celedhrim - 2016-08-14
Hello,
I have switch to LibreELEC (Krypton) v7.90.004 ALPHA so docker headless has now a krypton branch with alpha3:
https://github.com/Celedhrim/docker-kodi-server/tree/krypton
Image on docker hub is ready
docker pull celedhrim/kodi-server:krypton
RE: Headless Kodi - Paranoidjack - 2016-08-28
There seems to be an issue with all docker containers running Kodi (jarvis)
Code:
15:00:45 T:140241308773040 DEBUG: Thread FileCache 140241308773040 terminating
15:00:45 T:140241317493424 DEBUG: CurlFile::Open(0x7f8c79e96960) http://mirrors.kodi.tv/addons/jarvis/addons.xml.gz
15:00:45 T:140241317493424 DEBUG: CCurlFile::Open - effective URL: <http://ftp.halifax.rwth-aachen.de/xbmc/addons/jarvis/addons.xml.gz>
15:00:46 T:140241317493424 DEBUG: CRepository 'http://mirrors.kodi.tv/addons/jarvis/addons.xml.gz' is gzip. decompressingFull log: http://pastebin.com/eMnah0j1
After this Kodi crashes and continues to loop.
I presume a recent change within addons.xml is the reason.
On further investigation:
I redirected "mirrors.kodi.tv" to 0.0.0.0 and started the container - it boots without any errors and removing the redirection this behaviour continued.
I wanted to confirm that addons.xml was the culprit so I deleted Addons20.db and rebooted the container with no redirections - the crashing behaviour returned.
RE: Headless Kodi - isamudaison - 2016-08-30
(2016-08-28, 17:09)Paranoidjack Wrote: There seems to be an issue with all docker containers running Kodi (jarvis)
Code:15:00:45 T:140241308773040 DEBUG: Thread FileCache 140241308773040 terminating
15:00:45 T:140241317493424 DEBUG: CurlFile::Open(0x7f8c79e96960) http://mirrors.kodi.tv/addons/jarvis/addons.xml.gz
15:00:45 T:140241317493424 DEBUG: CCurlFile::Open - effective URL: <http://ftp.halifax.rwth-aachen.de/xbmc/addons/jarvis/addons.xml.gz>
15:00:46 T:140241317493424 DEBUG: CRepository 'http://mirrors.kodi.tv/addons/jarvis/addons.xml.gz' is gzip. decompressing
Full log: http://pastebin.com/eMnah0j1
After this Kodi crashes and continues to loop.
I presume a recent change within addons.xml is the reason.
On further investigation:
I redirected "mirrors.kodi.tv" to 0.0.0.0 and started the container - it boots without any errors and removing the redirection this behaviour continued.
I wanted to confirm that addons.xml was the culprit so I deleted Addons20.db and rebooted the container with no redirections - the crashing behaviour returned.
I've noticed this as well, very frustrating!
RE: Headless Kodi - joelones - 2016-08-30
As a workaround I got it to stop crashing by copying Addons20.db from my 16.1 Mac OS X box and set the below to 2 in guisettings.xml to prevent addon updates:
Code:
<addonupdates>2</addonupdates>Not pretty, but for now it'll do.
RE: Headless Kodi - mrsdoubtfire613 - 2016-09-03
Ok, if this is the wrong place, correct me with whatever attitude you see fit.
I just installed (and since, reinstalled) linuxserver's headless kodi container in unRaid connecting to a (fresh, empty) mariaDB container. I keep receiving "connection refused" errors when trying to access the webgui. I pulled the logs and i see that the webserver starts, begins listening on the UDP port, but then immediately crashes. I am able to occasionally catch it when it's on and couchpotato can send a test notification and return successful but it stops right away. Any clue as to what is wrong? Is this related to what everyone else is experiencing? My log is below, if that helps.
Clarity: This is running as a Docker in unRaid 6.1.9.
Logs
-Philip
RE: Headless Kodi - joelones - 2016-09-03
(2016-09-03, 04:26)mrsdoubtfire613 Wrote: Ok, if this is the wrong place, correct me with whatever attitude you see fit.
I just installed (and since, reinstalled) linuxserver's headless kodi container in unRaid connecting to a (fresh, empty) mariaDB container. I keep receiving "connection refused" errors when trying to access the webgui. I pulled the logs and i see that the webserver starts, begins listening on the UDP port, but then immediately crashes. I am able to occasionally catch it when it's on and couchpotato can send a test notification and return successful but it stops right away. Any clue as to what is wrong? Is this related to what everyone else is experiencing? My log is below, if that helps.
Clarity: This is running as a Docker in unRaid 6.1.9.
Logs
-Philip
I'm pretty sure it's the same issue concerning the downloaded addons.xml.gz which is causing kodi-headless to loop endlessly - hence the connection refused error you're getting. I posted a workaround two posts above, which at least for me, stopped the looping. Similar setup as you.
RE: Headless Kodi - NeS_BCN - 2016-09-06
Hello,
I have the exact same problem with the kodi-headless docker container from linuxserver.io
But, I had to copy the Addons20.db from a working & recently updated, non-container, kodi instance for it to work. Previously I had unsuccessfully tried with an addons20.db file from a container backup in June.
Thanks for your help, hopefully it will be resolved soon.
RE: Headless Kodi - Saidou - 2016-09-07
I'm using the Celedhrim image for some months know on my Synology DS412+ (DSM5.2) without any problems, but suddenly it started crashing, just after I start the docker container.
The log says:
Code:
00:13:43 libnfs error: Socket closed stdout
00:13:44 stdout
00:13:44 libnfs error: NFS: MKDIR of //playlists failed with NFS3ERR_EXIST(-17) stdout
00:13:44 libnfs error: NFS: MKDIR of /playlists/music failed with NFS3ERR_EXIST(-17) stdout
00:13:44 libnfs error: NFS: MKDIR of /playlists/video failed with NFS3ERR_EXIST(-17) stdout
00:13:44 libnfs error: NFS: MKDIR of /playlists/mixed failed with NFS3ERR_EXIST(-17) stdout
00:14:20 libnfs error: Socket closed stdout
00:14:20 stdout
00:14:20 libnfs error: NFS: MKDIR of //playlists failed with NFS3ERR_EXIST(-17) stdout
00:14:20 libnfs error: NFS: MKDIR of /playlists/music failed with NFS3ERR_EXIST(-17) stdout
00:14:20 libnfs error: NFS: MKDIR of /playlists/video failed with NFS3ERR_EXIST(-17) stdout
00:14:20 libnfs error: NFS: MKDIR of /playlists/mixed failed with NFS3ERR_EXIST(-17) stdoutIs this causing the crash? I'm sharing the playlists over the network (advancedsetings.xml - path substitution), but even when I remove the line, I get the same error.
Can some one help?
Thanks
RE: Headless Kodi - whiskaz - 2016-09-10
(2016-08-30, 19:55)joelones Wrote: As a workaround I got it to stop crashing by copying Addons20.db from my 16.1 Mac OS X box and set the below to 2 in guisettings.xml to prevent addon updates:
Code:<addonupdates>2</addonupdates>
Not pretty, but for now it'll do.
Thanks for this! I had been fighting with my Kodi headless install restarting... this did the trick. Of course it came post-system upgrade so I wasn't sure what to blame. Occasionally starting the service with no profile available (and generating a new one from scratch), things would run OK for a bit but then choke after a couple of days.