C.Y.M wrote:
I concur with Cym's actions. Even though I am not getting the exact buffer messages as you state, when it does seem to be crashing I have noticed is when it has to change channels to do the recording. As long as I have it already on the channel it doesn't seem to crash. But is using memory like crazy. I don't know if that is related or not. But VDR does continue to run as long as it is already on channel first before the timer kicks in.Klaus Schmidinger wrote:I have been experimenting with this patch and have also applied the patch mentioned in another post by Reinhard Nissl about:Chad Flynt wrote:...I tried this and actually was able to reproduce this. Unfortunately it didn't happen any more since I have inserted a few lines to test something. Will try that again tomorrow. If somebody would like to try this: --- remux.c 2004/10/16 09:11:52 1.19 +++ remux.c 2004/10/19 16:23:00 @@ -556,6 +556,11 @@ int resultCount = 0; uchar *data = resultBuffer->Get(resultCount); if (data) { + if (!synced && resultCount > RESULTBUFFERSIZE * 10 / 8) {//XXX + dsyslog("clearing resultBuffer before sync"); + Clear(); + return NULL; + }//XXX for (int i = 0; i < resultCount - 3; i++) { if (data[i] == 0 && data[i + 1] == 0 && data[i + 2] == 1) { int l = 0; and let me know whether this message is ever logged, that would be nice. KlausThanks for the test code. I have rebuilt vdr with this patch and now I can not seem to reproduce the buffer overflow either... Could the extra time it takes to process this new code be preventing some kind of race condition? So far I have not seen any "clearing resultBuffer before sync" messages... I'll keep testing.
- if (Count > TRANSFERBUFSIZE * 2 / 3) {
+ if (ringBuffer->Available() > TRANSFERBUFSIZE * 2 / 3) {
but, the same buffer overflows occur and I have not seen any messages about "clearing resultBuffer before sync" in my syslogs. However, I do get messages about "clearing device because of consecutive poll timeouts". Im starting to notice that when I set a bunch of consecutive timers, that the first timer seems to always work. The problem seems to occur when VDR has already initiated a prior recording, then must stop recording, then switch chans, then start a new TS. Almost like VDR is not given enough time to recover from the previous recording. If it is of any consequence, I have also noticed that when VDR must switch chans initiated by the timer, that it successfully starts a new TS but the picture on the tv is frozen with the image of the previous channel (until I manually switch chans to the one that is recording).
Thanks,