[ANNOUNCE] VDR developer version 1.3.49
Commit Message
Klaus Schmidinger wrote:
> VDR developer version 1.3.49 is now available at
> If there are no more serious bugs, this will become the final
> version 1.4.0 this sunday :-)
looking through local changes, i think this is the only one obviously-correct enough
-- i got +/- wrong when calculating the size; should be mostly harmless anyway (was
just calling fadvise with too large area).
Comments
Artur Skawina wrote:
> Klaus Schmidinger wrote:
>> VDR developer version 1.3.49 is now available at
>
>> If there are no more serious bugs, this will become the final
>> version 1.4.0 this sunday :-)
>
> looking through local changes, i think this is the only one
> obviously-correct enough
> -- i got +/- wrong when calculating the size; should be mostly harmless
> anyway (was
> just calling fadvise with too large area).
>
>
> ------------------------------------------------------------------------
>
> diff -urNp vdr-1.3.49.org/tools.c vdr-1.3.49.min/tools.c
> --- vdr-1.3.49.org/tools.c 2006-04-21 15:12:47.000000000 +0000
> +++ vdr-1.3.49.min/tools.c 2006-04-29 09:10:26.000000000 +0000
> @@ -1179,7 +1179,7 @@ ssize_t cUnbufferedFile::Read(void *Data
> }
> else if (cachedend > ahead && cachedend - curpos > READCHUNK * 2) {
> // current position has moved back enough, shrink head window.
> - FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK);
> + FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK));
> cachedend = curpos + READCHUNK;
> }
> }
Can anybody else confirm that this doesn't cause any new problems?
I'm afraid I can't make this change for the final 1.4.0 without
extensive testing. So unless at least three others give me a GO
on this one, it will have to stay out of 1.4.0.
Klaus
>> - FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK);
>> + FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK));
>> cachedend = curpos + READCHUNK;
>
> Can anybody else confirm that this doesn't cause any new problems?
> I'm afraid I can't make this change for the final 1.4.0 without
> extensive testing. So unless at least three others give me a GO
> on this one, it will have to stay out of 1.4.0.
i don't think this really fixes any real problems, just a correctness issue :)
Basically the code was trying to free a bit too much data, when playing or jumping backwards -- i doubt it matters in RL. It probably doesn't even matter when replaying an ongoing recording near the end (the only case i can think of where it actually could make noticeable difference, by forcing the new data to disk). As i said it's mostly harmless, just wanted to mention it once i got a current vdr running and before i forget about it. Certainly it doesn't deserve to hold up 1.4.0 by itself.
artur
@@ -1179,7 +1179,7 @@ ssize_t cUnbufferedFile::Read(void *Data
}
else if (cachedend > ahead && cachedend - curpos > READCHUNK * 2) {
// current position has moved back enough, shrink head window.
- FadviseDrop(curpos + READCHUNK, cachedend - curpos + READCHUNK);
+ FadviseDrop(curpos + READCHUNK, cachedend - (curpos + READCHUNK));
cachedend = curpos + READCHUNK;
}
}