[Piers]

OK, I tested your most recent master. Here's a log including the issues (line 357): http://pastey.org/view/635396d4

I've reverted back to the repository version, it works again. So it's definitely an issue with the most recent add-on. Happy to help with further testing.

I think that new error may be linked to the fact that you are running with 'restricted rights' (see line 9 in your log).
Are you running in portable mode? Does the user that you are running as have rw privileges to the actual addon directory?

The issue is that the addon needs to dynamically set the choices of the names of the profiles on the Settings page that you gave in the Ambibox Windows program since you can name the profiles whatever you want. Kodi does not provide anyway to dynamically change these choices other than programmatically editing the settings.xml file which appears to reside in a directory that the python api no longer has rw privileges. I don't yet understand what has caused the change for some to no longer have rw rights for this file.

I need to do more research on this issue because I can't recreate it on my systems.

I pushed another update to github to provide more logging of why this might fail. Hopefully it will also allow you to move on even if the addon isn't able to add your profiles to the settings screen. This is temporary fix for now...
Please post back a log.

Thanks for your help in squashing this bug.

There is correct permissions for that add-on directory - I do normally run in portable mode on my workstation where I have multiple version of Kodi installed (for obvious reasons), but not on my main HTPC since I only the most recent RC or stable.

I'll test your updated release and post a log shortly.

[Piers]

I've now tested your updated version (Logging for restricted mode exception during settings.xml parse).

Although there seems to be a problem between the connection with Ambibox, this only occurs when I turn my TV off. I've changed the power settings for the USB port and hope that will rectify it.

However, your recent change appears to work - I also very much like the part you've added to "optimize". I tested three files, there were no issues other than the "start with" option - but I think that's more to do with permissions or the location (everything on that machine is installed in a default location). Here's a log, although not a proper debug log (I'll provide that at a later time): http://pastey.org/view/25815bb6

[Piers]

Here's a very long debug log: http://pastey.org/view/56e5de7f

What I've noticed is that, sometimes, the light isn't disabled after a video has finished. There doesn't appear to be a pattern - it happens at seemingly random instances. This could be a Lightpack issue, which is unlikely, or, most likely, an issue with the connection between Ambibox and your add-on.

It also occurred on the previous version.

Edit:
What you can rule out: permissions - this has no bearing on the previously reported issue.

[bruncolio]

Not to derail, but is ambibox dead? The download site isn't working for me, and having searched around it looks to have been down for months now. Can't find a mirror either...

[KenV99]

Not to derail, but is ambibox dead? The download site isn't working for me, and having searched around it looks to have been down for months now. Can't find a mirror either...

I went to the site after I clean installed Windows 10 and downloaded it on 9/9/2015 at 9:55am EDT. So cerainly not down for months...
If the site remains down, I'll email the author later today.

I uploaded the current to github temporarily for you: https://github.com/AmbiBox/kodi.script.a..._2.1.7.zip

[KenV99]

Here's a very long debug log: http://pastey.org/view/56e5de7f

What I've noticed is that, sometimes, the light isn't disabled after a video has finished. There doesn't appear to be a pattern - it happens at seemingly random instances. This could be a Lightpack issue, which is unlikely, or, most likely, an issue with the connection between Ambibox and your add-on.

It also occurred on the previous version.

Edit:
What you can rule out: permissions - this has no bearing on the previously reported issue.

I pushed another update. I hope the restricted mode error is solved at this point due to the changes in which I present the profiles.
Please make sure you go into settings and set the default profile to None and change the video settings to your preferred settings after you update.

The next time the lights don't shut off, if you can, please post a log. Because the screen capture routine runs in separate thread, it's possible that issue is somewhere there that it occasionally misses turning them off. These multithreading bugs are often difficult to track down and reproduce because I have yet to find a way of creating a VM to simulate a lower powered system so I only have my own HTPC and desktop to test on and both are i7 quadcores running at 3.5 and 4.2 GHz.

Thanks again for your help.

[bruncolio]

Not to derail, but is ambibox dead? The download site isn't working for me, and having searched around it looks to have been down for months now. Can't find a mirror either...

I went to the site after I clean installed Windows 10 and downloaded it on 9/9/2015 at 9:55am EDT. So cerainly not down for months...
If the site remains down, I'll email the author later today.

I uploaded the current to github temporarily for you: https://github.com/AmbiBox/kodi.script.a..._2.1.7.zip

My mistake - it must have been intermittent outages leading to a bunch of people posting "is this site down or is it just me?" posts, giving the impression of one long consistent outage.

Regardless, thank you! Really appreciate it.

[Piers]

Here's a very long debug log: http://pastey.org/view/56e5de7f

What I've noticed is that, sometimes, the light isn't disabled after a video has finished. There doesn't appear to be a pattern - it happens at seemingly random instances. This could be a Lightpack issue, which is unlikely, or, most likely, an issue with the connection between Ambibox and your add-on.

It also occurred on the previous version.

