Hi
When we delete index file on some HD recording due to synchronous problem for editing, sometimes vdr is not able to rebuild it , start for few seconds and generate an errors
Stream has "something" in it, you can add mark but not navigate between without crashing vdr , when playing records, time goes not seconds to seconds but every two seconds
Is it possible for next release to increase the buffer size to 300 instead of 100 in recording.c , class cIndexFileGenerator ? This has been tested successfully by at least two users with same problem
Thanks in advance
On 13.04.2010 17:44, dplu wrote:
Hi
When we delete index file on some HD recording due to synchronous problem for editing, sometimes vdr is not able to rebuild it , start for few seconds and generate an errors
Stream has "something" in it, you can add mark but not navigate between without crashing vdr , when playing records, time goes not seconds to seconds but every two seconds
If the index is initially wrong, and ok after regenerating it, this patch may fix the initial index creation:
--- remux.c 2010/02/28 14:42:07 2.42 +++ remux.c 2010/04/05 09:32:57 2.43 @@ -817,7 +817,7 @@ if (synced && Processed) return Processed; if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE) - return 0; // need more data, in case the frame type is not stored in the first TS packet + return Processed; // need more data, in case the frame type is not stored in the first TS packet if (!frameDuration) { // frame duration unknown, so collect a sequence of PTS values: if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames
Is it possible for next release to increase the buffer size to 300 instead of 100 in recording.c , class cIndexFileGenerator ? This has been tested successfully by at least two users with same problem
I don't see how increasing this buffer size would change anything. cFrameDetector::Analyze() needs to see MIN_TS_PACKETS_FOR_FRAME_DETECTOR packets, which is a mere 376 byte. So even a much smaller buffer should work.
But maybe I'm missing something here and somebody can point out why increasing this buffer size would actually change anything.
Klaus
Le Sunday 18 April 2010 16:11:20 Klaus Schmidinger, vous avez écrit : Hi
On 13.04.2010 17:44, dplu wrote:
Hi
When we delete index file on some HD recording due to synchronous problem for editing, sometimes vdr is not able to rebuild it , start for few seconds and generate an errors
Stream has "something" in it, you can add mark but not navigate between without crashing vdr , when playing records, time goes not seconds to seconds but every two seconds
If the index is initially wrong, and ok after regenerating it,
It is not ok until the buffer size is increased ...
this patch may fix the initial index creation:
--- remux.c 2010/02/28 14:42:07 2.42 +++ remux.c 2010/04/05 09:32:57 2.43 @@ -817,7 +817,7 @@ if (synced && Processed) return Processed; if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE)
return 0; // need more data, in case the frame type isnot stored in the first TS packet + return Processed; // need more data, in case the frame type is not stored in the first TS packet if (!frameDuration) { // frame duration unknown, so collect a sequence of PTS values: if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames
Is it possible for next release to increase the buffer size to 300 instead of 100 in recording.c , class cIndexFileGenerator ? This has been tested successfully by at least two users with same problem
I don't see how increasing this buffer size would change anything. cFrameDetector::Analyze() needs to see MIN_TS_PACKETS_FOR_FRAME_DETECTOR packets, which is a mere 376 byte. So even a much smaller buffer should work.
But maybe I'm missing something here and somebody can point out why increasing this buffer size would actually change anything.
Not sure but what happen if the size of data stream between two keyframes is greater than max buffer value ? You will never be able to have inside one buffer range two I frames at the same time ? HD stream in France are not full standard, maybe to prevent copy or other
Will test your patch this week and see if it change or not index problem
Best regards
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 04/18/10 18:53, dplu wrote:
Le Sunday 18 April 2010 16:11:20 Klaus Schmidinger, vous avez écrit : Hi
On 13.04.2010 17:44, dplu wrote:
Hi
When we delete index file on some HD recording due to synchronous problem for editing, sometimes vdr is not able to rebuild it , start for few seconds and generate an errors
Stream has "something" in it, you can add mark but not navigate between without crashing vdr , when playing records, time goes not seconds to seconds but every two seconds
If the index is initially wrong, and ok after regenerating it,
It is not ok until the buffer size is increased ...
this patch may fix the initial index creation:
--- remux.c 2010/02/28 14:42:07 2.42 +++ remux.c 2010/04/05 09:32:57 2.43 @@ -817,7 +817,7 @@ if (synced && Processed) return Processed; if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE)
return 0; // need more data, in case the frame type isnot stored in the first TS packet + return Processed; // need more data, in case the frame type is not stored in the first TS packet if (!frameDuration) { // frame duration unknown, so collect a sequence of PTS values: if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames
Is it possible for next release to increase the buffer size to 300 instead of 100 in recording.c , class cIndexFileGenerator ? This has been tested successfully by at least two users with same problem
I don't see how increasing this buffer size would change anything. cFrameDetector::Analyze() needs to see MIN_TS_PACKETS_FOR_FRAME_DETECTOR packets, which is a mere 376 byte. So even a much smaller buffer should work.
But maybe I'm missing something here and somebody can point out why increasing this buffer size would actually change anything.
Not sure but what happen if the size of data stream between two keyframes is greater than max buffer value ? You will never be able to have inside one buffer range two I frames at the same time ? HD stream in France are not full standard, maybe to prevent copy or other
Only two subsequent TS packets are used to analyze the where a new frame starts.
Will test your patch this week and see if it change or not index problem
I would expect this patch to fix the problem. I don't see why increasing the buffer size would help.
Klaus
Hi
Thanks for the patch, seems to work OK for now, as long problem was not on all recordings, long time of checking start ... will reactivate if necessary
@+
Le Sunday 18 April 2010 18:53:35 dplu, vous avez écrit :
Le Sunday 18 April 2010 16:11:20 Klaus Schmidinger, vous avez écrit : Hi
On 13.04.2010 17:44, dplu wrote:
Hi
When we delete index file on some HD recording due to synchronous problem for editing, sometimes vdr is not able to rebuild it , start for few seconds and generate an errors
Stream has "something" in it, you can add mark but not navigate between without crashing vdr , when playing records, time goes not seconds to seconds but every two seconds
If the index is initially wrong, and ok after regenerating it,
It is not ok until the buffer size is increased ...
this patch may fix the initial index creation:
--- remux.c 2010/02/28 14:42:07 2.42 +++ remux.c 2010/04/05 09:32:57 2.43 @@ -817,7 +817,7 @@ if (synced && Processed) return Processed; if (Length < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE) - return 0; // need more data, in case the frame type is not stored in the first TS packet + return Processed; // need more data, in case the frame type is not stored in the first TS packet if (!frameDuration) { // frame duration unknown, so collect a sequence of PTS values: if (numPtsValues < MaxPtsValues && numIFrames < 2) { // collect a sequence containing at least two I-frames
Is it possible for next release to increase the buffer size to 300 instead of 100 in recording.c , class cIndexFileGenerator ? This has been tested successfully by at least two users with same problem
I don't see how increasing this buffer size would change anything. cFrameDetector::Analyze() needs to see MIN_TS_PACKETS_FOR_FRAME_DETECTOR packets, which is a mere 376 byte. So even a much smaller buffer should work.
But maybe I'm missing something here and somebody can point out why increasing this buffer size would actually change anything.
Not sure but what happen if the size of data stream between two keyframes is greater than max buffer value ? You will never be able to have inside one buffer range two I frames at the same time ? HD stream in France are not full standard, maybe to prevent copy or other
Will test your patch this week and see if it change or not index problem
Best regards
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
dplu -
Klaus Schmidinger