Openhab 2 & Kodi

TSPrivat · June 23, 2017, 5:14am

The Thing status is detected but it is not working all the time

In the stable OH version I was able yo follow the Online/Offline status in the Thing section and it worked very responsive … doing the same now in the latest Snapshot I have delays in the Online/Offline status in the Thing section.

Its a step in the right direction but not working reliable

cweitkamp · July 3, 2017, 1:52pm

Hey Thomas,

did you update to OH2.1 already? Any changes?

TSPrivat · July 6, 2017, 3:29am

Hi Christoph,

I’m running the latest snapshot 2.2 on a RPI3 and the KODI binding got even more unreliable and is now OFFlLINE most of the time. I’m using a Windoes Kodi 17.3 and a LibraElec 17.3 and both systems show the same behaviour.

I was in doubt of my network but I have tried WIFI and Ethernet connectivity on both boxes.

Additionally I have now installed MQTT in parallel on both boxes. I’m getting the correct status update via MQTT and as well I’m able to send notifications to to the KODI screen. This works really fine and very responsive and again both systems respond in the same behaviour.

For example:

I’m starting a movie on kodi
MQTT is providing the new title to all system subscribed to the message (including OH)
After receiving the MQTT message I send back a notification to the KODI Screen “MQTT:Movie $$ has started”
KODI binding is taking a while 1-2minutes (and often fails) to update the title in the Paper UI
after receiving the KODI-Title change update I send a notification back to the KODI Screen “KODI: Move $$ has started”

The MQTT service is running fine even when the KODI service is showing OFFLINE for the KODI Thing

Any ideas on how to investigate on that issue? Is anybody else having the same situation ?

TSPrivat · July 6, 2017, 6:37am

Additional update:

I’m getting a similar error for both of my KODI instances.

Kodi is set to pause
Kodi is resumed from PAUSE to PLAY

I’m getting the below error

2017-07-06 16:32:06.420 [ItemStateChangedEvent     ] - pKodi2_Control changed from PAUSE to PLAY
==> /var/log/openhab2/openhab.log <==
2017-07-06 16:32:06.423 [ERROR] [i.internal.protocol.KodiClientSocket] - Error handling event {"jsonrpc":"2.0","method":"Player.OnPlay","params":{"data":{"item":{"episode":4,"season":5,"showtitle":"Star Trek: The Next Generation","title":"Silicon Avatar","type":"episode"},"player":{"playerid":-1,"speed":1}},"sender":"xbmc"}} player state change message: null
java.lang.NullPointerException
	at org.openhab.binding.kodi.internal.protocol.KodiConnection.requestPlayerUpdate(KodiConnection.java:234)[189:org.openhab.binding.kodi:2.2.0.201707042200]
	at org.openhab.binding.kodi.internal.protocol.KodiConnection.processPlayerStateChanged(KodiConnection.java:377)[189:org.openhab.binding.kodi:2.2.0.201707042200]
	at org.openhab.binding.kodi.internal.protocol.KodiConnection.handleEvent(KodiConnection.java:354)[189:org.openhab.binding.kodi:2.2.0.201707042200]
	at org.openhab.binding.kodi.internal.protocol.KodiClientSocket$KodiWebSocketListener$2.run(KodiClientSocket.java:158)[189:org.openhab.binding.kodi:2.2.0.201707042200]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
	at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]

cweitkamp · July 6, 2017, 1:31pm

Hey Thomas,

thanks for the update. I am a little bit helpless with your concern. I have some problems in my setup in combination of Kodi and openHAB. But nothing similar to yours. No performance problems. The Kodi binding is based on a Websocket implementation. This Websocket sometimes gets closed. But I don’t know why. E.g. if I reboot Kodi sometimes the connection gets lost, sometimes works without problems afterwards. I often have the situation, that Kodi goes to Suspend or Hibernate mode and doesn’t accept the commands from openHAB whereas every command using a third-party app (I am using Yatse) is executed without exception.

TSPrivat · July 8, 2017, 2:33am

Yes, I’m a bit lost as well with these issues. I had the same problems as you have with suspend or hibernate and disabled these functionalities.

In meanwhile I found out that whenever I had any of the above issues the Kodi-Thing went OFFLINE either before or just after the issue. I will try to install some persistence logging on the Kodi-Thing and on Commands send and received from Kodi, maybe this will give me some insight.

