+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Supplementary Tools for Kodi (https://forum.kodi.tv/forumdisplay.php?fid=116)
+--- Thread: Release Kodi/XBMC Callback Daemon (/showthread.php?tid=194910)
Kodi/XBMC Callback Daemon - pdffs - 2014-05-12
UPDATE v1.1.0: Now with LIFX support, for the full cinema experience.
A small Go daemon that reads notifications from Kodi/XBMC via the JSON-RPC socket, and performs actions based on those notifications.
I wrote this primarily because the Python callback interface can get blocked very easily by any add-on, which results in heavy delays getting callbacks executed (for example, using the service.xbmc.callbacks plugin), whereas notifications are shipped over the JSON interface immediately.
This is not an issue with service.xbmc.callbacks (good work pilluli!), but with the Kodi add-on infrastructure, and with other individual add-ons.
This daemon also aims to provide more flexibility. The targeted backends are hyperion, kodi, lifx and shell.
Upgrading to v1.0.0
Due to the name change to keep in line with XBMC's new name Kodi, if you have the previous package installed as xbmc-callback-daemon, you should uninstall it before installing the new kodi-callback-daemon. The init scripts should handle your existing /etc/xbmc-callback-daemon.json config file, but you're encouraged to move this to the new location /etc/kodi-callback-daemon.json as this feature may go away in future to avoid confusion.
Backends
Hyperion
The Hyperion backend submits callbacks via the JSON interface. This interface is also used by the hyperion-remote command-line utility. There's no end-user documentation for this interface, so when writing callbacks, your best bet is to simply read the JSON schemas in the source tree.
Kodi
The Kodi backend submits callbacks via the JSON-RPC interface. There is excellent documentation available in the Kodi wiki.
LIFX
The LIFX backend submits callbacks via the LIFX LAN protocol.
Shell
The shell backend simply executes a command on the system with specified arguments.
Installation
Grab the Latest Release as a compiled binary and either install it using your package manager (Debian/Ubuntu/derivs, via the .deb package), or extract kodi-callback-daemon to somewhere on your path (eg - /usr/local/bin) on Linux/OSX/FreeBSD, or where ever on Windows.
Alternatively, you make clone this repository and build it yourself.
Usage
See the GitHub repository for usage, configuration details and further information.
RE: XBMC Callback Daemon - richardkemp - 2014-09-05
Hi! Thanks for making this public. I can't get it to work though. When I run the daemon from a terminal it replies that it has connected - which it does not do if xbmc isn't running. Working so far.
However, my intended commands are never run. Could you check my config file please?
OnPlay command is a test to see if echo works, OnStop is a script which I actually want to run. Neither works.
Code:
cat .xbmc-callback-daemon.config.json
{
"xbmc": {
"address": "127.0.0.1",
"port": 9262
},
"debug": true,
"callbacks": {
"Player.OnPlay": [
{
"backend": "shell",
"background": false,
"command": "echo ee > /home/rich/xbmc"
}
],
"Player.OnStop": [
{
"backend": "shell",
"background": true,
"command": "/home/rich/bin/xbmc_OnStop"
}
]
}
}Edit: I couldn't find the log, or any info on github about where logs are saved to.
RE: XBMC Callback Daemon - pdffs - 2014-09-06
Hi Richard, the config looks alright, you've changed the JSON-RPC port in XBMC to 9262 (from the default 9090)?
There isn't a log file, logging happens on stdout. How are you starting the daemon? Let me know and I can tell you how to redirect it to a file, otherwise you can just run it from a terminal and post the output.
EDIT: Actually, your echo test won't work - you need to split arguments out to the 'arguments' array property, like this example:
Code:
{
"backend": "shell",
"background": true,
"command": "/bin/echo",
"arguments": [
"-e",
"The 'arguments' property is optional\n"
]
}And you can't redirect the output like that (you'd need to stick that inside a script and call the script from the config).
None of that should stop your Player.OnStop callback from firing though. Is /home/rich/bin/xbmc_OnStop executable (chmod +x /home/rich/bin/xbmc_OnStop)?
RE: XBMC Callback Daemon - richardkemp - 2014-09-06
Thanks for your reply. xbmc_OnStop script is executable, it works when run from the terminal. I misread your comment about arguments, I thought by 'optional' you meant you could provide arguments in either manner.
9262 is the port I can access the web interface at (settings/services/webserver), and the port my android remote (Yatse) connects via. I haven't changed the json-rpc port in advancedsettings.xml.
Curiously the daemon reports (when run via the terminal) that it has connected to XBMC when connecting either on 9262 or 9090, but it doesn't actually work on either port.
After changing the OnPlay command to correctly use arguments, it doesn't run still. Even though debug is on, nothing shows in the terminal after
Code:
[INFO] Connected to XBMCRE: XBMC Callback Daemon - pdffs - 2014-09-06
You want to use port 9090 - that's the JSON-RPC port. I should probably send a ping to XBMC to make sure it's connected to the right port, currently it just connects and waits for events to show up. Make sure you have both the options 'Allow programs on this system to control XBMC' and 'Allow programs on other systems to control XBMC' enabled under 'System Settings' -> 'Network' -> 'Remote Control' (I don't understand why the second one is required, but it seems to be). Apparently I forgot to add this to the README, I'll update that.
RE: XBMC Callback Daemon - richardkemp - 2014-09-06
Both of those have been enabled from the start, I'm currently testing with 9090 but still no response. What should I look for in xbmc debug logs to verify it is sending notifications? Or, is there any better way to check this?
RE: XBMC Callback Daemon - pdffs - 2014-09-06
I've uploaded a new release to Github that does a version check on startup to make sure we're on a supported version, and connected to the raw JSON-RPC socket. It also implements the XBMC backend, though I don't have a use for it currently. There were some pretty big changes under the hood, but it all appears to be working here.
EDIT: To see if XBMC is emitting notifications, you can just telnet to the port, and you should see them if it's working:
Code:
telnet localhost 9090RE: XBMC Callback Daemon - richardkemp - 2014-09-06
Short version, it's now working - thanks for your help!
I noticed a few things - when I disabled and re-enabled the remote control checkboxes in xbmc settings it gave an error saying unable to start or something similar. I wondered if there was some sort of issue with the port being busy so checked and found multiple copies of the daemon running - I assume this is because I had added it to xbmc's autoexec.py so it started every time xbmc started, but was never closed again. After closing them all and running the new version, I see debug notifications in the terminal and my scripts are executed. Thank you again!
RE: XBMC Callback Daemon - richardkemp - 2014-11-08
I've had some troubles trying to use 0.3.0 after reinstalling my OS. I use arch linux x64 on an Intel i3 - I though initially I had the wrong download but neither of the linux ones (didn't try arm obviously) worked for me. Symptoms are high (~10%) idle cpu usage and (maybe) the program eventually crashes or quits.
So, I tried to download and compile myself. I'm a software developer but haven't tried go before. I executed 'go get github.com/pdf/xbmc-callback-daemon' and got the following error:
can't load package: package github.com/pdf/xbmc-callback-daemon: case-insensitive import collision: "github.com/StreamBoat/xbmc_jsonrpc" and "github.com/streamboat/xbmc_jsonrpc"
Any suggestions? I was successfully using 0.2.2 before.
RE: XBMC Callback Daemon - pdffs - 2014-11-09
(2014-11-08, 22:35)richardkemp Wrote: I've had some troubles trying to use 0.3.0 after reinstalling my OS. I use arch linux x64 on an Intel i3 - I though initially I had the wrong download but neither of the linux ones (didn't try arm obviously) worked for me. Symptoms are high (~10%) idle cpu usage and (maybe) the program eventually crashes or quits.
So, I tried to download and compile myself. I'm a software developer but haven't tried go before. I executed 'go get github.com/pdf/xbmc-callback-daemon' and got the following error:
can't load package: package github.com/pdf/xbmc-callback-daemon: case-insensitive import collision: "github.com/StreamBoat/xbmc_jsonrpc" and "github.com/streamboat/xbmc_jsonrpc"
Any suggestions? I was successfully using 0.2.2 before.
Ah, 0.3.0 was a pretty big refactor - I extracted the XBMC client out for another project. I have been using it fine though for a long time. The build error you're seeing there is from some new validation in Go 1.3. I've fixed that, and built 0.4.0, though that shouldn't be causing the issue you're seeing.
The reconnect logic did get a bit of a rework in the extraction I think, so maybe that has something to do with it. Can you pastebin the output (from 0.4.0) of running the daemon with debug enabled?
Also, are you running this on Debian/Ubuntu/XBMCbuntu, or something else? I ask because the deb packages (now) include init scripts which will handle running this for you, and on Ubuntu/XBMCbuntu you'll then find logs under /var/log/upstart/xbmc-callback-daemon.log
RE: XBMC Callback Daemon - richardkemp - 2014-11-09
rich 32557 0.0 0.0 0 0 pts/1 Z 13:00 0:00 [xbmc_OnPlay] <defunct>
rich 32654 0.0 0.0 0 0 pts/1 Z 13:01 0:00 [xbmc_OnStop] <defunct>
rich 32676 0.0 0.0 0 0 pts/1 Z 13:01 0:00 [xbmc_OnPlay] <defunct>
rich 32693 0.0 0.0 0 0 pts/1 Z 13:01 0:00 [xbmc_OnStop] <defunct>
These (and more of the same) are visible on 'ps aux | grep xbmc'. As I understand it, 'defunct' status is caused by the parent process, i.e. your daemon, not closing the children properly. Is this the case or am I doing something wrong in my scripts causing them to not end? There aren't any ongoing commands in them, they're just oneshots to change volumes.
As I wrote I'm using Arch linux x64 with an intel processor. Should I use linux_386 or linux_amd64? In any case I've now tried 0.4.0_linux_386 with (coincidentally) a new xbmc profile and I'm not seeing the high idle cpu usage I mentioned. Thanks for the update!
RE: XBMC Callback Daemon - pdffs - 2014-11-09
(2014-11-09, 15:49)richardkemp Wrote: rich 32557 0.0 0.0 0 0 pts/1 Z 13:00 0:00 [xbmc_OnPlay] <defunct>Ahh, I guess you're using the background option - I wasn't cleaning these up, and this didn't occur in my limited local testing (I don't use any shell callbacks personally). This should be fixed now in 0.4.1, thanks for the head-up - let me know if these still show up after upgrading (unfotunately you may need to reboot to clear the zombies if a restart of the daemon doesn't get rid of them).
rich 32654 0.0 0.0 0 0 pts/1 Z 13:01 0:00 [xbmc_OnStop] <defunct>
rich 32676 0.0 0.0 0 0 pts/1 Z 13:01 0:00 [xbmc_OnPlay] <defunct>
rich 32693 0.0 0.0 0 0 pts/1 Z 13:01 0:00 [xbmc_OnStop] <defunct>
These (and more of the same) are visible on 'ps aux | grep xbmc'. As I understand it, 'defunct' status is caused by the parent process, i.e. your daemon, not closing the children properly. Is this the case or am I doing something wrong in my scripts causing them to not end? There aren't any ongoing commands in them, they're just oneshots to change volumes.
(2014-11-09, 15:49)richardkemp Wrote: As I wrote I'm using Arch linux x64 with an intel processor. Should I use linux_386 or linux_amd64?Sorry, I though you'd mentioned this, but I couldn't remember and didn't see it in a quick scan of the thread. If you're running x86_64, I'd use the amd64 version. The term amd64 is just a synonym for x86_64: when 64-bit processors were first reaching the market, Intel had a pure 64-bit implementation (Itanium), and AMD produced the 64-bit architecture that we all use now, so that was the term that was used, and because that's how it was named early on, it's stuck that way on some Linux distributions.
(2014-11-09, 15:49)richardkemp Wrote: I'm not seeing the high idle cpu usage I mentioned. Thanks for the update!Sweet! Although, I'm not sure what could have been causing this...
RE: XBMC Callback Daemon - pdffs - 2014-11-12
Newly released v0.4.2 has improved reconnect logic, should now correctly recover from XBMC going away/returning. This lets it run fine in the background on system startup, regardless of what XBMC does.
RE: XBMC Callback Daemon - richardkemp - 2014-11-12
Hi again!
I made an AUR package for Arch linux users to simplify installing and keeping this up to date:
https://aur.archlinux.org/packages/xbmc-callback-daemon-git/
RE: XBMC Callback Daemon - pdffs - 2014-11-13
Oh sweet, thanks, I'll update the README. I would like to suggest a couple of things for the build:
* I've added Godep to pull in dependencies, so I would suggest adding `godep` to your makedepends (there appears to be a package available). Then your build stage would become something like:
Code:
build() {
cd "${_pkgname}"
export GOPATH="godep
godep restore
godep go build
}TBH, I'm not sure I understand how the binary is getting build in your current build stage, though I'm not familiar with Arch, so adapt the above as you see fit.
* You might consider adding an init script to simplify things for users. If Arch uses a SysV compatible init and provides /lib/lsb/init-functions with the init_is_upstart check, you may get away with just taking the debian/xbmc-callback-daemon.init file and dropping it in as `/etc/init.d/xbmc-callback-deamon`. Then providing there is a config file at the default location, users can just set the daemon to start on boot and forget about it. That also means they don't have to worry about modifying autoexec.py or whatever, and the have a sane means of start/stop/restart.
If you do the above, and PKGBUILD lets you drop in a config file that won't overwrite one that already exists (so your config doesn't get clobbered on upgrade), you might also consider putting an base config at `/etc/xbmc-callback-daemon.json` with the contents:
Code:
{
"xbmc": {
"address": "127.0.0.1",
"port": 9090
},
"callbacks": {
}
}Then update your post-install instructions to reference this config.
The godep stuff in particular is a good idea to make sure that the right library versions are used, but the init stuff is completely optional. Thanks again!