[vdr] [ANNOUNCE] VDR developer version 1.7.17

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Sun Mar 20 13:31:49 CET 2011

On 20.03.2011 12:46, Klaus Schmidinger wrote:
> 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?

Sorry, there was a line missing that makes sure the initial load
takes place. Attached is a revised version of the patch.

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

More information about the vdr mailing list