I had 5 players installed on 5 machines, for testing Xibo according to our needs. The machines are part of a network that many users can access and log into. Xibo players are installed without regard to users. That means that, I cannot choose to install it for only one user. When another user is logged into the machine, I discovered that multiple instances of Xibo run. I was wondering if that would/could be the source of some of the issues I was encountering. Namely, I was unable to request screenshots for certain displays (port conflicts?) and the players kept restarting with message “Activity count threshold exceeded,” or something to that effect. I tinkered with this a bit and found that if I went into task manager and closed the process for the other user, this message was not displayed.
I have to wait before attempting to resolve this issue myself, as the machines are shared, but I thought I might change the policy regarding who can log into the machine, or perhaps find a way to disable Xibo for other users. I have to talk to my boss about the machines before I do anything.
I’m interested in hearing other people’s thoughts on this.
Yes, if you had multiple Xibo players instances running like that, then that will cause exactly the issues you’ve mentioned.
While of course you can have multiple Xibo players on one PC, then need additional configuration - separate folders, library locations, renamed executable etc. in your case when it was ‘the same’ player running on different user accounts, then you will end up with all sort of issues.
Perhaps some group policy changes or registry changes to disallow Xibo for certain users would help there.
I honestly don’t know what else to try. I tried changing the name of watchdog so it wouldn’t do that every minute, and it worked, but then none of my players would pull from the CMS, which obviously defeats the purpose.
After changing the name of watchdog and only running the player, not watchdog, the CMS says that none of the players are logged in and that they were last accessed at the time that I shut down watchdog (and didn’t start it again). Scheduling layouts produces no changes.
Hi guys,
not sure if this is going to be any help but i would however like to share it.
I have never used dual player in one PC but i run 2 channels in one PC which is the same thing but very functional and stable.
Here is how i do it,
if i want to have 2 different content in one PC,
i connect 2 displays to it and use the extended desktop which is 3840x1080 (2 displays horizontally side by side or top of each other, doesn’t really matter).
After this i create a layout of this size (3840x1080) and divide it to two and i assign it to my player. This of course a limitation where you cannot schedule the divided layout separately, you will be forced to use the same schedule for both screens.
I have to say that i really love this functionality
Is there just one player instance running when you look in windows task manager?
Just to confirm and for me to try and recreate it, what CMS and player versions are you using please?
From memory, you had 1.8.2 docker installation, is that still correct or is it 1.8.3 now with the players in the same version?
Is the XMR correctly configured? with docker you should only need to provide public xmr address in CMS settings, from the looks of it players can’t reach it at all.
Well I wasn’t insisting that Watchdog was causing it. I was simply stating what happened and why I thought it did.
Yes. I renamed the watchdog, started the player (watchdog does not start with the player) and that is what was shown. I have left it like that for about 23 hours and it says the exact same thing. Nothing else is being logged. There is only one instance of each player per machine. There are no other processes related to Xibo on any machine, apart from the one player.
My CMS version is 1.8.2 (docker installation) and the players are 1.8.3. I will update the CMS, as I hadn’t realized there was an update. (I had reinstalled the players trying to select install for only one user before and didn’t realize the version had been updated.)
In the CMS, I have the XMR Public Address set under Settings, in the Display tab, and no where else. I have gone into the settings for each player and checked reconfigure XMR.
I’m going to update the CMS after this post, and if that fixes the issue, I will post and let you know.
Restarting the players shows them logged in but it doesn’t last long. Going back into the player options and saving them again seems to keep them logged in longer. I increased the logging through the CMS in settings -> troubleshooting. Is that what you mean?
I enabled Auditing until December 31st. Saving the player options again has resulted in everything working now. I can request screenshots, and they show up. I don’t know if it will stop working again, though, because I didn’t do anything else besides saving the player options several times. Hopefully the auditing will offer an explanation.
Saving display profile (or display record for that matter) clears the display(s) cache, so perhaps there was some sort of an issue - if something does start to be ‘off’ again, with auditing enabled you should have some logs that should tell us more about it.
