[topfs2]

I've recently been trying to gather up some patches and fix those things that depend on the gui in kodi so that we may at one point have a headless version of Kodi.

In general my goal is to split out my efforts over multiple PRs so that master gets better and better.
But for those interested I have pulled in all needed patches for my initial headless version of kodi on a base of Helix. Which can be found over at my repository https://github.com/topfs2/xbmc/tree/helix_headless

The initial attempt here is not to compile down a stripped version of kodi just for headless use, but rather to disable the gui on start. This means that it can replace a Helix and if its headless or not is only choosen via the startup argument --headless.

When headless uPnP and Webserver are default to on, as what point is headless if you can't connect to it

To run after compile simply

/path/to/kodi --headless

Please let me know of any bugs and crashes when running in headless so we can get headless into master ASAP!

TODO

• Fix param parsing on windows #33
  
• Fix "Can't open display" #15
  

Cheers,
Tobias

[sparklyballs]

I've recently been trying to gather up some patches and fix those things that depend on the gui in kodi so that we may at one point have a headless version of Kodi.

In general my goal is to split out my efforts over multiple PRs so that master gets better and better.
But for those interested I have pulled in all needed patches for my initial headless version of kodi on a base of Helix. Which can be found over at my repository https://github.com/topfs2/xbmc/tree/helix_headless

The initial attempt here is not to compile down a stripped version of kodi just for headless use, but rather to disable the gui on start. This means that it can replace a Helix and if its headless or not is only choosen via the startup argument --headless.

When headless uPnP and Webserver are default to on, as what point is headless if you can't connect to it

To run after compile simply

/path/to/kodi --headless

Please let me know of any bugs and crashes when running in headless so we can get headless into master ASAP!

Cheers,
Tobias

Could this be dockerised as there is a lot of interest on this over on the unraid forum as they have a docker base in the beta of uraid 6 and unraid and xbmc have been happy bedfellows for a long time.

---

ignore my silly question, lol.
it's a branch of source, got confused and thought it was something else.

just about to run a build.

---

ignore my silly question, lol.
it's a branch of source, got confused and thought it was something else.

just about to run a build.

---

my configure options,

./configure \
--enable-nfs \
--enable-upnp \
--enable-ssh \
--enable-libbluray \
--disable-debug \
--disable-vdpau \
--disable-vaapi \
--disable-crystalhd \
--disable-vdadecoder \
--disable-vtbdecoder \
--disable-openmax \
--disable-joystick \
--disable-rsxs \
--disable-projectm \
--disable-rtmp \
--disable-airplay \
--disable-airtunes \
--disable-dvdcss \
--disable-optical-drive \
--disable-libusb \
--disable-libcec \
--disable-libmp3lame \
--disable-libcap \
--disable-udev \
--disable-libvorbisenc \
--disable-asap-codec \
--disable-afpclient \
--disable-goom \
--disable-fishbmc \
--disable-spectrum \
--disable-waveform \
--disable-avahi \
--disable-non-free \
--disable-texturepacker \
--disable-pulse \
--disable-dbus \
--disable-alsa \
--disable-hal && \


do these look good to you ? anything else to disable, my personal choice is for bluray enabled as i have a lot of bluray rips.

[sparklyballs]

I've recently been trying to gather up some patches and fix those things that depend on the gui in kodi so that we may at one point have a headless version of Kodi.

In general my goal is to split out my efforts over multiple PRs so that master gets better and better.
But for those interested I have pulled in all needed patches for my initial headless version of kodi on a base of Helix. Which can be found over at my repository https://github.com/topfs2/xbmc/tree/helix_headless

The initial attempt here is not to compile down a stripped version of kodi just for headless use, but rather to disable the gui on start. This means that it can replace a Helix and if its headless or not is only choosen via the startup argument --headless.

When headless uPnP and Webserver are default to on, as what point is headless if you can't connect to it

To run after compile simply

/path/to/kodi --headless

Please let me know of any bugs and crashes when running in headless so we can get headless into master ASAP!

