Overflow with recording >4G?

[ulrhom]

Hi,

first of all: Thanks for the great VOMP: It seems to be the perfect frontend for my VDR.

I've increased in my VDR the size of recording chunks:
MaxVideoFileSize = 20000

Now I've tried to play a recording of approx 8G size with raspi vomp: the playback jumped after approx 4G back to the beginning. So i guess there is somewhere a unint32_t overflow.

[MartenR]

Hi,
well, I do not use files larger than 4 GB (since some file systems and network have still the 4 GB restriction).
So it is hard for me to debug it.
But anyway, can you please answer the following questions:
1) We are using the framenumber as index, so what does the recording time say (if you hit ok), does it jump backward or does it stay at advanced time?
2) A log of the serverside would be helpful, especially the " "getblock pos = %llu length = %lu" messages will help, where the problem is. (server or client side).
3) Do you use the windows client or mvp client? If yes does it happen there as well?

Marten

[ulrhom]

1) We are using the framenumber as index, so what does the recording time say (if you hit ok), does it jump backward or does it stay at advanced time?

It doesn't jump backwards, the time and the bar locks ok (they are advancing as if nothing happened), there are some disturbances on the screen (probably because of broken frames). Only if I stop the playback and start (resume) it I can see that die playback actually jumped back.

3) Do you use the windows client or mvp client? If yes does it happen there as well?

I don't own a MVP, but I can install it on windows if it helps.

2) A log of the serverside would be helpful, especially the " "getblock pos = %llu length = %lu" messages will help, where the problem is. (server or client side).

The logfile is interesting:

Code Select Expand

14:15:36.596616 [debug]  RRProc - getblock pos = 4337658960 length = 100000
14:15:36.596813 [debug]  RRProc - written 100000
14:15:36.596983 [debug]  RRProc - Finished getblock, have sent 100012
14:15:36.597012 [debug]  RRProc - threadMethod waiting
14:15:36.787231 [debug]  Client - Received chan=1, ser=5345, op=7, edl=12
14:15:36.787321 [debug]  RRProc - recvReq
14:15:36.787354 [debug]  RRProc - recvReq set req and signalled
14:15:36.787373 [debug]  Client - Waiting
14:15:36.787396 [debug]  RRProc - thread woken with req, queue size: 1
14:15:36.787513 [debug]  RRProc - getblock pos = 4337758960 length = 100000
14:15:36.788113 [debug]  RRProc - written 100000
14:15:36.788304 [debug]  RRProc - Finished getblock, have sent 100012
14:15:36.788351 [debug]  RRProc - threadMethod waiting
14:15:37.152834 [debug]  Client - Received chan=1, ser=5346, op=13, edl=0
14:15:37.152942 [debug]  RRProc - recvReq
14:15:37.153002 [debug]  RRProc - recvReq set req and signalled
14:15:37.153023 [debug]  Client - Waiting
14:15:37.153091 [debug]  RRProc - thread woken with req, queue size: 1
14:15:37.153180 [debug]  RecPlayer - FILENAME: /var/lib/video.00/Avatar_-_Aufbruch_nach_Pandora/2012-04-08.20.12.12-0.rec/00001.ts
14:15:37.153277 [debug]  RecPlayer - File 1 found, totalLength now 7867414224, numFrames = 9706163959069204426
14:15:37.153352 [debug]  RecPlayer - FILENAME: /var/lib/video.00/Avatar_-_Aufbruch_nach_Pandora/2012-04-08.20.12.12-0.rec/00002.ts
14:15:37.153456 [debug]  RRProc - Rescan recording, wrote new length to client
14:15:37.153481 [debug]  RRProc - threadMethod waiting
14:15:37.154900 [debug]  Client - Received chan=1, ser=5347, op=7, edl=12
14:15:37.154979 [debug]  RRProc - recvReq
14:15:37.155007 [debug]  RRProc - recvReq set req and signalled
14:15:37.155026 [debug]  Client - Waiting
14:15:37.155051 [debug]  RRProc - thread woken with req, queue size: 1
14:15:37.155159 [debug]  RRProc - getblock pos = 4337858960 length = 100000
14:15:37.155183 [debug]  RecPlayer - openFile called for index 1 string:/var/lib/video.00/Avatar_-_Aufbruch_nach_Pandora/2012-04-08.20.12.12-0.rec/00001.ts
14:15:37.180453 [debug]  RRProc - written 100000
14:15:37.180678 [debug]  RRProc - Finished getblock, have sent 100012
14:15:37.180709 [debug]  RRProc - threadMethod waiting
14:15:37.358053 [debug]  Client - Received chan=1, ser=5348, op=7, edl=12
14:15:37.358144 [debug]  RRProc - recvReq
14:15:37.358179 [debug]  RRProc - recvReq set req and signalled
14:15:37.358199 [debug]  Client - Waiting
14:15:37.358218 [debug]  RRProc - thread woken with req, queue size: 1
14:15:37.358335 [debug]  RRProc - getblock pos = 4337958960 length = 100000
14:15:37.358954 [debug]  RRProc - written 100000
14:15:37.359186 [debug]  RRProc - Finished getblock, have sent 100012
14:15:37.359217 [debug]  RRProc - threadMethod waiting
14:15:37.552939 [debug]  Client - Received chan=1, ser=5349, op=7, edl=12
14:15:37.553027 [debug]  RRProc - recvReq
14:15:37.553059 [debug]  RRProc - recvReq set req and signalled
14:15:37.553077 [debug]  Client - Waiting
14:15:37.553110 [debug]  RRProc - thread woken with req, queue size: 1
14:15:37.553225 [debug]  RRProc - getblock pos = 4338058960 length = 100000


Actually there is no 00002.ts:

Code Select Expand


-rw-r--r-- 1 vdr vdr 7867414224 Apr  8  2012 00001.ts
-rw-r--r-- 1 vdr vdr    2555480 Apr  8  2012 index
-rw-r--r-- 1 vdr vdr        681 Apr  8  2012 info
-rw-r--r-- 1 vdr vdr          4 Nov 22 14:19 resume


Ulrich

[MartenR]

Can you please do the following at the vompserver?
Go into the file recplayer.cc to the method "unsigned long RecPlayer::getBlock(unsigned char* buffer, ULLONG position, unsigned long amount)"
and change "fseek" to "fseeko" and recompile the server.
And tell me if this fixed the problem.

Marten

[ulrhom]

Yes this fixes the problem.

Code Select Expand

--- vompserver-0.4.1/recplayer.c 2014-02-16 22:11:49.000000000 +0100
+++ vompserver-0.4.1.new/recplayer.c 2014-11-23 14:25:40.815182313 +0100
@@ -168,7 +168,7 @@
   ULONG yetToGet = amount;
   ULONG got = 0;
   ULONG getFromThisSegment = 0;
-  ULONG filePosition;
+  ULLONG filePosition;

   while(got < amount)
   {
@@ -186,7 +186,7 @@
       getFromThisSegment = segments[segmentNumber]->end - currentPosition;

     filePosition = currentPosition - segments[segmentNumber]->start;
-    fseek(file, filePosition, SEEK_SET);
+    fseeko(file, filePosition, SEEK_SET);
     if (fread(&buffer[got], getFromThisSegment, 1, file) != 1) return 0; // umm, big problem.
 
     // Tell linux not to bother keeping the data in the FS cache


Ulrich

[MartenR]

Thanks,
I have put corresponding changes into the scraper_support branch in git, which is more or less going to be at some time the next release.

Marten