[PATCH] Invalidate /video cache _after_ cutting

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

 



Artur Skawina wrote:
> When a new recording is started vdr touches the .update file so that all 
> vdrs using the same /video directory rescan the tree and discover the 
> new data. While this makes sense for 'normal' recordings (makes it 
> possible to watch an ongoing recording on another vdr), it also happens 
> when the cutting process is started. This causes all other vdrs to 
> almost immediately reread the /video tree while the disk is busy -- both 
> the cutting process and the clients are significantly slowed down.
> This change lets the horde of vdrs loose _after_ the cutting is 
> finished. Edited recordings appear on other vdrs first when they are 
> finished.
> 
> artur
> 
> 
> ------------------------------------------------------------------------
> 
> diff -urNp vdr-1.4.1.org/cutter.c vdr-1.4.1-tr/cutter.c
> --- vdr-1.4.1.org/cutter.c	2006-02-12 10:07:23.000000000 +0000
> +++ vdr-1.4.1-tr/cutter.c	2006-07-07 13:42:10.000000000 +0000
> @@ -171,6 +171,7 @@ void cCuttingThread::Action(void)
>                   LastMark = true;
>                }
>             }
> +     Recordings.TouchUpdate();
>       }
>    else
>       esyslog("no editing marks found!");
> @@ -205,7 +206,7 @@ bool cCutter::Start(const char *FileName
>          // XXX
>          editedVersionName = strdup(evn);
>          Recording.WriteInfo();
> -        Recordings.AddByName(editedVersionName);
> +        Recordings.AddByName(editedVersionName, false);
>          cuttingThread = new cCuttingThread(FileName, editedVersionName);
>          return true;
>          }
> diff -urNp vdr-1.4.1.org/recording.c vdr-1.4.1-tr/recording.c
> --- vdr-1.4.1.org/recording.c	2006-04-29 13:22:20.000000000 +0000
> +++ vdr-1.4.1-tr/recording.c	2006-07-07 13:42:10.000000000 +0000
> @@ -970,7 +970,7 @@ cRecording *cRecordings::GetByName(const
>    return NULL;
>  }
>  
> -void cRecordings::AddByName(const char *FileName)
> +void cRecordings::AddByName(const char *FileName, bool TriggerUpdate)
>  {
>    LOCK_THREAD;
>    cRecording *recording = GetByName(FileName);
> @@ -978,7 +978,8 @@ void cRecordings::AddByName(const char *
>       recording = new cRecording(FileName);
>       Add(recording);
>       ChangeState();
> -     TouchUpdate();
> +     if (TriggerUpdate)
> +        TouchUpdate();
>       }
>  }
>  
> diff -urNp vdr-1.4.1.org/recording.h vdr-1.4.1-tr/recording.h
> --- vdr-1.4.1.org/recording.h	2006-04-09 13:47:11.000000000 +0000
> +++ vdr-1.4.1-tr/recording.h	2006-07-07 13:42:10.000000000 +0000
> @@ -133,7 +133,7 @@ public:
>    bool StateChanged(int &State);
>    void ResetResume(const char *ResumeFileName = NULL);
>    cRecording *GetByName(const char *FileName);
> -  void AddByName(const char *FileName);
> +  void AddByName(const char *FileName, bool TriggerUpdate = 1);
>    void DelByName(const char *FileName);
>    int TotalFileSizeMB(void); ///< Only for deleted recordings!
>    };

What if a recording starts or is deleted while the cutter is
running? That would also trigger a reread for all other VDRs.

Besides, the cutter itself as well as the reread of the other VDRs
are done in separate threads. Does this really slow down the
user interface in such a way that's worth this extra handling
(which isn't even complete, see above)?

Klaus


[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