Data usage per Client >10MB/h?

Before completing please check that the time, date and timezone have been correctly set on the device running the Player.

Check! (I always check this in the install phase and we have the NTP client on)

To be completed by the original poster:

Player Version

CMS Version: 2.3.10 (Docker)
Client Version: windows 2 R256.7-256 (WhiteLable)

Issue

Since some time our clients use a lot of bandwidth (~10-11MB/h). We noticed this because some weeks ago one LTE-Router, with 9 clients behind them, runs in days in the monthly data traffic limit. We checkt this with a newly setuped client in the office (with R256.7). The interesting part is that the bandwidth usage on the CMS don’t shows it but the windows 10 traffic counter says that most of it is used by the Xibo client. We use a Win. 10 IoT Enterprise system with all update-, and annoyance-, services are turned off. The Playlist for testing has just a bunch of pictures scheduled, which should be a one time download. For testing I also turned off the stats (in the player profile and in the layout and playlist options) and I switched error logging off. All without any change in bandwidth usage. We don’t have this problem ever before.

I have found one error in the logs, which may or my not be the problem!?

With error logging on there are two errors per Display, both 3-4 times per minute:

#1. SQLSTATE[HY000]: General error: 1812 Tablespace is missing for table cms.stat.

#2. Run: Exception in Run: Der vom Client gefundene Anforderungsinhaltstyp ist ‘text/plain;charset=UTF-8’, erwartet wurde ‘text/xml’.Fehler bei der Anforderung mit folgender Fehlermeldung:–Es trat ein unbekannter Fehler im Zusammenhang mit dem XMDS auf. Der Fehler wurde in das Log geschrieben. Bitte kontaktieren Sie den Administrator.–.

Without error logging only error #1 get’s logged.

Did you know what it is or how we can track down the error to it’s roots?

The error you mention is because someone deleted part of the MySQL database from the filesystem. It’s the table that records proof of play statistics.

The Players will be sending those up to the CMS indefinitely trying to flush those out, and the CMS will error each time, which is why the bandwidth isn’t recorded.

You need to run the following SQL on your database:

DROP TABLE `stat`;
CREATE TABLE `stat` (
  `statId` int(11) NOT NULL AUTO_INCREMENT,
  `type` varchar(20) NOT NULL,
  `statDate` int(11) NOT NULL,
  `scheduleId` int(11) NOT NULL,
  `displayId` int(11) NOT NULL,
  `campaignId` int(11) DEFAULT NULL,
  `layoutId` int(11) DEFAULT NULL,
  `mediaId` int(11) DEFAULT NULL,
  `widgetId` int(11) DEFAULT NULL,
  `start` int(11) NOT NULL,
  `end` int(11) NOT NULL,
  `tag` varchar(254) DEFAULT NULL,
  `duration` int(11) NOT NULL,
  `count` int(11) NOT NULL,
  `engagements` text,
  PRIMARY KEY (`statId`),
  KEY `statDate` (`statDate`),
  KEY `displayId` (`displayId`,`end`,`type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

The above is specific to version 2.3.10. You shouldn’t use it for any other version. If you’re unsure how to run that, please see How can I run a SQL command when using a Docker Install?

That will fix the error. If you don’t want proof of play statistics, then turn them off in the Display settings profile. The Players will need to flush out what they have recorded before they will stop sending in records, so if this has been going on for some time, that table will continue to grow for a while.

You can run the following to empty it periodically:

TRUNCATE `stat`;
OPTIMIZE TABLE `stat`;

It’s not OK to just delete files from shared/db. They form part of a database, they aren’t raw log files.

Other reasons Windows may show different bandwidth to the CMS is if you’re embedding webpages, streaming video etc that doesn’t pass through the CMS.

Thanks for your support! That does the Trick. I’m now down to 0,25MB/h.

But the OPTIMIZE doesn’t seems to work!?

MySQL [cms]> TRUNCATE stat; OPTIMIZE TABLE stat;
Query OK, 0 rows affected (0.383 sec)

±---------±---------±---------±------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
±---------±---------±---------±------------------------------------------------------------------+
| cms.stat | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| cms.stat | optimize | status | OK |
±---------±---------±---------±------------------------------------------------------------------+
2 rows in set (0.168 sec)

Is

a “problem” or should I use other SQL commands to optimize that table?

No it’s not a problem. It’s completely normal.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.