Messages

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

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

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.