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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr