diff mbox

vdr-1.3.31 - Wrong recording state after playback on cMenuRecordings

Message ID 1125738125.6283.14.camel@wopr.deltab.de
State New
Headers

Commit Message

Andreas Brachold Sept. 3, 2005, 9:02 a.m. UTC 
  Hi,

here a small patch avoid wrong recording state after playback on
cMenuRecordings.

Before this patch on cMenuRecordings new recordings always
marked with "*" even if it was already played.
Only a external trigged rescan of full video directory has 
this updated.
Now with this patch is the recording state after playback on
cMenuRecordings proper. And it reload only associated resume.vdr.



Andreas


BTW : Is there any chance that my patch for SVDRP/MOVC integrated,
it completed only the listed SVDRP commands !?
This function a missed for external channels editing.
http://www.linuxtv.org/pipermail/vdr/2005-August/004512.html

Comments

Klaus Schmidinger Sept. 3, 2005, 10:11 a.m. UTC | #1 
Andreas Brachold wrote:
> ...
> BTW : Is there any chance that my patch for SVDRP/MOVC integrated,
> it completed only the listed SVDRP commands !?
> This function a missed for external channels editing.
> http://www.linuxtv.org/pipermail/vdr/2005-August/004512.html

Chances would be better if you had structured and formatted it the
same way all the other SVDRP command functions are formatted ;-)

Klaus
Udo Richter Sept. 3, 2005, 4:47 p.m. UTC | #2 
Andreas Brachold wrote:
> here a small patch avoid wrong recording state after playback on
> cMenuRecordings.

I'm using another well done patch for this old bug, published here:
http://www.vdrportal.de/board/thread.php?threadid=31248

Cheers,

Udo
C.Y.M Sept. 3, 2005, 5:24 p.m. UTC | #3 
Udo Richter wrote:
> Andreas Brachold wrote:
> 
>>here a small patch avoid wrong recording state after playback on
>>cMenuRecordings.
> 
> 
> I'm using another well done patch for this old bug, published here:
> http://www.vdrportal.de/board/thread.php?threadid=31248
> 

Should these two patches be integrated?

Re.
Udo Richter Sept. 3, 2005, 8:25 p.m. UTC | #4 
C.Y.M wrote:
> Udo Richter wrote:
>> Andreas Brachold wrote:
>>> here a small patch avoid wrong recording state after playback on
>>> cMenuRecordings.
>>
>> I'm using another well done patch for this old bug, published here:
>> http://www.vdrportal.de/board/thread.php?threadid=31248
> 
> Should these two patches be integrated?

Well, at most /one/ of these patches. They do basically the same. The
one of TomG does it a little bit smarter though.

But since the recordings list is officially confirmed to be a "lo(o)se
end" for 1.4, Klaus' might skip it for some bigger and better solution.

Cheers,

Udo
C.Y.M Sept. 3, 2005, 9:26 p.m. UTC | #5 
Udo Richter wrote:
> C.Y.M wrote:
> 
>>Udo Richter wrote:
>>
>>>Andreas Brachold wrote:
>>>
>>>>here a small patch avoid wrong recording state after playback on
>>>>cMenuRecordings.
>>>
>>>I'm using another well done patch for this old bug, published here:
>>>http://www.vdrportal.de/board/thread.php?threadid=31248
>>
>>Should these two patches be integrated?
> 
> 
> Well, at most /one/ of these patches. They do basically the same. The
> one of TomG does it a little bit smarter though.
> 
> But since the recordings list is officially confirmed to be a "lo(o)se
> end" for 1.4, Klaus' might skip it for some bigger and better solution.
> 

Yes, I have been using Tom's patch for a while now.  But, this new patch from
Andreas fixes VDR's recording menu so the (*) astersk is removed after replaying
a new recording.  I have found that if I create a recording with VDR, then cut
and process the cuts with VDR before I play it, the astersk never goes away
(still indicating that the recording has never been played).  This only happens
if I cut the recording before playing it first.

Re,
Udo Richter Sept. 3, 2005, 10:56 p.m. UTC | #6 
C.Y.M wrote:
> Yes, I have been using Tom's patch for a while now.  But, this new patch from
> Andreas fixes VDR's recording menu so the (*) astersk is removed after replaying
> a new recording.  I have found that if I create a recording with VDR, then cut
> and process the cuts with VDR before I play it, the astersk never goes away
> (still indicating that the recording has never been played). 

Strange. I also cut almost everything, since I am a 'keep it until the 
space is needed otherwise' type.

For me, Tom's patch works fine, anyway whether its a cut or uncut 
recording, the asterisk is only shown if the resume pointer points to 
the beginning of the recording.

> This only happens
> if I cut the recording before playing it first.

How do you cut a recording without playing it at least once? ;)

Cheers,

Udo
C.Y.M Sept. 4, 2005, 1:05 a.m. UTC | #7 
Udo Richter wrote:
> 
> How do you cut a recording without playing it at least once? ;)
> 

Hehe.. thats a good point.  Please let me rephrase that. The asterisk does not
go away in the recording menu until I play the new recording, then stop it, and
then view it in the recordings menu a second time.  But, if I cut/process a
recording the first time I play it, before the asterisk is removed, it seems to
get stuck there in the processed recording title (starting with a "%" symbol).
With Andreas' patch, the asterisk does not appear to get "stuck" there anymore
after replaying.

Re,
Udo Richter Sept. 4, 2005, 1:57 a.m. UTC | #8 
C.Y.M wrote:
> But, if I cut/process a
> recording the first time I play it, before the asterisk is removed, it seems to
> get stuck there in the processed recording title (starting with a "%" symbol).

