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
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
Hi,
Klaus Schmidinger wrote:
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 ;-)
Ok, i don't would break the prior codings style.
Here is a reformated patch, that too implement moving channels via svdrp.
Andreas
Andreas Brachold wrote:
Hi,
Klaus Schmidinger wrote:
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 ;-)
Ok, i don't would break the prior codings style.
Here is a reformated patch, that too implement moving channels via svdrp.
Thanks, added for version 1.3.32. Although, the formatting was still pretty off... ;-) I wonder what it is with people not putting a blank between 'if' and the opening '(', or after a ','...
Klaus
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
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.
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
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,
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
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,
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
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,
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
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,
-
Andreas Brachold -
C.Y.M -
Klaus Schmidinger -
Udo Richter