[vdr] [ANNOUNCE] VDR developer version 1.7.17

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Sun Mar 20 12:46:00 CET 2011

On 19.03.2011 22:42, Klaus Schmidinger wrote:
> On 19.03.2011 21:56, Udo Richter wrote:
>> Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
>>> - While replaying, the editing marks are now updated every 10 seconds (based on a
>>>   patch from Manuel Reimer).
>> Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I
>> only used the marks reloading. (As a good-bye, I've posted an updated
>> jumpplay at [1]).
>> However, the VDR version also has the slow update speed of once every 10
>> seconds that I don't like. Especially after editing, I usually
>> immediately switch to the edited recording to check the result, and then
>> have to either wait 10 seconds for all marks to appear, or re-start the
>> replay to get updated marks. (With hard link cutter, editing is usually
>> done in less than 10 seconds.)
>> As a solution, I thought it would be a good idea to reload the marks
>> file whenever the index file gets updated. Unfortunately, this is more
>> complicated than I thought, because the marks reside in cReplayControl,
>> while the index is in a cDvbPlayer which is owned by cDvbPlayerControl.
>> There is no direct access to the index from cReplayControl.
>> Polling for number of total frames via GetIndex() would work, as
>> cReplayControl::ShowProgress does - but only if the editing OSD is
>> visible. So add another polling of GetIndex(), and another lastTotal to
>> check for changes? Not very elegant. The alternative would be some extra
>> rewrites...
>> Any thoughts on that?
> How about taking the age of the marks file into account?
> Like, when checking whether the file has been changed, calculate
> the age of the file (tm) and schedule the next check for "now + f(tm)".
> That way, a file that has just been updated will be checked again
> very soon, while an old file will only be checked rarely.
> Ages under one minute could be treated as "one second", ages under
> one hour as "10 seconds" and anything older could just result
> in not rereading the marks file (since it's rather unlikely that
> it will change once it's grown that old).

I have attached a patch that implements this.
Would this be ok?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdr-1.7.17-updatemarks.diff
Type: text/x-patch
Size: 2175 bytes
Desc: not available
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20110320/23b54c96/attachment.bin>

More information about the vdr mailing list