So if you cut *Title, the cut recording is named *%*Title? Or just
*%Title and the * never goes away? You're sure you've been using exactly
that version of the patch?

Really, that doesn't happen for me. The edit mark gets updated instantly
for cut and uncut recordings. It disappears if the resume position is
somewhere in the recording, and re-appears as soon as the recording is
rewinded. The update happens the moment I leave the replay mode.

Do you use patches that modify the cutting behavior? Any automatic
messing with resume.vdr files? Skins other than STTNG?

Cheers,

Udo
C.Y.M Sept. 4, 2005, 2:14 a.m. UTC | #9 
Udo Richter wrote:
> C.Y.M wrote:
> 
>>But, if I cut/process a
>>recording the first time I play it, before the asterisk is removed, it seems to
>>get stuck there in the processed recording title (starting with a "%" symbol).
> 
> 
> So if you cut *Title, the cut recording is named *%*Title? Or just
> *%Title and the * never goes away? You're sure you've been using exactly
> that version of the patch?

Yes, I cut *Title, then the cut recording is named *%Title and the "*" never
goes away.  I have been using Tom's patch for quite some time.

> 
> Really, that doesn't happen for me. The edit mark gets updated instantly
> for cut and uncut recordings. It disappears if the resume position is
> somewhere in the recording, and re-appears as soon as the recording is
> rewinded. The update happens the moment I leave the replay mode.
> 
> Do you use patches that modify the cutting behavior? Any automatic
> messing with resume.vdr files? Skins other than STTNG?
> 

I am also using the jumpplay patch which modifys the cutting behavior... hmm.

Re,
Udo Richter Sept. 4, 2005, 3:02 a.m. UTC | #10 
C.Y.M wrote:
> Yes, I cut *Title, then the cut recording is named *%Title and the "*" never
> goes away.  I have been using Tom's patch for quite some time.

Here's a walkthrough I just did on my machine:

Starting point: Recording *Test, freshly un-touched recording.
-> Start playback, set two editing marks, press 2, wait.
Result: *Test and *%Test in recording menu.
-> Stop playback.
Result: Test and *%Test
-> Start playback of cut recording, seek forward
Result: Test and *%Test
-> Stop playback
Result: Test and %Test


The strange thing is: Cut recordings and un-cut recordings only differ 
by their name. The only situation in which VDR differentiates between 
cut and uncut recordings (IsEdited()) is automatic cleanup on low disk 
space. How should this affect resume file updates?

Cheers,

Udo
C.Y.M Sept. 4, 2005, 1:08 p.m. UTC | #11 
Udo Richter wrote:
> C.Y.M wrote:
> 
>> Yes, I cut *Title, then the cut recording is named *%Title and the "*"
>> never
>> goes away.  I have been using Tom's patch for quite some time.
> 
> 
> Here's a walkthrough I just did on my machine:
> 
> Starting point: Recording *Test, freshly un-touched recording.
> -> Start playback, set two editing marks, press 2, wait.
> Result: *Test and *%Test in recording menu.
> -> Stop playback.
> Result: Test and *%Test
> -> Start playback of cut recording, seek forward
> Result: Test and *%Test
> -> Stop playback
> Result: Test and %Test
> 
> 
> The strange thing is: Cut recordings and un-cut recordings only differ
> by their name. The only situation in which VDR differentiates between
> cut and uncut recordings (IsEdited()) is automatic cleanup on low disk
> space. How should this affect resume file updates?
> 

Maybe it was something else in the past, but I just double checked using only
Tom's patch with vdr-1.3.31 and its now working too.  I must have had something
else wrong at the time.  Sorry for all the confusion.. I'm glad you made me
double check :)  Please disregard my previous wild accusations. :)

Re,
diff mbox

Patch

diff -Nur vdr-1.3.31.org/menu.c vdr-1.3.31/menu.c
--- vdr-1.3.31.org/menu.c	2005-08-27 11:37:23.000000000 +0200
+++ vdr-1.3.31/menu.c	2005-09-03 10:24:00.000000000 +0200
@@ -1616,6 +1616,7 @@ 
         cRecording *recording = GetRecording(ri);
         if (recording) {
            cReplayControl::SetRecording(recording->FileName(), recording->Title());
+           recording->ResetResumeCache(); //reload resume for next menu opening
            return osReplay;
            }
         }
diff -Nur vdr-1.3.31.org/recording.c vdr-1.3.31/recording.c
--- vdr-1.3.31.org/recording.c	2005-08-13 16:00:48.000000000 +0200
+++ vdr-1.3.31/recording.c	2005-09-03 10:26:04.000000000 +0200
@@ -562,6 +562,11 @@ 
   return resume;
 }
 
+void cRecording::ResetResumeCache(void) 
+{ 
+    resume = RESUME_NOT_INITIALIZED; 
+}
+
 int cRecording::Compare(const cListObject &ListObject) const
 {
   cRecording *r = (cRecording *)&ListObject;
diff -Nur vdr-1.3.31.org/recording.h vdr-1.3.31/recording.h
--- vdr-1.3.31.org/recording.h	2005-08-13 16:09:50.000000000 +0200
+++ vdr-1.3.31/recording.h	2005-09-03 10:26:03.000000000 +0200
@@ -78,6 +78,7 @@ 
   const char *PrefixFileName(char Prefix);
   int HierarchyLevels(void) const;
   bool IsNew(void) const { return GetResume() <= 0; }
+  void ResetResumeCache(void);
   bool IsEdited(void) const;
   bool WriteInfo(void);
   bool Delete(void);