Hello,
I’m attempting to do an analysis of our recordings using, among other things, the Media.size field in the database. However, the size stored in the DB doesn’t seem to match the actual file size. Does the size field denote something other than file size in bytes?
We’re running server 3.1.9 on Ubuntu 22.04 LTS.
Interesting…anything in the logs around this time?. Are you using docker? 3.1.9 is a bit older, not saying you have to upgrade just curious.
All recordings seem to be affected. Here are the logs for yesterday:
Aug 21 01:32:11 cmbluecherry2 bc-server[1958]: I(3/Entrance NE): Bad timestamp: too large a gap of 1 seconds (1 tolerated), dts=1221120902610 while last was 1221119406990 on stream 0, bailing out, causing the recording file to restart
Aug 21 01:32:11 cmbluecherry2 bc-server[1958]: E(3/Entrance NE): Failure in recording writing
Aug 21 01:34:51 cmbluecherry2 bc-server[1958]: I(3/Entrance NE): Motion detected
Aug 21 09:01:15 cmbluecherry2 bc-server[1958]: I(6/Aisle A): Last message repeated 1149 times!
Aug 21 09:01:15 cmbluecherry2 bc-server[1958]: I(6/Aisle A): Bad timestamp: too large a gap of 1 seconds (1 tolerated), dts=1223545667130 while last was 1223544171060 on stream 0, bailing out, causing the recording file to restart
Aug 21 09:01:15 cmbluecherry2 bc-server[1958]: E(6/Aisle A): Failure in recording writing
Aug 21 09:16:26 cmbluecherry2 bc-server[1958]: I(6/Aisle A): Motion detected
Aug 21 15:28:31 cmbluecherry2 bc-server[1958]: I(): Last message repeated 506 times!
No, ESXi.
Can you confirm that your server’s db size matches actual file size?
Checking in. I’m currently running a script every hour to keep the size accurate in the DB, but I’d like to not do that.
I would prefer you test the next release (3.1.14)…which distro are you using?