[ANNOUNCE] VDR developer version 1.3.49

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux