[KenV99]

Hello Pilluli,
I tried you method this morning it works too. Thanks.

I just however discovered an issue with the plugin, whether i use your default.py or KenV99: the plugin works only when i go into its settings and validate them before playing a video.
Let me explain better:
- scenario1: i just start xbmc, and then start a video: plugin does not trigger
- scenario2: i start xbmc, go into plugin config page, validate the config without changing it, return to homepage, and then start a video: it works.

I activated XBMC debug to see what happened.

In scenario2 (working case after config), i see that in the logs:

Code:

10:56:55 T:3004  NOTICE: -----------------------------------------------------------------------
10:56:55 T:3004  NOTICE: Starting XBMC (12.0 Git:20130127-fb595f2), Platform: Windows 7 32-bit, build 7600. Built on Jan 28 2013 (compiler 1600)
[...]
10:57:34 T:3004   DEBUG: ------ Window Init (DialogAddonSettings.xml) ------
[...]
10:57:37 T:4072   DEBUG: XBMC callbacks: Reading properties
10:57:37 T:4072   DEBUG: XBMC callbacks: script xbmc starts = ""
10:57:37 T:4072   DEBUG: XBMC callbacks: script player starts = "wscript C:\sarah\plugins\fred\bin\huelight_low.vbs"
10:57:37 T:4072   DEBUG: XBMC callbacks: script player stops = "wscript C:\sarah\plugins\fred\bin\huelight_high.vbs"
10:57:37 T:4072   DEBUG: XBMC callbacks: script player pauses = "wscript C:\sarah\plugins\fred\bin\huelight_high.vbs"
10:57:37 T:4072   DEBUG: XBMC callbacks: script player resumes = "wscript C:\sarah\plugins\fred\bin\huelight_low.vbs"
10:57:37 T:4072   DEBUG: XBMC callbacks: script screensaver starts = ""
10:57:37 T:4072   DEBUG: XBMC callbacks: script screensaver stops = ""
10:57:37 T:4072   DEBUG: XBMC callbacks: script idle = ""
10:57:37 T:4072   DEBUG: XBMC callbacks: db update = ""
[...]
10:57:50 T:4072   DEBUG: XBMC callbacks: player starts
10:57:50 T:4072   DEBUG: XBMC callbacks: Going to execute script = "wscript C:\sarah\plugins\fred\bin\huelight_low.vbs"

When i am in scenario1 (default case, not working), i see in the logs:

Code:

10:53:24 T:4824  NOTICE: -----------------------------------------------------------------------
10:53:24 T:4824  NOTICE: Starting XBMC (12.0 Git:20130127-fb595f2), Platform: Windows 7 32-bit, build 7600. Built on Jan 28 2013 (compiler 1600)
[...]
10:55:53 T:3032   DEBUG: XBMC callbacks: player starts

I looked into the default.py code, and it seems to me that in default case the properties are not loaded, so even though the event "player starts" is properly catched it does not trigger the subprocesscall.
For the properties to be read, i have to validate them at each xbmc start.
But, why?
I do not know if it is pertinent, but please note that i use xbmc in portable mode (started with '-p' )

My solution proposal would be to modify the default.py to hardcode within each callback function the value of the variable from settings.xml, so that it works even if the settings are not read.

Any other idea?

Hmmmm. I'm thinking that it definitely may be related to the portable mode, because I know for sure that the code retrieves the settings properly during initialization in the non-portable mode. In addition, when I step through using a debugger, that code is properly executed. The python extensions for XBMC do not provide alternate means of retrieving the settings in portable mode versus non-portable. The extension provides automatic path translation due to the differences in OS's.

I will look into running the debugger when starting in portable mode and tracing the calls, but I'll have to figure out the process of copying over my settings to the portable_data directory. Are you running from the Program Files directory using 'run as admin' or are you running from a different read/write directory?

The code as it stands should read the settings at initialization and whenever the settings change. Although it could be written to read the settings before each script call, I'd like to investigate why it's failing currently before resorting to that.

I'm also contemplating including code in my fork to directly execute url/http calls and more detailed error catching and logging. And optionally provide on-screen notifications when the scripts run to also help with debugging. If it seems to work well, perhaps I'll ask pilulli to consider pulling that code back into the master.