And I can confirm on 3rd party-apps. Whenever I had an issue with Kodi(e.g Thing went offline)

I used Yatse to control the Kodi…it worked all the time
I used the MQTT messages to send and receive information … works all the time ([KODI MQTT])(https://github.com/owagner/kodi2mqtt)
I used the Kodi-Web interface … it worked as well all the time

My issues are often apearing in the below scenarios:

Kodi-Thing goes offline … commands to/from Kodi fail to execute
when Kodi is running and OH is restarting (e.g: Stope/Start RPI OH instance)sometimes the Kodi-Thing is not registered as ONLINE and remains OFFLINE
when modifying rules (no OH restart) the Kodi-Thing is going OFFLINE
when Kodi is crashing or the according system is powered-off … the Kodi-Thing goes OFFLINE and is not registering when Kodi is coming back online (maybe it is still in a timeout-loop?)

As said, I will try to get some more logging details to analyse. At moment, I’m suspecting that some Kodi command timeout-durations are just too long and preventing to reconnect the Kodi-Thing when trying to come back ONLINE.

Besides these issues I love the Kodi binding and the options it is opening up. I have now created virtual channel switches and able to start selected Movies and TV channels via Alexa and other triggers

mancer · November 8, 2019, 9:25pm

Reviving this thread…

Since upgrading from 2.4 to 2.5M4, I get this warning every 10s when something is playing:

[WARN ] [di.internal.utils.ByteArrayFileCache] - Could not write file '7b78bebb84c9d626127f50056b473d7d.248%253a32400%252fphoto%252f%253a%252ftranscode%253fwidth%253d1920%2526height%253d1920%2526minSize%253d1%2526upscale%253d0%2526url%253d%252flibrary%252fmetadata%252f1596%252fart%252f1570971676%2526X-Plex-Token%253dXScJLJbUdcybNXFyHLuv' to cache

java.nio.file.FileSystemException: /var/lib/openhab2/cache/org.openhab.binding.kodi/7b78bebb84c9d626127f50056b473d7d.248%253a32400%252fphoto%252f%253a%252ftranscode%253fwidth%253d1920%2526height%253d1920%2526minSize%253d1%2526upscale%253d0%2526url%253d%252flibrary%252fmetadata%252f1596%252fart%252f1570971676%2526X-Plex-Token%253dXScJLJbUdcybNXFyHLuv: File name too long

	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:91) ~[?:?]

	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]

	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]

	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) ~[?:?]

	at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) ~[?:?]

	at java.nio.file.Files.newOutputStream(Files.java:216) ~[?:?]

	at java.nio.file.Files.write(Files.java:3292) ~[?:?]

	at org.openhab.binding.kodi.internal.utils.ByteArrayFileCache.writeFile(ByteArrayFileCache.java:140) ~[?:?]

	at org.openhab.binding.kodi.internal.utils.ByteArrayFileCache.put(ByteArrayFileCache.java:98) ~[?:?]

	at org.openhab.binding.kodi.internal.protocol.KodiConnection.downloadImageFromCache(KodiConnection.java:893) ~[?:?]

	at org.openhab.binding.kodi.internal.protocol.KodiConnection.getImageForElement(KodiConnection.java:856) ~[?:?]

	at org.openhab.binding.kodi.internal.protocol.KodiConnection.requestPlayerItemUpdate(KodiConnection.java:654) ~[?:?]

	at org.openhab.binding.kodi.internal.protocol.KodiConnection.requestPlayerUpdate(KodiConnection.java:518) ~[?:?]

	at org.openhab.binding.kodi.internal.protocol.KodiConnection.updatePlayerStatus(KodiConnection.java:509) ~[?:?]

	at org.openhab.binding.kodi.internal.handler.KodiHandler.lambda$1(KodiHandler.java:627) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.

As you probably see I’m using a Plex server together with Kodi.
Not sure why or where OH tries to write an image… but how can I prevent this?

Alex

cweitkamp · November 9, 2019, 8:26am

Hi Alex,

Can you provide a full TRACE log? You might want to send it to me via PM to keep private data hidden. Thanks.

Kodi binding uses an internal cache to omit downloading thumbnails or fanarts all the time. In general it tries to extract the filename extension and calculates a hash for the basename to prevent such long filenames. This algorithm seem to fail in your case.