Cheers,
Tobias

is there a default port for the webserver (8080 presumably) and/or can it be set by advancedsettings.xml file ?

[sparklyballs]

Apologies if this has already been covered but can i make a suggestion if it hasn't ?


Seeing as a current use for headless version of kodi is in a mysql setup (i know it's gonna be phased out at some stage) and the only current way to change those settings is through advancedsettings.xml, can one be generated with a headless install by default so it just needs editing to suit.

[xexe]

What is the purpose of server.xml?

[jjd-uk]

Apologies if this has already been covered but can i make a suggestion if it hasn't ?


Seeing as a current use for headless version of kodi is in a mysql setup (i know it's gonna be phased out at some stage) and the only current way to change those settings is through advancedsettings.xml, can one be generated with a headless install by default so it just needs editing to suit.

That's not right, all settings can be changed via JSON-RPC however that's not very end user friendly, and not many of the remote app & webui app devs have picked up on this, the only one might be the official iOS remote app. Settings management via JSON is something we should perhaps promote more in preparation for headless.

[sparklyballs]

Apologies if this has already been covered but can i make a suggestion if it hasn't ?


Seeing as a current use for headless version of kodi is in a mysql setup (i know it's gonna be phased out at some stage) and the only current way to change those settings is through advancedsettings.xml, can one be generated with a headless install by default so it just needs editing to suit.

That's not right, all settings can be changed via JSON-RPC however that's not very end user friendly, and not many of the remote app & webui app devs have picked up on this, the only one might be the official iOS remote app. Settings management via JSON is something we should perhaps promote more in preparation for headless.

I wasn't aware that it could be changed through JSON, but definitely agree on the not very user friendly aspect.

I do hope that the advancedsettings.xml file will still be read, (if not created) or a default webui baked in will give us access to change various settings etc....

whilst if settings were possible through 3rd party apps, i think it would be inifinitely more preferalbe to be able to do it "inhouse" easily without any reliance on 3rd party stuff.

[sparklyballs]

Apologies if this has already been covered but can i make a suggestion if it hasn't ?


Seeing as a current use for headless version of kodi is in a mysql setup (i know it's gonna be phased out at some stage) and the only current way to change those settings is through advancedsettings.xml, can one be generated with a headless install by default so it just needs editing to suit.

That's not right, all settings can be changed via JSON-RPC however that's not very end user friendly, and not many of the remote app & webui app devs have picked up on this, the only one might be the official iOS remote app. Settings management via JSON is something we should perhaps promote more in preparation for headless.

I wasn't aware that it could be changed through JSON, but definitely agree on the not very user friendly aspect.

I do hope that the advancedsettings.xml file will still be read, (if not created) or a default webui baked in will give us access to change various settings etc....

whilst if settings were possible through 3rd party apps, i think it would be inifinitely more preferalbe to be able to do it "inhouse" easily without any reliance on 3rd party stuff.

Although, and this is purely from my personal perspective, this JSON setting up of mysql settings could be something i could make use of in a docker for unraid, and on that i have some questions.

can JSON take variables cos i could pass them through from template based docker app on unraid and then not worry about user-friendiless at all.

what are the JSON "commands" (don't know the proper term) to change mysql settings, ip, port, user, pass, etc.....

and lastly, although not directly related to this, what is a good test that kodi.bin is up and ready to accept JSON etc.... cos of the way docker works would need to know this before attempting to pass commands to it, currently i just sleep for 45 seconds before sed'ing advancedsettings.xml. it's not very elegant.

[topfs2]

What is the purpose of server.xml?

It contains override settings which are in effect when you run in headless mode, so it probably should be named headless.xml

I've recently been trying to gather up some patches and fix those things that depend on the gui in kodi so that we may at one point have a headless version of Kodi.

In general my goal is to split out my efforts over multiple PRs so that master gets better and better.
But for those interested I have pulled in all needed patches for my initial headless version of kodi on a base of Helix. Which can be found over at my repository https://github.com/topfs2/xbmc/tree/helix_headless

The initial attempt here is not to compile down a stripped version of kodi just for headless use, but rather to disable the gui on start. This means that it can replace a Helix and if its headless or not is only choosen via the startup argument --headless.

When headless uPnP and Webserver are default to on, as what point is headless if you can't connect to it

To run after compile simply

/path/to/kodi --headless

Please let me know of any bugs and crashes when running in headless so we can get headless into master ASAP!

Cheers,
Tobias

Could this be dockerised as there is a lot of interest on this over on the unraid forum as they have a docker base in the beta of uraid 6 and unraid and xbmc have been happy bedfellows for a long time.

---

ignore my silly question, lol.
it's a branch of source, got confused and thought it was something else.

just about to run a build.

---

ignore my silly question, lol.
it's a branch of source, got confused and thought it was something else.

just about to run a build.

---

my configure options,

./configure \
--enable-nfs \
--enable-upnp \
--enable-ssh \
--enable-libbluray \
--disable-debug \
--disable-vdpau \
--disable-vaapi \
--disable-crystalhd \
--disable-vdadecoder \
--disable-vtbdecoder \
--disable-openmax \
--disable-joystick \
--disable-rsxs \
--disable-projectm \
--disable-rtmp \
--disable-airplay \
--disable-airtunes \
--disable-dvdcss \
--disable-optical-drive \
--disable-libusb \
--disable-libcec \
--disable-libmp3lame \
--disable-libcap \
--disable-udev \
--disable-libvorbisenc \
--disable-asap-codec \
--disable-afpclient \
--disable-goom \
--disable-fishbmc \
--disable-spectrum \
--disable-waveform \
--disable-avahi \
--disable-non-free \
--disable-texturepacker \
--disable-pulse \
--disable-dbus \
--disable-alsa \
--disable-hal && \


do these look good to you ? anything else to disable, my personal choice is for bluray enabled as i have a lot of bluray rips.

The intent of my branch is to run without any disables, i.e. a fully functional kodi but with the GUI disabled. So its fully possible to play music on it etc.
This is because we/I am aiming towards platforms were GUI is available but you might not want to run it. For example if you have kodi installed on your windows box it could potentially always boot up in headless mode, starting kodi via menu would simply trigger the GUI creation and "exit" would mean that it simply closes the GUI while headless remains. Much like how steams big picture behaves.

However, in a NAS environment it will always be beneficial to disable, as there is never a GUI available, and packages with gui makes no sense. But thats not my personal main goal, as that should be very possible to do no matter.

[sparklyballs]

What is the purpose of server.xml?

It contains override settings which are in effect when you run in headless mode, so it probably should be named headless.xml

I've recently been trying to gather up some patches and fix those things that depend on the gui in kodi so that we may at one point have a headless version of Kodi.

In general my goal is to split out my efforts over multiple PRs so that master gets better and better.
But for those interested I have pulled in all needed patches for my initial headless version of kodi on a base of Helix. Which can be found over at my repository https://github.com/topfs2/xbmc/tree/helix_headless

The initial attempt here is not to compile down a stripped version of kodi just for headless use, but rather to disable the gui on start. This means that it can replace a Helix and if its headless or not is only choosen via the startup argument --headless.

When headless uPnP and Webserver are default to on, as what point is headless if you can't connect to it

To run after compile simply

Please let me know of any bugs and crashes when running in headless so we can get headless into master ASAP!

Cheers,
Tobias

Could this be dockerised as there is a lot of interest on this over on the unraid forum as they have a docker base in the beta of uraid 6 and unraid and xbmc have been happy bedfellows for a long time.

---

ignore my silly question, lol.
it's a branch of source, got confused and thought it was something else.

just about to run a build.

---

ignore my silly question, lol.
it's a branch of source, got confused and thought it was something else.

just about to run a build.

---

my configure options,

./configure \
--enable-nfs \
--enable-upnp \
--enable-ssh \
--enable-libbluray \
--disable-debug \
--disable-vdpau \
--disable-vaapi \
--disable-crystalhd \
--disable-vdadecoder \
--disable-vtbdecoder \
--disable-openmax \
--disable-joystick \
--disable-rsxs \
--disable-projectm \
--disable-rtmp \
--disable-airplay \
--disable-airtunes \
--disable-dvdcss \
--disable-optical-drive \
--disable-libusb \
--disable-libcec \
--disable-libmp3lame \
--disable-libcap \
--disable-udev \
--disable-libvorbisenc \
--disable-asap-codec \
--disable-afpclient \
--disable-goom \
--disable-fishbmc \
--disable-spectrum \
--disable-waveform \
--disable-avahi \
--disable-non-free \
--disable-texturepacker \
--disable-pulse \
--disable-dbus \
--disable-alsa \
--disable-hal && \


do these look good to you ? anything else to disable, my personal choice is for bluray enabled as i have a lot of bluray rips.

The intent of my branch is to run without any disables, i.e. a fully functional kodi but with the GUI disabled. So its fully possible to play music on it etc.
This is because we/I am aiming towards platforms were GUI is available but you might not want to run it. For example if you have kodi installed on your windows box it could potentially always boot up in headless mode, starting kodi via menu would simply trigger the GUI creation and "exit" would mean that it simply closes the GUI while headless remains. Much like how steams big picture behaves.

However, in a NAS environment it will always be beneficial to disable, as there is never a GUI available, and packages with gui makes no sense. But thats not my personal main goal, as that should be very possible to do no matter.

I ran my build last night and had a little explore with it earlier, not certain if it is a vagary of docker but i had to start it, let it run for a few minutes and then stop/start it again before i could get the web interface and ping it from sickbeard etc...

That aside though, it seems stable when browsing music in the web app which in headless trips it up sometimes.

[jjd-uk]

whilst if settings were possible through 3rd party apps, i think it would be inifinitely more preferalbe to be able to do it "inhouse" easily without any reliance on 3rd party stuff.

That is part of the plan I believe.

The author of the Chorus webui has joined the Team with the aim of using it as a basis of a new default webui, as part of this we also want the settings management, however lack of time has been an issue in getting this done.

[sparklyballs]

I've recently been trying to gather up some patches and fix those things that depend on the gui in kodi so that we may at one point have a headless version of Kodi.

In general my goal is to split out my efforts over multiple PRs so that master gets better and better.
But for those interested I have pulled in all needed patches for my initial headless version of kodi on a base of Helix. Which can be found over at my repository https://github.com/topfs2/xbmc/tree/helix_headless

The initial attempt here is not to compile down a stripped version of kodi just for headless use, but rather to disable the gui on start. This means that it can replace a Helix and if its headless or not is only choosen via the startup argument --headless.

When headless uPnP and Webserver are default to on, as what point is headless if you can't connect to it

To run after compile simply

/path/to/kodi --headless

Please let me know of any bugs and crashes when running in headless so we can get headless into master ASAP!

Cheers,
Tobias

i've just made a separate ubuntu 14.04 VM specfically for playing with kodi builds and i'm gonna use it for this first , as far as dependencies go should i be looking to the kodi ppa and installing build-dep or getting the dependencies seperately ?

[wsnipex]

you can use build-dep if you add the ppa with add-apt-repository -s

[Woerd88]

Very interesting feature, topfs2
I was think about the android platform:
Would it be possible to run kodi as a service, and run the gui in an activity?
This would improve listening to music on a android device in the background, because with the current architecture the playback stops when you leave kodi.

[pgjensen]

Steps I took to get this working:

1) cd
2) git clone https://github.com/topfs2/xbmc.git kodi-helix-headless
3) cd kodi-helix-headless/
4) git checkout helix_headless
5) ./bootstrap
6) ./configure --prefix=/opt/kodi-helix-headless/
7) make
8) sudo make install
9) /opt/kodi-helix-headless/lib/kodi/kodi.bin --headless &
Can't open display

** keeps running! **