I recently installed Xibo 1.8.5 using Docker on a dedicated Ubuntu 16.04 LTS server. The single player that is connected to the CMS runs a freshly installed Windows 1.8.3-130 client. After one and a half day of operation the collection of proof of play data stopped. On the player machine I found around 1540 xml stat files with timestamps starting roughly at the time the collection stopped.
Right now I am still trying to figure out how I can collect the backlog statistics and did the following:
Restarted the player multiple times
Manually triggered the daily maintenance
Rebooted the server
The player is logged in and responds to XMR requests (like screenshot requests).
Both player and server have enough internet bandwidth (20Mbit/s symmetric, 1Gbit/s symmetric) and are idling CPU-wise. I found no errors in the log of the CMS and would be grateful for hints what I could try next.
The players shows customers ads (most between 10 and 20 seconds long). So proof of play is a mandatory feature, even with logs that easily can reach around 8.500 entries per day.
Assuming the stats are enabled in the display profile assigned to your display, it should send them back to the CMS as described here - Statistics reporting
If you look in your CMS, how does the proof of play stats page look like there?
Thanks for your reply. It shows the layout and the media items in this layout with number of plays / duration in a table, but the “Last shown” column lags behind 2 days.
In the Display Settings profile for Windows, try increasing the number of simultaneous downloads. I believe that also increases the number of uploads back in a single collection.
You may also need to lower your collection interval so that the Player uploads more often. It will then slowly catch up over a period of days.
Thank you alex. I lowered the collection interval and the players seems to process the backlog. I’ll keep an eye on the progress. Increasing the number of simultaneous uploads led to intermittent crashes of the player, so I left them at the default.