[ANNOUNCE] VDR developer version 1.7.17
Commit Message
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?
Klaus
===================================================================
RCS file: ./RCS/recording.c
retrieving revision 2.26
@@ -1270,7 +1270,7 @@
{
fileName = AddDirectory(RecordingFileName, IsPesRecording ? MARKSFILESUFFIX ".vdr" : MARKSFILESUFFIX);
framesPerSecond = FramesPerSecond;
- lastUpdate = 0;
+ nextUpdate = 0;
lastFileTime = -1; // the first call to Load() must take place!
return Update();
}
@@ -1278,11 +1278,25 @@
bool cMarks::Update(void)
{
time_t t = time(NULL);
- if (t - lastUpdate > MARKSUPDATEDELTA) {
- lastUpdate = t;
- t = LastModifiedTime(fileName);
- if (t > lastFileTime) {
- lastFileTime = t;
+ if (t > nextUpdate) {
+ time_t LastModified = LastModifiedTime(fileName);
+ int d;
+ if (LastModified > 0) // the file exists
+ d = t - LastModified;
+ else { // the file doesn't exist
+ if (lastFileTime <= 0)
+ lastFileTime = t - 2; // -2 makes sure we don't miss an update within the very same second
+ d = t - lastFileTime;
+ }
+ if (d < 60)
+ d = 1; // check frequently if the file has just been modified
+ else if (d < 3600)
+ d = 10; // older files are checked less frequently
+ else
+ d /= 360; // phase out checking for very old files
+ nextUpdate = t + d;
+ if (LastModified > lastFileTime) {
+ lastFileTime = LastModified;
cMutexLock MutexLock(&MutexMarkFramesPerSecond);
MarkFramesPerSecond = framesPerSecond;
if (cConfig<cMark>::Load(fileName)) {
===================================================================
RCS file: ./RCS/recording.h
retrieving revision 2.16
@@ -192,7 +192,7 @@
private:
cString fileName;
double framesPerSecond;
- time_t lastUpdate;
+ time_t nextUpdate;
time_t lastFileTime;
public:
bool Load(const char *RecordingFileName, double FramesPerSecond = DEFAULTFRAMESPERSECOND, bool IsPesRecording = false);