Edit:
What you can rule out: permissions - this has no bearing on the previously reported issue.

I pushed another update. I hope the restricted mode error is solved at this point due to the changes in which I present the profiles.
Please make sure you go into settings and set the default profile to None and change the video settings to your preferred settings after you update.

The next time the lights don't shut off, if you can, please post a log. Because the screen capture routine runs in separate thread, it's possible that issue is somewhere there that it occasionally misses turning them off. These multithreading bugs are often difficult to track down and reproduce because I have yet to find a way of creating a VM to simulate a lower powered system so I only have my own HTPC and desktop to test on and both are i7 quadcores running at 3.5 and 4.2 GHz.

Thanks again for your help.

It does appear to be random, so, if it happens again, I'll post a standard log. Can you explain what you mean with "restricted mode"? I'm running with standard Windows restrictions, the previous version is working well. I'll give the latest a test and report my findings.

[Piers]

The new add-on appears to have no issues. For me, it functions as well as your previous version.

[Piers]

I'm starting to notice more and more "KodiDirect Fail" notices. The only solution is to restart Kodi and AmbiBox. Log: http://pastey.org/view/4d156764

[KenV99]

I'm starting to notice more and more "KodiDirect Fail" notices. The only solution is to restart Kodi and AmbiBox. Log: http://pastey.org/view/4d156764

Is that occurring while you are watching and the LEDs should be working or only at the end of playing?

Those fails in the log occur for me occasionally when I am stopping the video. Again, since it is threaded, I think what happens is that the thread that is driving the LEDs shows a failure due to the fact that the RenderCapture buffer is emptied and returns CAPTURE_STATE_FAILED before the Player fires the onPlaybackStopped event which in turns sets a signal in the other thread to stop capturing. In the code I try to catch that possibility by checking Player.isPlaying(), but again, I think there may be a lag between what occurs in the RenderCapture buffer and that function returning false.

[Piers]

I'm starting to notice more and more "KodiDirect Fail" notices. The only solution is to restart Kodi and AmbiBox. Log: http://pastey.org/view/4d156764

Is that occurring while you are watching and the LEDs should be working or only at the end of playing?

Those fails in the log occur for me occasionally when I am stopping the video. Again, since it is threaded, I think what happens is that the thread that is driving the LEDs shows a failure due to the fact that the RenderCapture buffer is emptied and returns CAPTURE_STATE_FAILED before the Player fires the onPlaybackStopped event which in turns sets a signal in the other thread to stop capturing. In the code I try to catch that possibility by checking Player.isPlaying(), but again, I think there may be a lag between what occurs in the RenderCapture buffer and that function returning false.

Here's a proper debug log with more information and both audio and video tested - the "KodiDirect Fail" message only appears to occur during video playback.

http://pastey.org/view/54ae3f65

(a couple of file paths have been removed from the log)

[Piers]

Here's more unusual behaviour. Disabling the add-on is causing Kodi to crash, http://pastey.org/view/d5407f2e

That's all I could get before I needed to terminate the process.

[KenV99]

Here's more unusual behaviour. Disabling the add-on is causing Kodi to crash, http://pastey.org/view/d5407f2e

That's all I could get before I needed to terminate the process.

I pushed a github update.

That crash behavior seems to have started in Isengard. I am not sure what changed in Kodi to cause it. The only way I seem to be able to eliminate that is by calling sys.exit without any house-keeping to terminate threads and delete objects. Stuff I usually do to eliminate memory leaks and abandoned threads. Shouldn't cause much problems unless someone repeatedly enables and disables without restarting Kodi.

As far as the KodiDirect Fail issue goes I also updated the loop with a 250ms pause to see if the player has stopped before generating a Fail message. Please see if this works for you now.

Thanks again for your help.

EDIT:
If you continue to get Fail messages at this point during playback and not just when stopping I would try lowering the throttle to see if that decreases the probability that the addon requests a video frame and the Kodi RenderCapture buffer cannot provide it.

[Piers]

Here's more unusual behaviour. Disabling the add-on is causing Kodi to crash, http://pastey.org/view/d5407f2e

That's all I could get before I needed to terminate the process.

I pushed a github update.

That crash behavior seems to have started in Isengard. I am not sure what changed in Kodi to cause it. The only way I seem to be able to eliminate that is by calling sys.exit without any house-keeping to terminate threads and delete objects. Stuff I usually do to eliminate memory leaks and abandoned threads. Shouldn't cause much problems unless someone repeatedly enables and disables without restarting Kodi.

As far as the KodiDirect Fail issue goes I also updated the loop with a 250ms pause to see if the player has stopped before generating a Fail message. Please see if this works for you now.

Thanks again for your help.

EDIT:
If you continue to get Fail messages at this point during playback and not just when stopping I would try lowering the throttle to see if that decreases the probability that the addon requests a video frame and the Kodi RenderCapture buffer cannot provide it.

Thank you. I will test your updated version and provide a log, if it's needed.