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). Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
