[vdr] [PATCH] vdr-1.7.31 small improvement for last viewed recording
Hi,
attached is a small patch which I find very useful.
It extends the (Re)PlayButton.
If no last viewed recording was set (mostly after restart of vdr) and
you press the Play Button all Recordings will be shown.
Would be nice, if it find's a way into the main vdr.
BR,
Alex
--- vdr.c.orig 2012-09-24 14:43:04.0 +0200
+++ vdr.c 2012-10-03 10:11:26.775120496 +0200
@@ -1238,6 +1238,9 @@
cControl::Shutdown();
cControl::Launch(new cReplayControl);
}
+ else {
+ DirectMainFunction(osRecordings);
+ }
break;
default:break;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.31 small improvement for last viewed recording
Am 03.10.2012 10:36, schrieb AlexW: If no last viewed recording was set (mostly after restart of vdr) and you press the Play Button all Recordings will be shown. Nice idea. But I think the idea of having the play button have more functionality can be improved further. For one thing, a feature that I always wanted to implement, but never got to, is to remember the last playback across restarts, so you can easily stop watching, shut down, restart later, and just hit play to continue. Shouldn't be too difficult. Obviously, this would make your idea mostly useless. On a second thought however, VDR could react differently when reaching the end of a recording, compared to stopping in the middle. When played back to the end, hitting play would show the last 10 seconds again, something you probably don't want. Instead, VDR could show the recordings folder the recording was in, so you can for example pick the next following recording. Or if you really want to see that recording, just hit play again. I really like the idea of starting up VDR, hit play, and either continue to watch the last recording I've seen, or to start watching the next following recording. Thoughts on that? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.31 small improvement for last viewed recording
On 03.10.2012 12:22, Udo Richter wrote: Am 03.10.2012 10:36, schrieb AlexW: If no last viewed recording was set (mostly after restart of vdr) and you press the Play Button all Recordings will be shown. Nice idea. But I think the idea of having the play button have more functionality can be improved further. For one thing, a feature that I always wanted to implement, but never got to, is to remember the last playback across restarts, so you can easily stop watching, shut down, restart later, and just hit play to continue. Shouldn't be too difficult. This could be done by simply storing the name of the last viewed recording in setup.conf. Obviously, this would make your idea mostly useless. Not really. If the last viewed recording has been deleted, this new functionality could still kick in (and it will, since I've already adopted this patch for verison1.7.32 ;-). Besides, I have added the same functionality to the Blue key in the main menu. On a second thought however, VDR could react differently when reaching the end of a recording, compared to stopping in the middle. When played back to the end, hitting play would show the last 10 seconds again, something you probably don't want. Instead, VDR could show the recordings folder the recording was in, so you can for example pick the next following recording. Or if you really want to see that recording, just hit play again. I really like the idea of starting up VDR, hit play, and either continue to watch the last recording I've seen, or to start watching the next following recording. Thoughts on that? Sounds way too complex for my taste. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
Am 30.09.2012 15:41, schrieb Klaus Schmidinger: - The new class cIoThrottle is used to allow I/O intense threads to temporarily suspend their activities in case buffers run full (suggested by Torsten Lang). Currently the cutter thread is suspended if the TS or Recorder buffer use more than 50% of their capacity. Plugin authors may want to participate in this mechanism if they use intense background I/O. I'd suggest to use this for the low disk space deleted recording cleanup too. Recently, I've seen an issue like this happen, using VDR-1.7.30, where my disk was nearly full, and some deleted recordings didn't get wiped before a new recording. After a while, two HD recordings running at that time, AssertFreeDiskSpace kicked in and cleaned a deleted recording to free up disk space, resulting in an buffer overflow for the recorder: 02:08:31 low disk space while recording, trying to remove a deleted recording... 02:08:31 removing recording /video/...del 02:08:31 removing /video/...del/1.ts [...] 02:08:37 removing /video/...del/00100.ts 02:08:37 removing /video/...del/resume 02:08:37 removing /video/...del/marks 02:08:37 removing /video/...del 02:08:38 max. latency time 7 seconds 02:08:43 buffer usage: 70% (tid=27204) 02:08:43 buffer usage: 80% (tid=27204) 02:08:44 buffer usage: 90% (tid=27204) 02:08:44 buffer usage: 100% (tid=27204) 02:08:44 ERROR: 1 ring buffer overflow (1 bytes dropped) 02:08:44 buffer usage: 70% (tid=27187) 02:08:44 buffer usage: 60% (tid=27187) 02:08:45 ERROR: skipped 187 bytes to sync on start of TS packet 02:08:45 ERROR: skipped 187 bytes to sync on start of TS packet 02:08:45 cNaluDumper: TS continuity offset 6 02:08:45 buffer usage: 0% (tid=27204) The deleting was surprisingly slow, probably because of the high disk fill and fragmentation. And for some reason, the overflow happened after the deleting. Not sure what caused the delay. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.31 small improvement for last viewed recording
Am 03.10.2012 12:28, schrieb Klaus Schmidinger: Not really. If the last viewed recording has been deleted, this new functionality could still kick in The patch above just checks the string presence. It should also check whether the string is an existing recording then. Sounds way too complex for my taste. Not necessarily. One way: When hitting play, check whether LastReplay exists, is a recording, and check whether the replay index is far from the file end. If not, show recordings menu. Another way: When writing index-StoreResume() in dvbplayer, check for file end and set a flag remembering that. Maybe together with LastReplayed file. Then, when hitting play, check for that flag and show recordings menu instead. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.31 small improvement for last viewed recording
On 03.10.2012 13:29, Udo Richter wrote: Am 03.10.2012 12:28, schrieb Klaus Schmidinger: Not really. If the last viewed recording has been deleted, this new functionality could still kick in The patch above just checks the string presence. It should also check whether the string is an existing recording then. When a recording is deleted, cReplayControl::ClearLastReplayed() sets that string to NULL in case it is the deleted recording. Sounds way too complex for my taste. Not necessarily. One way: When hitting play, check whether LastReplay exists, is a recording, and check whether the replay index is far from the file end. If not, show recordings menu. Another way: When writing index-StoreResume() in dvbplayer, check for file end and set a flag remembering that. Maybe together with LastReplayed file. Then, when hitting play, check for that flag and show recordings menu instead. Don't like it. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
On 03.10.2012 13:03, Udo Richter wrote:
Am 30.09.2012 15:41, schrieb Klaus Schmidinger:
- The new class cIoThrottle is used to allow I/O intense threads to temporarily
suspend their activities in case buffers run full (suggested by Torsten
Lang).
Currently the cutter thread is suspended if the TS or Recorder buffer use
more
than 50% of their capacity. Plugin authors may want to participate in this
mechanism if they use intense background I/O.
I'd suggest to use this for the low disk space deleted recording cleanup too.
Recently, I've seen an issue like this happen, using VDR-1.7.30, where my disk
was nearly full, and some deleted recordings didn't get wiped before a new
recording.
I guess this should do the trick:
--- recording.c 2012/09/30 13:05:14 2.64
+++ recording.c 2012/10/03 12:52:13
@@ -97,6 +97,8 @@
bool deleted = false;
cThreadLock DeletedRecordingsLock(DeletedRecordings);
for (cRecording *r = DeletedRecordings.First(); r; ) {
+ if (cIoThrottle::Engaged())
+return;
if (r-Deleted() time(NULL) - r-Deleted() DELETEDLIFETIME) {
cRecording *next = DeletedRecordings.Next(r);
r-Remove();
The deleting was surprisingly slow, probably because of the high disk fill and
fragmentation. And for some reason, the overflow happened after the deleting.
Not sure what caused the delay.
Which file system are you using for your video directory?
I recently switched from ext3 to ext4 and it does feel a little snappier.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.31
Am 03.10.2012 14:55, schrieb Klaus Schmidinger: Which file system are you using for your video directory? I recently switched from ext3 to ext4 and it does feel a little snappier. Its an XFS disk, and it was surprisingly fast on deleting when it was fresh. Unfortunately, #df -m /video Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/lvm--disk-data 948568943016 5553 100% /mnt/data which is not a good use% to run any file system on long term. :( Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
