What is the difference between xmdsCollectInterval and lastActivity in the status json? I’ve noticed that when the Xibo GUI locks up lastActivity will continue to update but xmdsCollectInterval. I’m writing a windows service to replace the watchdog and wondering if monitoring xmdsCollectInterval would be better.
lastActivity - monitors various threads, etc in the application (usually will be updated more frequently than xmds)
xmdsLastActivity - monitors the last time xmds was used - which should be updated at least one per collection interval, but might be changed more often if there is more xmds activity.
Monitoring xmdsLastActivity might be better for your needs.
The xmdsCollectInterval - is the setting ‘Collection Interval’ (in seconds) that you can adjust in the Display profile in CMS.
1 Like
Great, thanks! That seems to be working well.
Any particular reason why you’d like to replace the watchdog? I’m just curious - if you see some large benefit to having a windows service instead, then perhaps we could move to that as standard
Having the service eliminates the need to schedule something at startup, and also provides the significant benefit of having Windows monitor the service health and restart it if necessary. I’ve also got the specific case where I’m running dual monitors in a lot of situations and the existing watchdog seems to work well on the first monitor, but not always on the 2nd.
I’d be happy to submit the source code once I get a few more bugs worked out… seems to work well but still needs some work and a config file (the only settings in there are hard coded to what I needed). I’ve been making small tweaks every day, so it’s not completely stable yet.
There is one minor quirk though - since it’s running under a service account, you have to give a couple of extra user permissions to the local service account in order to allow the service to start up an app on the interactive desktop. I suppose it’d be better to create a separate local account for this, but I’m lazy 
I’ve looked around and haven’t found a good way to do this programmatically, although I’m sure there’s a workaround.
It does also make it harder to know when it should and shouldn’t be started in cases where the Player should only be run sometimes. The watchdog doesn’t need to be run at start up, because the Player starts it automatically if it isn’t running.
This is a bug that will be fixed in 1.8.2 where only 1 instance of the watchdog was allowed to be running at one time
I’d love to look at your source code, when ready, and see if we can implement something similar into Xibo.
I’ve been using the service for a while… send me a PM with your e-mail and I’ll send over the source code