Login at Kodi Home

**isamudaison** · (This post was last modified: 2016-08-09, 05:01 by isamudaison.)

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*

shred00 · 2016-08-10, 13:55

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.

marantz · 2016-08-11, 23:08

the patch from master doesnt apply to kodi master (krypton) anymore

sparklyballs · 2016-08-11, 23: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-k...less.patch

marantz · 2016-08-11, 23:14

(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-k...less.patch

wow, that was Lucky Luke fast, worked fine. Thanks

shred00 · 2016-08-12, 17:00

(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.

celedhrim · 2016-08-14, 09:05

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...ee/krypton

Image on docker hub is ready

docker pull celedhrim/kodi-server:krypton

Paranoidjack · (This post was last modified: 2016-08-30, 14:04 by Paranoidjack.)

There seems to be an issue with all docker containers running Kodi (jarvis)

Code:
00:45 T:140241308773040   DEBUG: Thread FileCache 140241308773040 terminating

00:45 T:140241317493424   DEBUG: CurlFile::Open(0x7f8c79e96960) http://mirrors.kodi.tv/addons/jarvis/addons.xml.gz

00:45 T:140241317493424   DEBUG: CCurlFile::Open - effective URL: <http://ftp.halifax.rwth-aachen.de/xbmc/addons/jarvis/addons.xml.gz>

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.

**isamudaison** · 2016-08-30, 19:43

(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!

joelones · 2016-08-30, 19:55

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.

mrsdoubtfire613 · 2016-09-03, 04:26

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

joelones · (This post was last modified: 2016-09-03, 15:39 by joelones.)

(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.

NeS_BCN · 2016-09-06, 12:53

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.

Saidou · (This post was last modified: 2016-09-07, 15:29 by Saidou.)

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:
13:43        libnfs error: Socket closed                                                        stdout

13:44                                                                                            stdout

13:44        libnfs error: NFS: MKDIR of //playlists failed with NFS3ERR_EXIST(-17)            stdout

13:44        libnfs error: NFS: MKDIR of /playlists/music failed with NFS3ERR_EXIST(-17)        stdout

13:44        libnfs error: NFS: MKDIR of /playlists/video failed with NFS3ERR_EXIST(-17)        stdout

13:44        libnfs error: NFS: MKDIR of /playlists/mixed failed with NFS3ERR_EXIST(-17)        stdout

14:20        libnfs error: Socket closed                                                        stdout

14:20                                                                                            stdout

14:20        libnfs error: NFS: MKDIR of //playlists failed with NFS3ERR_EXIST(-17)            stdout

14:20        libnfs error: NFS: MKDIR of /playlists/music failed with NFS3ERR_EXIST(-17)        stdout

14:20        libnfs error: NFS: MKDIR of /playlists/video failed with NFS3ERR_EXIST(-17)        stdout

14:20        libnfs error: NFS: MKDIR of /playlists/mixed failed with NFS3ERR_EXIST(-17)        stdout

Is 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

whiskaz · 2016-09-10, 16:18

(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.