Recent Posts

91

VOMP for Raspberry Pi / Re: Overflow with recording >4G?

« Last post by ulrhom on November 23, 2014, 13:38:29 »

Yes this fixes the problem.

Code: [Select]

--- 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

92

VOMP for Raspberry Pi / Re: Overflow with recording >4G?

« Last post by MartenR on November 23, 2014, 10:30:47 »

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

93

VOMP for Raspberry Pi / Re: Overflow with recording >4G?

« Last post by ulrhom on November 22, 2014, 13:35:49 »

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]

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]

-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

94

VOMP for Raspberry Pi / Re: Overflow with recording >4G?

« Last post by MartenR on November 22, 2014, 09:39:04 »

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
 

95

VOMP for Raspberry Pi / Overflow with recording >4G?

« Last post by ulrhom on November 21, 2014, 07:38:14 »

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.

96

VOMP for Raspberry Pi / Re: Vompclient with tvscraper support

« Last post by MartenR on October 28, 2014, 07:40:49 »

Is now fixed!

Marten

97

VOMP for Raspberry Pi / Re: Vompclient with tvscraper support

« Last post by JTe on October 27, 2014, 19:31:15 »

Ok. If you cannot reproduce it, let me know.

-JTe

98

VOMP for Raspberry Pi / Re: Vompclient with tvscraper support

« Last post by MartenR on October 27, 2014, 19:27:07 »

I was meaning the debugging (logging) switch -d. I did only manage to get the log once, after that every run seems to work, but without the -d switch it always gets jammed with a black screen, without loading the start menu.

Then do not do the test, this sounds like I can reproduce it this way.

Marten

99

VOMP for Raspberry Pi / Re: Vompclient with tvscraper support

« Last post by JTe on October 27, 2014, 19:22:46 »

I will make the tests. It will just take some time as I compile in native raspi environment and it takes some time to compile.

 I was meaning the debugging (logging) switch -d. I did only manage to get the log once, after that every run seems to work, but without the -d switch it always gets jammed with a black screen, without loading the start menu.

-JTe

100

VOMP for Raspberry Pi / Re: Vompclient with tvscraper support

« Last post by MartenR on October 27, 2014, 18:19:19 »

Hard to say, I have changed a lot during the last commit.
So we have to revert it, step by step.
1) First try, can you please use mutex.h and mutex.cc of the commit before. If it works, we already have to problem.
2) If this did not fix, it try to use the old boxstack.cc and boxstack.h with the new mutex files.

1 and 2 are unrelated, other changes are connected to optimizations in the rendering classes, so not so easy to disentangle for this:

3) It it would be helpful, if you attach the debugger using "gdb -tui -p PIDOFVOMP", you can get the pid of vomp using ps. Now, using "info threads" should give a list where all threads are. You can select every thread with "thread THREADNUMBER", now it getting information, where every thread is using, "bt" can help. 

Another question, before you only see the keep alive packets, are the log lines then always the same?
Furthermore what do you mean with "with debugging"? Compiling with debug symbols? With attached debugger?    Maybe there is a way, where I can reproduce it... I tested everything with a debug build and with switch "-d".

Marten