Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Hi list, In the 'final' 1.0 version of the shutdown patch, and in VDR 1.5.1, a small bug slipped through that prevented automatic shutdown after VDR started for a recording only. I've uploaded a new 1.1 version of the patches for VDR 1.4.5, VDR 1.5.0 and VDR 1.5.1 to my web page: http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown The minimal patch for 1.5.1 should also work on the shutdown-1.0-patched VDR 1.4.5/1.5.0 versions, and doesn't require plugins to be recompiled. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, final
On 2/27/07, Marko Mäkelä [EMAIL PROTECTED] wrote: This would be similar to analog VCRs, which obviously remember the position even after being unplugged. VCR's don't remember anything related to position, it's the tape itself that moves (from one reel to the other), not the head in the VCR. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, final
On Sat, Mar 03, 2007 at 04:36:03PM +0100, Klaus Schmidinger wrote: Sorry, I forgot one feature request. In a private discussion with Klaus a long time ago (around vdr 1.3.30), Klaus mentioned the idea of VDR remembering the name of the last replayed recording across shutdowns. That is, you could press Play to resume whatever you were watching before powering off VDR. This would be similar to analog VCRs, which obviously remember the position even after being unplugged. This has nothing to do with the actual shutdown stuff. VDR just needs to store this information in its setup.conf. Well, in a sense it has something to do with shutdown, because if VDR were never restarted, storing the information in setup.conf would be useless. I hope that you wrote this down on your secret TODO list. :-) Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, final
Hi list, Now that VDR 1.5.1 was published, I've also published the final 1.0 version of the shutdown rewrite. The changes since 0.4 are mainly by Klaus. http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown The patch is identical to the changes of VDR 1.5.1, except that no functions were dropped, for compatibility. Also, the detection define is present, and should be used like this: #if VDRVERSNUM = 10501 || (defined(PATCH_SHUTDOWN_REWRITE) PATCH_SHUTDOWN_REWRITE = 100) ... #else ... #endif Changes: - Identifiers changed: cShutdown - cShutdownHandler Shutdown - ShutdownHandler - cRemote::LastActivity() now returns an absolute time, not a relative! - Dropped cThread::EmergencyExit (still present in this patch for compatibility) - Rearranged signal handling, report all signals instantly to syslog - ISREALKEY macro to check whether a key is user-generated - Some new timeout constants in vdr.c - Updated man page regarding SIGHUP - Coding style rewrite by Klaus, slight changes in documentation, comments and i18n strings Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Udo Richter wrote: Matthias Schwarzott wrote: In gentoo vdr package we added a small hack (attached), which implements a svdrp call down to tell vdr it is inactive and will shutdown in X minutes. We call this from shutdown-scripts to let vdr retry shutdown in 5 min (or other value if needed). Question is: Is this still needed? VDR already retries after an acceptable time, and VDR probably knows better whether an user is currently active or not. The only reason I could think of is that VDR was started without a timer nearby, and the start script knows that this is not an user start. And sending a kPower key press will also let VDR go inactive. Things were different in old versions, where VDR retried shutdown after 3 hours or so, but that has changed. I assume that with the ability to force a reload by sending SIGHUP to the vdr process (which will be included in the upcoming version 1.5.1) this should not be necessary any more. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote: - Added #define PATCH_SHUTDOWN_REWRITE to detect the patch Use #if VDRVERSNUM = 105xx || defined(PATCH_SHUTDOWN_REWRITE) after final integration into VDR. Now that VDR 1.5.1 includes the patch, I wonder if you are going to maintain the patch for vdr 1.4, or at least continue to host the latest version on your home page. I strongly hope so, because I am reluctant to switch my production system to the development branch until that branch stabilizes or introduces significant new features, such as support for UTF-8 locales or DVB subtitles. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Sun, Feb 25, 2007 at 09:11:36PM +0200, Marko Mäkelä wrote: On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote: - Added #define PATCH_SHUTDOWN_REWRITE to detect the patch Use #if VDRVERSNUM = 105xx || defined(PATCH_SHUTDOWN_REWRITE) after final integration into VDR. Now that VDR 1.5.1 includes the patch, I wonder if you are going to maintain the patch for vdr 1.4, or at least continue to host the latest version on your home page. I hope that you can release a 0.5 version of your patch that corresponds to what is included in VDR 1.5.1. Most notably, please rename the global variable Shutdown to ShutdownHandler. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4
Udo Richter wrote:
I've finished a fourth version of the shutdown rewrite. Again there are
two patches available, one for VDR 1.5.0, and one with slight changes
for 1.4.x.
Changes:
- Handle setup menu restart questions in cShutdown::ConfirmRestart()
- Act differently on SIGHUP:
Restart VDR like on setup menu restart, but dont ask questions.
Well, that was the intention. Next time I'll do it, promise! ;)
The attached patch fixes this and actually calls ConfirmRestart, not
ConfirmShutdown.
Beside that, things are getting close to land in VDR 1.5.x, so any last
minute bug hunting is welcome.
Cheers,
Udo
--- vdr.c.old 2007-02-24 22:36:26.707746080 +0100
+++ vdr.c 2007-02-24 22:38:21.012241392 +0100
@@ -1169,7 +1169,7 @@
if (LastSignal == SIGHUP) {
LastSignal = 0;
// Confirm for any activity that blocks a restart
- if (!Shutdown.ConfirmShutdown(true))
+ if (!Shutdown.ConfirmRestart(true))
// Not confirmed, cancel.
break;
--- menu.c.old 2007-02-24 22:36:23.037304072 +0100
+++ menu.c 2007-02-24 22:38:15.016152936 +0100
@@ -2726,7 +2726,7 @@
return osContinue;
// Confirm for any activity that blocks a restart
- if (!Shutdown.ConfirmShutdown(true))
+ if (!Shutdown.ConfirmRestart(true))
// Not confirmed, cancel.
return osContinue;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
Marko Mäkelä wrote: On Tue, Feb 20, 2007 at 08:52:20AM +0200, Rolf Ahrenberg wrote: On Mon, 19 Feb 2007, Udo Richter wrote: Rolf Ahrenberg wrote: I've one question about this sentence: Plugin %s wakes up in %ld min, continue? If I'm pressing 'OK' here, does it continue the shutdown or running the VDR? I don't like it either, but didn't come up with a good other idea for this. For consistency it should be Plugin %s wakes up in %ld minutes, restart anyway?, but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again. My vote goes to dropping the plugin name as it doesn't provide (imho) any valuable information for the user. Do we really need to know that a femon or relay plugin is about to wakeup in ten minutes, when we are restarting the VDR? I'd say: no. Well, then the name of the plugin should be written to the log, for troubleshooting. Or is it necessary to say Plugin %s wakes up? Would it be enough to say %s wakes up? I'd guess that many plugin names are shorter than the translation of Plugin in many languages. Hmm, many languages don't seem to translate the word Plugin, but the Estonian and Finnish translations are among the longest ones. It's better to see which plugin is wanting to prevent the operation than simply something is preventing. The word 'Plugin' on the other hand is unnecessary, IMO. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
On 2/20/07, Marko Mäkelä [EMAIL PROTECTED] wrote: Would it be enough to say %s wakes up? That's fine if you don't mind using poor grammar. For example, femon wakes up? makes absolutely no sense. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
On Sun, 18 Feb 2007, Marko Mäkelä wrote: On Sun, Feb 18, 2007 at 10:09:54PM +0100, Udo Richter wrote: Editing - shut down anyway? ( no longer cutting ;) ) Schneide - trotzdem ausschalten? Leikkaus kesken - sammutetaanko? Hmm, this is inconsistent with most Finnish translations of editing (muokkaus) in i18n.c. I'd replace Leikkaus with Muokkaus. As Udo wrote it's no longer cutting (leikkaus), but editing (muokkaus), so the correct translation should be: Muokkaus kesken - sammutetaanko? Editing - restart anyway? Schneide - trotzdem neu starten? Muokkaus kesken - käynnistetäänkö uudelleen? Press any key to cancel restart Taste drücken, um Neustart abzubrechen Peru uudelleenkäynnistäminen painamalla mitä tahansa nappia Shouldn't it be button (Knopf) instead of key (Taste)? I would guess that most people control vdr with a remote control unit instead of a keyboard. Besides, nappia is shorter than näppäintä (as in the Finnish translation of Press any key to cancel shutdown). Well, I disagree in finnish terms: Paidassani on nappeja, mutta näppäimistössäni ja kaukosäätimessäni on näppäimiä. Otherwise these sounds quite ok, but I'd use uudelleenkäynnistys instead of uudelleenkäynnistäminen as this should be consistent with existing VDR translation: Press any key to cancel restart Peru uudelleenkäynnistys painamalla mitä tahansa näppäintä Press any key to cancel shutdown Peru sammutus painamalla mitä tahansa näppäintä I's also change this: VDR sammuu myöhemmin - pakota virtakytkimellä to VDR sammuu myöhemmin - pakota virtanäppäimellä Notice, that this should be corrected also in current VDR's i18n.c. I've one question about this sentence: Plugin %s wakes up in %ld min, continue? If I'm pressing 'OK' here, does it continue the shutdown or running the VDR? BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
On Mon, 19 Feb 2007, Udo Richter wrote: Rolf Ahrenberg wrote: I've one question about this sentence: Plugin %s wakes up in %ld min, continue? If I'm pressing 'OK' here, does it continue the shutdown or running the VDR? I don't like it either, but didn't come up with a good other idea for this. For consistency it should be Plugin %s wakes up in %ld minutes, restart anyway?, but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again. My vote goes to dropping the plugin name as it doesn't provide (imho) any valuable information for the user. Do we really need to know that a femon or relay plugin is about to wakeup in ten minutes, when we are restarting the VDR? I'd say: no. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4
Hi list, I've finished a fourth version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x. http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown Changes: - Renamed some identifiers: cSetup::NextWakeupEvent - cSetup::NextWakeupTime cPlugin::NextWakeupEvent() - cPlugin::WakeupTime() cPluginManager::GetNextWakeupEventPlugin() - cPluginManager::GetNextWakeupPlugin() - Dropped running playback from the list of things that need confirmation on shutdown. Pressing power key while playback now shuts down just like in live mode. Automatic inactivity shutdown still wont happen while playback, since playback blocks housekeeping. - Handle setup menu restart questions in cShutdown::ConfirmRestart() - Do not handle setup menu restart as 'emergency exit' any more - Act differently on SIGHUP: Restart VDR like on setup menu restart, but dont ask questions. Do nothing if anything blocks restart. - The functionality of cThread::EmergencyExit(), vdr.c:ExitCode and vdr.c:Interrupted is now handled by cShutdown. - Shutdown.Exit(int) now stops the main loop and lets VDR return int as error level - cThread::EmergencyExit() remains as a wrapper - vdr.c:LastSignal partially replaces vdr.c:Interrupted - Dropped debug output from main loop - i18n strings added for German and Finnish: VDR will shut down later - Press power to force VDR schaltet später aus - Nochmal zum erzwingen VDR sammuu myöhemmin - pakota virtakytkimellä VDR will shut down in %s minutes ( note that %s will be something like 4:30 ) VDR wird in %s Minuten ausschalten VDR sammuu %s minuutin kuluttua Editing - shut down anyway? ( no longer cutting ;) ) Schneide - trotzdem ausschalten? Leikkaus kesken - sammutetaanko? Plugin %s wakes up in %ld min, continue? Plugin %s wacht in %ld Min auf, weiter? Laajennos %s herää %ld minuutin kuluttua - sammutetaanko? ( is this too long? ) Editing - restart anyway? Schneide - trotzdem neu starten? Press any key to cancel restart Taste drücken, um Neustart abzubrechen Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Darren Salt wrote: We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal. An external script could then repeat sending the SIGHUP periodically until termination did succeed. That'd be start-stop-daemon, most likely, which means that the task would have to be backgrounded. Its -R option is useful for this - something like -R forever/-HUP/5, I think - but it's just possible that VDR may become inactive then active without receiving a signal in between. However, that doesn't fit in well with runvdr, or at least with my version In this case I guess your runvdr is the one that should send the signals to VDR, as it also will know if VDR did terminate. And at least your runvdr probably knows your update strategies. I'm currently coding it in a way that SIGHUP issues a VDR restart (exit code 1), if no serious activity (cutting, recording, plugins) is going on - just like the setup menu restart command. Otherwise, the signal is ignored. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
In [EMAIL PROTECTED], Patrick Mackin wrote: Is that HD-capable? HDTV seems quite common in NA, but currently in the UK there are very few HD channels, only available through overpriced subscriptions. It looks unlikely that there'll be any FTA/FTV HD until at least after the analogue terrestrial switch-off in 2012. HDTV is not as common here as the advertising would make you believe. HDTV programming is very limited here also. The famous shut off of analog signals in NA is honestly much ado about nothing (interesting choice in year 2012 by the way). It concerns only OTA HDTV terrestrial reception, and in America, the vast majority of households (90%+) subscribe to cable or satellite. The remaining 10% are the homes that are too poor to afford an HDTV, and therefore won't care about OTA HDTV signals. Sorry to bring this up again, but the situation is worse than I thought. I've just heard that when UK analogue TV is discontinued, the government plans to sell off the bandwidth to the highest bidder (probably a mobile phone company) rather than use it for HDTV. So please could all UK readers visit http://www.hdforall.org.uk and sign both petitions. At least in N America HDTV can be considered mainstream in that, even if you have to pay for them, a lot of the prime shows eg Lost, 24, Prison Break, are available in HD. In the UK you've got a choice between Sky and cable (if you happen to live in the right area for the one with HD). AFAICT from browsing my Sky EPG Sky's own HD channels show non-HD material most of the time. BBC's HD channel has only demos, old non-HD shows, and the same costume drama that they've been showing every day since the servie was launched. You do get National Geographic HD. In terms of content I prefer Discovery, but they can't even manage widescreen yet! Apparently on Telewest cable you don't get any of the above except BBC. You also get an ITV HD channel which has about as much fresh material as the BBC one, and you can get old movies on demand (so that would be pay-per-view presumably). -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Darren Salt wrote: I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some Min User Inactivity setting, or else live viewing could be interrupted by the automatic update. The user inactivity setting isn't relevant to that, AFAICS. If you want to do the update while there's no ongoing activity, then you'll need some kind of user inactivity, otherwise a live viewer would be interrupted instantly. For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts. (Did you mean exits?) Actually, exists, in the sense that the name of a script has been set using the Shutdown.SetShutdownCommand() call. The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless. Ok, a suggestion how this could be done in a simple and useful way: We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal. An external script could then repeat sending the SIGHUP periodically until termination did succeed. Also, the SIGHUP effect is not delayed for an indefinite time and wont strike unexpected / needs thoughts on how to cancel the SIGHUP if you change your mind. And on SVDRP: Since the SVDRP rewrite is on the todo list anyway, we could add support to do SVDRP on unix domain sockets, not just TCP. Domain sockets are represented by files (like for example /etc/vdr/svdrp.socket) and access rights are controlled by the file system. This would allow to open SVDRP only for the local root, or just for the local video user group. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I demand that Udo Richter may or may not have written... Darren Salt wrote: I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some Min User Inactivity setting, or else live viewing could be interrupted by the automatic update. The user inactivity setting isn't relevant to that, AFAICS. If you want to do the update while there's no ongoing activity, then you'll need some kind of user inactivity, otherwise a live viewer would be interrupted instantly. Local policy would seem to be the best way to handle this. For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts. (Did you mean exits?) Actually, exists, in the sense that the name of a script has been set using the Shutdown.SetShutdownCommand() call. Bad choice of word - the obvious meaning of the phrase is when the script is created. The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless. Ok, a suggestion how this could be done in a simple and useful way: We re-define SIGHUP, so that it doesn't terminate VDR instantly, but instead checks for activity. If user and vdr is inactive, act just like sigterm, if there's some activity, ignore the signal. An external script could then repeat sending the SIGHUP periodically until termination did succeed. That'd be start-stop-daemon, most likely, which means that the task would have to be backgrounded. Its -R option is useful for this - something like -R forever/-HUP/5, I think - but it's just possible that VDR may become inactive then active without receiving a signal in between. However, that doesn't fit in well with runvdr, or at least with my version - which you can find in this diff (which can be cleanly applied against an empty directory) as vdr-1.4.5/debian/runvdr.c: URL:http://zap.tartarus.org/~ds/debian/dists/unstable/main/source/vdr_1.4.5-1.ds.diff.gz (Link: URL:http://www.youmustbejoking.demon.co.uk/progs.sid.html#vdr) Also, the SIGHUP effect is not delayed for an indefinite time and won't strike unexpectedly / needs thoughts on how to cancel the SIGHUP if you change your mind. Sending a SIGTERM would obviously cancel it. :-) That aside, I'd probably use SIGUSR1 as a cancellation (which should be as simple as clearing a flag). And on SVDRP: Since the SVDRP rewrite is on the todo list anyway, we could add support to do SVDRP on unix domain sockets, not just TCP. Domain sockets are represented by files (like for example /etc/vdr/svdrp.socket) and access rights are controlled by the file system. This would allow to open SVDRP only for the local root, or just for the local video user group. That could be useful. For my purposes, though, I still prefer signals :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. Pieces of nine! Pieces of nine! ...sorry, parroty error... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Sun, Feb 11, 2007 at 08:11:03PM +, Darren Salt wrote: I demand that VDR User may or may not have written... On 2/8/07, Marko Mäkelä [EMAIL PROTECTED] wrote: (August already?) Hey, I wrote that on 2007-02-08 (ISO date) or 8.2.2007 (German or Finnish style date). I think there are at least 3 permutations of /-separated dates in different locales. In my opinion, the behavior should be that the power button engages an immediate shutdown. Period. An appropriate signal, probably SIGTERM, should also do this. The ONLY exception to this would be if vdr is currently recording something, in which case a warning comes up and asks you to confirm the shutdown. Agreed. SIGHUP. Brilliant idea. This would also simplify the ACPI powerbutton event script, whose name escapes me right now. I modified the script on my system to send HITK Power via SVDRP, but it would be much cleaner and probably somewhat faster to send a signal. Darren, if your packages end up in the official Debian, I hope you will also provide a nice hook for the ACPI powerbutton event. (If vdr is running, signal it. Otherwise, shut down the system normally.) Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I demand that VDR User may or may not have written... On 2/8/07, Marko Mäkelä [EMAIL PROTECTED] wrote: (August already?) On Thu, Feb 08, 2007 at 01:08:33PM +0200, Rolf Ahrenberg wrote: BTW, I'm very used to VDR's current behaviour to shutdown itself after the recording is made and don't want to get rid of that one either. As far as I understand, nobody has suggested that we should get rid of that feature. You could compare this to an analog VCR. I would believe that they refuse to power off when there is a timed recording going on. Yes, exactly. In my opinion, the behavior should be that the power button engages an immediate shutdown. Period. An appropriate signal, probably SIGTERM, should also do this. The ONLY exception to this would be if vdr is currently recording something, in which case a warning comes up and asks you to confirm the shutdown. Agreed. SIGHUP. Then there's the upgrade restart, which should be available via a signal. The actual restart should be deferred if VDR is currently busy. (It is *possible* to implement this via runvdr, but it's a lot easier to handle if VDR can re-exec itself.) [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Patch griefs with proverbs. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Darren Salt wrote: Then there's the upgrade restart, which should be available via a signal. The actual restart should be deferred if VDR is currently busy. (It is *possible* to implement this via runvdr, but it's a lot easier to handle if VDR can re-exec itself.) H. Some kind of i-am-idle-lets-do-a-restart state? I'm not really sure what makes this different to the existing stuff. Surely, an upgrade should not interrupt ongoing activity. If the VDR does automatic shutdown, then the answer is simple: Do your upgrade on next shutdown or restart. Thats the earliest time anyway. I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some Min User Inactivity setting, or else live viewing could be interrupted by the automatic update. Some kind of temporary shutdown script could do the trick. In normal situations, there's no shutdown because of no shutdown script, but in case of pending updates, a temporary shutdown script does the update. For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I demand that Udo Richter may or may not have written... Darren Salt wrote: Then there's the upgrade restart, which should be available via a signal. The actual restart should be deferred if VDR is currently busy. (It is *possible* to implement this via runvdr, but it's a lot easier to handle if VDR can re-exec itself.) H. Some kind of i-am-idle-lets-do-a-restart state? I'm not really sure what makes this different to the existing stuff. Maybe not much. I'm just making sure that what I see as useful here (from a packager's point of view) is heard... Surely, an upgrade should not interrupt ongoing activity. That's reasonable but ISTM that it's something which is best left to the local admin to decide. I'll agree that recording should *normally* never be interrupted (but a forcible shutdown needs to be possible). If the VDR does automatic shutdown, then the answer is simple: Do your upgrade on next shutdown or restart. Thats the earliest time anyway. That's possible, but not always appropriate or even wanted. (It doesn't match how I do things, for a start.) I guess the only situation that may cause a problem is if the VDR never shuts down, eg. has no shutdown script at all. It must have some Min User Inactivity setting, or else live viewing could be interrupted by the automatic update. The user inactivity setting isn't relevant to that, AFAICS. Some kind of temporary shutdown script could do the trick. In normal situations, there's no shutdown because of no shutdown script, but in case of pending updates, a temporary shutdown script does the update. For example, a plugin may be possible that reacts on a SVDRP command (request for update), and that sets a temporary shutdown script (calls Shutdown.SetShutdownCommand()). As soon as the script exists, the inactivity shutdown will be back, but instead of shutting down, the script stops VDR, installs the update and restarts. (Did you mean exits?) That has problems... The update could already be installed. This is normally true when a package manager is used (it's definitely true here - I build .debs for local installation), but could also be true of an early make install. The local admin may have disabled SVDRP or the SVDRP port may be in use (perhaps a buggy plugin, or maybe just bad timing). Sending a signal to the running vdr process works regardless. SVDRP has one advantage here, though - response codes. OTOH, I'm reasonably sure that that can be negated by kill() and getppid() or, possibly, a pipe, and I can easily adapt runvdr (well, my runvdr.c) to wait for a short time for vdr to respond... -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Another such victory over the Romans, and we are undone. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I demand that VDR User may or may not have written... [snip] Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways. They might point a camera (probably a webcam) at it, though... [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output less CO2 = avoid boiling weather. TIME IS RUNNING OUT *FAST*. You humans are all alike. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Fri, Feb 09, 2007 at 05:55:54PM +, Darren Salt wrote: I demand that VDR User may or may not have written... [snip] Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways. They might point a camera (probably a webcam) at it, though... Such as the original webcam? http://www.theregister.co.uk/2001/03/07/worlds_first_webcam_coffee_pot/ Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Thu, Feb 08, 2007 at 01:08:33PM +0200, Rolf Ahrenberg wrote: BTW, I'm very used to VDR's current behaviour to shutdown itself after the recording is made and don't want to get rid of that one either. As far as I understand, nobody has suggested that we should get rid of that feature. You could compare this to an analog VCR. I would believe that they refuse to power off when there is a timed recording going on. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
VDR User wrote: On 2/7/07, *Klaus Schmidinger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd also say that the Power button should shutdown without confirmation unless there is a recording going on or a plugin is Active(). To avoid accidental shutdowns it might still prompt the user with Shutdown - press any key to stay up or something like that for a few seconds, but it shouldn't be necessary to confirm anything, even if a replay is currently going on. I appreciate your input on the issue, it seems that we're pretty much on the same page. I think your method of dealing with an accidental shutdown best suits the situation. One question though... Say I have the sysinfo or femon plugin screen up, would this mean the plugin is Active() and would prevent a power button shutdown? This should not override a power button shutdown. A plugin is considered active if its Active() function returns a string. So it's entirely up to the plugin whether or not it wants to prevent a shutdown. However, just having a plugin's menu screen open shouldn't mean the plugin is active. Plugin activity is something like burning a DVD or doing some other stuff that shouldn't be interrupted. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
[EMAIL PROTECTED] Also, the user inactivity stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'. Maybe if you got a newer/better TV you would have this feature. My TV turns itself off after some inactivity time. So does my coffee-machine. I have many times accidentily switched of the VDR when someone else has set a timer and thus missed the recording. To me the logical way to do this would be: - if no recording going on and no timers switch off - if recording warn and ask for confirmation - if timer set warn and ask if it should write to nvram and then switch off Ideally how to behave could be chosen with settings. Josce Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On 2/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] Also, the user inactivity stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'. Maybe if you got a newer/better TV you would have this feature. My TV turns itself off after some inactivity time. So does my coffee-machine. I have a new/great TV, and it will not turn itself off if I don't interact with the tv itself while I'm watching an all-day marathon of Lost for example. We're talking about tv here. People tend to put on something they want to watch, and then watch it... Not play with their remote control or fiddle with tv settings. It's completely ridiculous to assume the user is done watching tv simply because he doesn't tell his tv otherwise every x minutes or x hours. If he wants the tv off, he can turn it off himself. There is no reason to behave otherwise unless it's done thru some kind of auto-shutoff? [y/n] setting. With a setting like that I suppose you could specify to shut off at a certain time of the day or user-defined timeout period. But force a shutdown because the user hasn't interacted with vdr? No way! He was probably too busy enjoying his favorite shows to think 'oh, I better check in with my tv before it turns itself off'. Come on now. Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways. I have many times accidentily switched of the VDR when someone else has set a timer and thus missed the recording. To me the logical way to do this would be: - if no recording going on and no timers switch off - if recording warn and ask for confirmation - if timer set warn and ask if it should write to nvram and then switch off Ideally how to behave could be chosen with settings. How about if a timer is set to record within the next x minutes (defined by the user), warn and ask to confirm shutdown? This seems like a reasonable way to deal with the issue to me. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
VDR User wrote: Also, the user inactivity stuff is again, a bad idea. Vdr should not assume anything or take action just because the user hasn't interacted with it in a while. This type of behavior is simply not consistent with other devices and not a behavior the user would expect. My tv will not turn itself off based on my 'inactivity'. You can set the config option Min User Inactivity to 0, and VDR wont ever get 'inactive' by itself. (with one exception, if a recording is going on and you press the power key, VDR will do the shutdown at end of recording. Technically this is user inactivity.) The inactivity shutdown is nice as a fallback, for example if I just forgot to shut down, or if a power failure caused a reboot to make sure the wakeup is re-programmed. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Thu, 8 Feb 2007, VDR User wrote: There is no reason to behave otherwise unless it's done thru some kind of auto-shutoff? [y/n] setting. With a setting like that I suppose you could specify to shut off at a certain time of the day or user-defined timeout period. But force a shutdown because the user hasn't interacted with vdr? I still cannot follow your reasoning as the user can already disable the automatic shutdown feature. Do you want to remove this option completely, rename it or change its' behaviour? The shutdown could be changed to a standby/powersave mode: the stream decoding will be turned off instead of poweroff. VDR's MANUAL: Setting MinUserInactivity to 0 disables the automatic shutdown, while still retaining the possibility to manually shutdown the computer. -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
VDR User wrote: There is no reason to behave otherwise unless it's done thru some kind of auto-shutoff? [y/n] setting. As said above, its called Min User Inactivity and can be set to 0. Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways. H. Can a coffee maker run VDR? :) How about if a timer is set to record within the next x minutes (defined by the user), warn and ask to confirm shutdown? This seems like a reasonable way to deal with the issue to me. Called Min Event Timeout, and will ask Recording in xxx minutes, shut down anyway?. Any other existing options you want to know of? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On 2/8/07, Udo Richter [EMAIL PROTECTED] wrote: H. Can a coffee maker run VDR? :) If it's possible, somebody will find a way! ;) Any other existing options you want to know of? I hadn't pay much attention to this thread until recently and the way some things were worded made it seem like the behaviors being discussed were going to be forced. That coupled with the fact that this thread focuses on a re-write, which leads one to believe there will be changes to the existing methods. If vdr has commonly expected behavior for this kind of device/software, and the user can modify that to be uncommon or to suit his needs via settings options, then no problem. My only concern is that things would be forced that shouldn't be. I'm going to go watch my coffee-maker now. Cheers! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
It's a safe assumption that when a user presses a power button, they intend that the device be immediately turned off or shut down. I can't think of any device that performs any differently. If a user wants to shut down vdr after he's done watching a playback, he would obviously still be sitting there when it ends therefore he can press the power button when its over. I see no reason to make this issue more complex than it should be. The power button has the final say, you don't press it if you don't want to force a shutdown. What logic is there that vdr should be any different? Just my $.02 fellas. Cheers! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, Feb 07, 2007 at 10:40:44PM +0100, Udo Richter wrote: Marko Mäkelä wrote: You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends. Sure, if the playback ends. It won't end with my patched softdevice that stops the playback of recordings when Shutdown.IsUserInactive() returns true. I do understand this right: If your softdevice detects IsUserInactive, then it sends a 'stop playback' to VDR? Weired... It doesn't actually send anything to VDR; it'll just return 0 from cDevice::PlayVideo() and cDevice::PlayAudio(). It will also have to sleep a little, because otherwise VDR would use 100% of CPU. I guess the most natural behavior would be to pretend that you're playing back normally, eg. make softdevice eat the incoming data stream at normal speed without decoding it. Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position. Then, VDR wouldn't shut down unexpectedly while playing back a recording even if the inactivity timeout kicks in. But VDR wouldn't ask for confirmation when pressing the Power key. Thus, no new configuration option would be necessary. More easy, just drop the playback check completely. A running playback means that the !Interact check in vdr.c will prevent any housekeeping and thus automatic shutdown. Before writing my previous message, I added #if 0 #endif around the NowReplaying() check in shutdown.c, and it seems to work. VDR will be powered off during playback if there is no timed recording going on. But again, that way you cannot get VDR into inactive mode manually while playback. Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like Shutdown during playback must be confirmed. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Udo Richter wrote: Marko Mäkelä wrote: Well, that would still break this scenario: You're watching a recording while it is being recorded. Then you get interrupted and push the Power button. Before the timed recording finishes and VDR gets a chance to shut down, you get back and push a button to switch to interactive state. You will be surprised to see that the playback doesn't resume from the same position. Actually I wouldn't. Its the POWER key, not the PAUSE key. If I do that with my old VCR (means, switch off the TV instead of pausing the VCR) the same thing would happen. But again, that way you cannot get VDR into inactive mode manually while playback. Is that feature necessary? If you believe so, maybe you could introduce a configuration option for enabling it? The default behaviour would be to obey the Power button immediately. The option could be named something like Shutdown during playback must be confirmed. Its mainly because the 'old' code did not shut down while playback, at least since 1.3.25. (No longer stopping Transfer Mode or replay immediately when the Power button is pressed (thanks to Rolf Ahrenberg)) Before, I think, the power button stopped playback and did shut down. I don't want to add yet another config option, either we let the power button work directly while playback, or we ask for confirmation on playback. Whatever the majority wants. I'd also say that the Power button should shutdown without confirmation unless there is a recording going on or a plugin is Active(). To avoid accidental shutdowns it might still prompt the user with Shutdown - press any key to stay up or something like that for a few seconds, but it shouldn't be necessary to confirm anything, even if a replay is currently going on. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, Jan 31, 2007 at 10:55:11PM +0100, Udo Richter wrote: Marko Mäkelä wrote: First, and more important: Can you please suspend the playback of recordings when Shutdown.IsUserInactive() holds? This would break the other interesting feature, shut down VDR as soon as the playback ends. The above can be addressed in plugins that are derived from cDevice. However, you're right about breaking that feature: if PlayVideo() and PlayAudio() start refusing data when Shutdown.IsUserInactive() holds, the playback will never end, and VDR would probably wait MinUserInactivity (3 hours by default) until shutdown. So, I have a feature request that would greatly improve the WAF around here. Could you please introduce a configuration option that would allow the Power key to initiate shutdown even while playing a recording (provided that nothing else prevents a shutdown, of course)? After all, it does initiate shutdown when viewing live program without waiting until the end of the current program. The problem in our family is that my wife often watches recorded children's programs with my kids, and they may try to shut down VDR while the credits texts are running. It'd be an extra step to press the Stop button before Power. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: However, you're right about breaking that feature: if PlayVideo() and PlayAudio() start refusing data when Shutdown.IsUserInactive() holds, the playback will never end, and VDR would probably wait MinUserInactivity (3 hours by default) until shutdown. While playback, the current patch waits beyond these 3 hours. (Without, too) Could you please introduce a configuration option that would allow the Power key to initiate shutdown even while playing a recording (provided that nothing else prevents a shutdown, of course)? You can shut down while playback, you just have to confirm it. And if you don't confirm it, VDR will shut down 5 minutes after the playback ends. (the current behavior is to ignore the power key while playback, and then shut down unexpectedly at end of playback) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Peter Dittmann wrote: How about a new two level inactivity timeout ? After VDR starts the inactivity timeout uses a first short timeout (e.g. 5min) assuming that VDR has automaticly being started. Actually, even in worst case you'll see the 5-minute-countdown, so you already have enough time to become interactive. Last but not least I would personally wish for an new anti-timeout-plugin that would block VDR from shutting down on request. You could just set the Min User Inactivity to 0, and VDR will not shut down automatically. (unless you hit the power key - this will even work delayed, eg. after a recording ends.) However the last one now look like it's just a very simple plugin. It is. Just type ./newplugin Noshutdown, then edit Noshutdown.c so that cPluginNoshutdown::Active() always returns a string. Done. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: Actually I would press the pause button, as I usually don't want to miss anything. And then the playback should be halted anyway, no matter if display is on or off. But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity? Actually, I have a plain old CRT that doesn't seriously suffer from burning in. (provide that I resume playback within a month or so. ;) ) And if I want to save power, I power off the CRT completely, and thats something my VDR cannot do on its own (yet). Just blanking the screen has no advantage for me. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Sat, Feb 03, 2007 at 10:48:42AM +0100, Udo Richter wrote: Marko Mäkelä wrote: Actually I would press the pause button, as I usually don't want to miss anything. And then the playback should be halted anyway, no matter if display is on or off. But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity? Actually, I have a plain old CRT that doesn't seriously suffer from burning in. (provide that I resume playback within a month or so. ;) ) And if I want to save power, I power off the CRT completely, and thats something my VDR cannot do on its own (yet). Just blanking the screen has no advantage for me. I'll shortly make my updated vdr-relay plugin available, adapted for your shutdown rewrite patch. Then you can install a simple solid-state relay to a spare RS-232 port. I ended up installing mine inside the soon 20-year-old 14 CRT, to reduce clutter. I control everything from the bundled Hauppauge remote control unit. http://www.iki.fi/~msmakela/electronics/relay/ For the cable, I used an old mouse cord that I soldered to a mono plug. I attached a mono jack to the monitor's back together with a manual override switch. The solid-state relay is connected in series with the power switch of the monitor. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Hi, But you surely would power the display off, to avoid burning the still image on the CRT or plasma screen or to save the precious hours on the lamp of your video beamer? Or maybe you have a TFT screen and do not care about wasting electricity? Surely this shouldn't be too difficult to implement via a Plugin. One could either simply blank out the screen after a configurable time once the Pause button is pressed (and no other key). Another idea would be to show a small OSD containing a configurable picture of one's on choice that is randomly placed and shown on the main (large) OSD while blanking out the background. Maybe as an extension of the Picture in Picture plugin or the Showpicture plugin. regards, Reinhard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Thu, Feb 01, 2007 at 08:27:14PM +0200, Marko Mäkelä wrote: Maybe not switching off display while doing playback? It doesn't make much sense anyway to run playback invisible. It does. The typical use case is that you pause live video or start a recording with a timer, then start watching it while it is still recording, so that you can skip commercial breaks. Then you get interrupted while watching it. It would be very handy to push the power button. If it was a short interruption, you'd push any button to resume playback. If the interruption was longer (such as your kid wakes up and you'll have to put him back to sleep for a few hours), vdr would do the right thing and shut down after finishing the recording. According to Reinhard Nissl's reply in another thread, this can be fixed in the cDevice plugin by not blocking input in cDevice::PlayVideo() or cDevice::PlayAudio() when cDevice::Transferring() holds. I'll update my shutdown patch for softdevice soon. No need to change anything in your patch. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
In [EMAIL PROTECTED], you wrote: I wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware. Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware. Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that. Not to get too off-topic, but I disagree. In north america, from surveying posts on several bulletin boards, vdr usage seems to be 90%+ with FF cards (typically the Nexus-S). There's actually the perception with many in NA that vdr doesn't work with budget cards! And while more PCs are adding the built-in functions a FF card provides (Digital audio out, Coax or S-video out, adequate processing power for decoding) everything seems to be moving to mpeg-4. I know from working regularly with Xvid / mpeg4 files that they require a lot more processing power, and many pcs are older machines dedicated to running vdr, not top of the line full fledged 4 ghz systems. I've never regretted owning my FF card, and would look for a FF mpeg4 card if I was in the market. Plus, they always seem the simplest to configure and use with most software, not to mention not requiring a computer monitor to run vdr on FF :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
In [EMAIL PROTECTED], Patrick Mackin wrote: Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that. Not to get too off-topic, but I disagree. In north america, from surveying posts on several bulletin boards, vdr usage seems to be 90%+ with FF cards (typically the Nexus-S). Is that HD-capable? HDTV seems quite common in NA, but currently in the UK there are very few HD channels, only available through overpriced subscriptions. It looks unlikely that there'll be any FTA/FTV HD until at least after the analogue terrestrial switch-off in 2012. There's actually the perception with many in NA that vdr doesn't work with budget cards! And while more PCs are adding the built-in functions a FF card provides (Digital audio out, Coax or S-video out, adequate processing power for decoding) everything seems to be moving to mpeg-4. If the Nexus-S requires replacement for HD/MPEG4 I wouldn't be surprised if its successor doesn't feature a decoder. The latest graphics cards support MPEG4 too, including H.264. Someone posted about a new DVB card which does have an MPEG4 decoder recently, but pointed out that it's only a reference design, not a production model. And it's PCI-E, so it doesn't look like the manufacturers are very keen to support old PCs. I know from working regularly with Xvid / mpeg4 files that they require a lot more processing power, and many pcs are older machines dedicated to running vdr, not top of the line full fledged 4 ghz systems. I haven't noticed a big difference, although I've only encountered MPEG4 part 2 (DivX etc), usually at lower resolutions than DVB/DVD, as opposed to HD H.264. I've never regretted owning my FF card, and would look for a FF mpeg4 card if I was in the market. Plus, they always seem the simplest to configure and use with most software, not to mention not requiring a computer monitor to run vdr on FF :) Well that was one of my points too. Connecting a typical HDTV to a PC is pretty much the same as connecting a monitor, not like all the headaches involved in getting a decent PAL or NTSC signal from a standard graphics card. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, Jan 31, 2007 at 09:02:58AM +0200, Rolf Ahrenberg wrote: I would rather write käynnistyy instead of the foreign aktivoituu. But VDR starts (käynnistää) all plugins already at the beginning and depending on the plugins behaviour it's activated on main menu action, external trigger, ... So, using the käynnistää as activate confuses me a bit and I'd avoid using it here, but I can live with it. I didn't think of that. If the verb is already used in some translation string, it might be good to avoid using the verb in another context. What about Laajennos herää (Plugin wakes up)? Does VDR really shut _itself_ off (VDR sammuu)? I've always think that it just listens signals from OS that can be generated via the external shutdown script. When VDR invokes the external shutdown script, I would say that it indeed does shut itself off, or at least attempts to. But it might be a little funny to write VDR attempts to shut down in %ld minutes or VDR yrittää sammua %ld minuutin päästä. That would make sense if the vdr-shutdown script could deny the operation because some other application on the VDR box is being used. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, 31 Jan 2007, Marko Mäkelä wrote: I didn't think of that. If the verb is already used in some translation string, it might be good to avoid using the verb in another context. What about Laajennos herää (Plugin wakes up)? That sounds ok. When VDR invokes the external shutdown script, I would say that it indeed does shut itself off, or at least attempts to. But it might be a little funny to write VDR attempts to shut down in %ld minutes or VDR yrittää sammua %ld minuutin päästä. That would make sense if the vdr-shutdown script could deny the operation because some other application on the VDR box is being used. Well, I wouldn't try to translate that one too literally (no need to tell about trying) - it's enough to inform user that VDR will shut down in a few minutes. If it fails due to any plugin activity that could be informed later on. These (sometimes rather annoying!) OSD messages should be as short and simple as possible. BR -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x - Finnish translations
I believe that we have reached consensus on the Finnish translation. On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote: - i18n strings: VDR will shut down later. Press power to force. VDR sammuu myöhemmin - pakota virtakytkimellä VDR will shut down in %s minutes VDR sammuu %s minuutin kuluttua (consider replacing the %s with %ld) Replaying - shut down anyway? Toisto kesken - sammutetaanko? Cutting - shut down anyway? Leikkaus kesken - sammutetaanko? Plugin activity in %ld minutes, shut down anyway? Laajennos herää %ld minuutin kuluttua - sammutetaanko? better: Plugin %s wakes up in %ld minutes, shut down anyway? Laajennos %s herää %ld minuutin kuluttua - sammutetaanko? Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: First, and more important: Can you please suspend the playback of recordings when Shutdown.IsUserInactive() holds? Here is the relevant hunk from my vdr-suspend patch: This would break the other interesting feature, shut down VDR as soon as the playback ends. Also, this would require a long and visible warning that VDR will soon stop playback because of inactivity, so the user wont be confused by the sudden stop of the playback. Alternatively, could you suggest how to fix this in softdevice? Maybe not switching off display while doing playback? It doesn't make much sense anyway to run playback invisible. Second request: Consider modifying cDevice::Action() so that non-recording tuners will not be read during user inactivity. The kernel would then be able to turn off unnecessary tuners. We had this discussion before, and since the majority of VDRs continues to display live video, I don't think that this should be part of VDR itself, and I don't really want to extend this patch into the deeper parts of cDevice. To de-tune live devices, a plugin could display a still, like streamdev-server does, to free up devices. Actually, it'd be nice to turn off any unneeded tuners, also during interactive use (multi-tuner setups, or watching recordings). Unneeded tuners get de-tuned. Provide there are unneeded tuners. (I know that my primary FF card tuner gets de-tuned if I play back a recording.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Tuesday 30 January 2007 19:28, Marko Mäkelä wrote: On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote: Plugin activity in %ld minutes, shut down anyway? Liitännäinen toimii %ld minuutin päästä, sammutetaanko? IIRC plugin has been translated to laajennos elsewhere in VDR - no matter if it's laajennos or liitännäinen, consistency would be good. And toimii sounds a bit weird to me in this context, but I don't have better suggestions right now. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Tue, 30 Jan 2007, Marko Mäkelä wrote: Here are my suggested Finnish translations, and some comments and questions. I'd use passive sentencies and no comma at the ends and try to use the current style. VDR will shut down later. Press power to force. VDR sammuu myöhemmin. Pakota painamalla virtanappia. VDR sammutetaan myöhemmin - pakota virtakytkimellä VDR will shut down in %s minutes VDR sammuu %s minuutin kuluttua. VDR sammutetaan %ld minuutin kuluttua Replaying - shut down anyway? Sammutetaanko kesken toiston? Toisto kesken - sammutetaanko? This should be similar to current: Recording - restart anyway? Cutting - shut down anyway? Sammutetaanko kesken leikkauksen? Leikkaus kesken - sammutetaanko? Plugin activity in %ld minutes, shut down anyway? Liitännäinen toimii %ld minuutin päästä, sammutetaanko? Better: Plugin %s activity (liitännäinen %s) where %s is the name of the first plugin to run. Laajennos aktivoituu %ld kuluttua - sammutetaanko? BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Tuesday 30 January 2007 21:56, Rolf Ahrenberg wrote: Laajennos aktivoituu %ld kuluttua - sammutetaanko? Should be ...%ld minuutin kuluttua... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Tue, Jan 30, 2007 at 09:56:36PM +0200, Rolf Ahrenberg wrote: I'd use passive sentencies and no comma at the ends and try to use the current style. I agree with you that it is good to maintain a consistent style. However, The passive voice should be avoided. I quickly browsed some tooltips in GNOME, and I didn't see the passive form anywhere. Plugin activity in %ld minutes, shut down anyway? Liitännäinen toimii %ld minuutin päästä, sammutetaanko? Better: Plugin %s activity (liitännäinen %s) where %s is the name of the first plugin to run. Laajennos aktivoituu %ld kuluttua - sammutetaanko? I would rather write käynnistyy instead of the foreign aktivoituu. But this is not in passive form, is it? To be consistent with your suggestion VDR sammutetaan (VDR will be shut down), it should be Laajennos aktivoidaan or Laajennos käynnistetään (Plugin will be activated). That sounds unnecessarily complicated to me, as does VDR sammutetaan. The passive form is used when the subject is not known. We know that it is VDR that shuts down itself or activates a plugin. The active form is also shorter than the passive form. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote: Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However, running the script with a closed file handle may cause other side effects. I can't think of any side effect. The shutdown script is not supposed to be interactive, and system tools generally do not read stdin. There are two reasons why my runvdr script closes stdin and redirects stdout and stderr to a file. First, scrolling console output on the bitmap framebuffer could interfere with softdevice-dfb or slow down the playback. Second, I may occasionally launch the runvdr script via an ssh session, and the ssh session would refuse to close if stdin, stdout, or stderr are being used after exiting the shell. I guess I could work around this bug by leaving file descriptor 0 open before starting vdr, e.g., by replacing the - with /dev/null in my runvdr script. But I would very much appreciate it if you could add close(STDIN_FILENO) after the fork() call. Are you planning to maintain the 1.4 branch of the patch? If yes (and I hope so), can plugins use some #ifdef to see if Shutdown.IsUserInactive() is available? Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: On Tue, Jan 23, 2007 at 10:19:57PM +0100, Udo Richter wrote: Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However, running the script with a closed file handle may cause other side effects. I can't think of any side effect. The shutdown script is not supposed to be interactive, and system tools generally do not read stdin. Well, strange things happen. I've had such a side effect on my runvdr extreme with a closed stdout, see here: (German) http://www.vdr-portal.de/board/thread.php?postid=542948#post542948 In this case, printf on kanotix complained heavily on a closed stdout, and the only workaround was to replace - with the traditional /dev/null. Are you planning to maintain the 1.4 branch of the patch? If yes (and I hope so), can plugins use some #ifdef to see if Shutdown.IsUserInactive() is available? For now I'll maintain it, currently the differences are only minor. Adding some #ifdef detection is a good idea, I'll add that for the next 1.4 patch. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: The problem seems to lie in shutdown.c, in SystemExecSession(). It won't close file descriptor 0, but it will close anything above STDERR_FILENO (which is normally 2). This function appears to show up in strace output as clone(). Adding close(0) to the function fixes the problem. Do you see any reason why the shutdown script would need to access stdin? (I can see reasons why it would want to access stdout or stderr.) Actually, the SystemExecSession() is just a modified version of SystemExec() in thread.c, that was used before to call the shutdown script. They only differ in the fact that VDR continues instead of waiting for the child process, and that the child process is detached into its own session. There's no serious difference regarding the file handles. Since the shutdown script runs in the background, the stdin could probably be closed. After all, VDR should continue to 'own' stdin, and running in the background would probably cause a conflict. However, running the script with a closed file handle may cause other side effects. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Sat, Jan 13, 2007 at 09:48:47PM +0100, Udo Richter wrote:
A more important suggestion: Could you please add a notification method
to status.h for notifying plugins whether VDR is currently in
interactive mode?
You can poll this state on your own by calling
Shutdown.IsUserInactive().
Thanks, this seems to work: the display is powered off after the
press any button to cancel shutdown timeout. However, after a
failed shutdown attempt (renaming the shutdown script so that
it won't be found), vdr does something to the file descriptor that
my plugin opens, and the relay control will fail.
This might have something to do with the fact that it is file descriptor 0.
There is no stdin, because my runvdr script closes it:
exec - /tmp/vdr.log 21
The problem seems to lie in shutdown.c, in SystemExecSession().
It won't close file descriptor 0, but it will close anything above
STDERR_FILENO (which is normally 2). This function appears to show
up in strace output as clone(). Adding close(0) to the function
fixes the problem. Do you see any reason why the shutdown script
would need to access stdin? (I can see reasons why it would want to
access stdout or stderr.)
I made a simple patch to softdevice (attached) that seems to work.
A similar patch would be needed for the subtitles plugin, to prevent
subtitles from appearing on the suspended video screen.
Marko
Index: softdevice.c
===
RCS file: /cvsroot/softdevice/softdevice/softdevice.c,v
retrieving revision 1.76
diff -p -u -r1.76 softdevice.c
--- softdevice.c 3 Dec 2006 20:38:18 - 1.76
+++ softdevice.c 22 Jan 2007 21:06:00 -
@@ -15,6 +15,7 @@
#include vdr/osd.h
#include vdr/dvbspu.h
+#include vdr/shutdown.h
#include sys/mman.h
#include sys/ioctl.h
@@ -1084,6 +1085,11 @@ bool cPluginSoftDevice::SetupParse(const
{
// Parse your own setup parameters and store their values.
return setupStore.SetupParse(Name, Value);
+}
+
+void cPluginSoftDevice::MainThreadHook(void)
+{
+ setupStore.shouldSuspend = Shutdown.IsUserInactive();
}
VDRPLUGINCREATOR(cPluginSoftDevice); // Don't touch this!
Index: softdevice.h
===
RCS file: /cvsroot/softdevice/softdevice/softdevice.h,v
retrieving revision 1.13
diff -p -u -r1.13 softdevice.h
--- softdevice.h 11 Nov 2006 08:45:17 - 1.13
+++ softdevice.h 22 Jan 2007 21:06:00 -
@@ -58,6 +58,7 @@ public:
virtual cOsdObject *MainMenuAction(void);
virtual cMenuSetupPage *SetupMenu(void);
virtual bool SetupParse(const char *Name, const char *Value);
+ virtual void MainThreadHook(void);
#if VDRVERSNUM = 10330
virtual bool Service(const char *Id, void *Data = NULL);
#endif
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Tue, Jan 16, 2007 at 12:15:32AM +0100, Udo Richter wrote: Marko Mäkelä wrote: While VDR is running, I would guess that the only way it can become interactive is by receiving button events from the remote control unit. Hmm, ok, I was mainly thinking of becoming inactive - since this is after a certain time has passed, it can only be polled. For lots of cases the current patch wont poll this state at all for a long time. Right, becoming inactive is not that time-critical. I will give your suggestion a try: in the MainThreadHook of each plugin, poll Shutdown.IsUserInactive(). Actually, the key press lets the VDR main loop spin, and directly after the key press was handled, there's a call to MainThreadHook, so its not that long. Okay, this sounds reasonable. It is also good that every plugin will notice the change of Shutdown.IsUserInactive() virtually at the same time. One more thing: are the timeouts for interactive-inactive-shutdown configureable? Is there a way to force VDR to enter inactive mode without immediate shutdown? Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: Right, becoming inactive is not that time-critical. I will give your suggestion a try: in the MainThreadHook of each plugin, poll Shutdown.IsUserInactive(). It should work, though the first key press may trigger some longer work, and the MainThreadHook will be called at the end. For softdevice and skins it may be interesting to watch for skin / osd activity while inactive. One more thing: are the timeouts for interactive-inactive-shutdown configureable? Is there a way to force VDR to enter inactive mode without immediate shutdown? Inactive mode is triggered by the Min User Inactivity timeout config option, by default 3 hours. 3 hours after the last key press VDR changes to inactive. At most 5 minutes before this timeout, but only if there's no background activity, the countdown timer starts. If the countdown runs to 0 and there is no further activity, VDR will initiate the shutdown. After that the 6 minutes retry counter starts, to retry the shutdown. (there's no way how the shutdown script can report failure.) These timeouts are hard-coded as constants in vdr.c. To force inactive mode, one can call Shutdown.SetUserInactive(); - the power key does it for example. This will lead to a shutdown as soon as there's no more activity - if you want to be inactive, but avoid shutdown, you can announce your activity by cPlugin::Active(). Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Wed, Jan 10, 2007 at 02:28:24PM +0100, Udo Richter wrote:
Hi list,
I've finished a second version of the shutdown rewrite. This time, there
are two patches available, one for VDR 1.5.0, and one with slight
changes for 1.4.x.
http://www.udo-richter.de/vdr/patches.html#shutdown
http://www.udo-richter.de/vdr/patches.en.html#shutdown
I had a short look at this patch:
http://www.udo-richter.de/vdr/files/vdr-1.4.5-shutdown-rewrite-0.2.diff
A minor cosmetic thing: the '#' of pre-processor directives should always
be located at the first column of the line. You can add spaces after
the '#' if you want to indent the directives. This is probably not a
problem, if VDR is only compiled with GCC. At least the compiler on
SGI IRIX (r.i.p.) would choke on such code.
A more important suggestion: Could you please add a notification method
to status.h for notifying plugins whether VDR is currently in
interactive mode? This would be useful for at least these three
plugins: softdevice, subtitles, and relay (my own plugin for controlling
a solid-state relay that powers the display on or off). Here are the
relevant chunks from my suspend patch
http://www.iki.fi/~msmakela/software/vdr/#suspend, which is to my
knowledge included in some VDR distributions:
diff -pu vdr-1.4.0/status.h vdr-1.4.0-suspend/status.h
--- vdr-1.4.0/status.h 2005-12-31 17:15:25.0 +0200
+++ vdr-1.4.0-suspend/status.h 2006-05-01 21:42:34.0 +0300
@@ -44,6 +44,9 @@ protected:
virtual void SetAudioChannel(int AudioChannel) {}
// The audio channel has been set to the given value.
// 0=stereo, 1=left, 2=right, -1=no information
// available.
+ virtual void SetSuspend(bool Suspend) {}
+ // Suspend or resume audio/video playback.
+ // true=suspend, false=resume.
virtual void OsdClear(void) {}
// The OSD has been cleared.
virtual void OsdTitle(const char *Title) {}
@@ -77,6 +80,7 @@ public:
static void MsgSetVolume(int Volume, bool Absolute);
static void MsgSetAudioTrack(int Index, const char * const *Tracks);
static void MsgSetAudioChannel(int AudioChannel);
+ static void MsgSetSuspend(bool Suspend);
static void MsgOsdClear(void);
static void MsgOsdTitle(const char *Title);
static void MsgOsdStatusMessage(const char *Message);
I'd suggest a method SetInteractive(bool Interactive). When VDR is
in non-interactive mode, the display would be powered off and the
software decoding of video would be suspended. For full-featured
cards, the suspendoutput plugin could perhaps be adapted:
http://users.tkk.fi/~phintuka/vdr/vdr-suspendoutput/
If you implemented the method, it would make my vdr-suspend patch
unnecessary. I could then try your patch and adapt the three
plugins I use (relay, softdevice, and subtitles, in that order).
Marko
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Marko Mäkelä wrote: A minor cosmetic thing: the '#' of pre-processor directives should always be located at the first column of the line. The only indented directives are for the debug output I think, and this will probably be removed before the final integration anyway. A more important suggestion: Could you please add a notification method to status.h for notifying plugins whether VDR is currently in interactive mode? You can poll this state on your own by calling Shutdown.IsUserInactive(). There is currently no internal notification anyway, VDR itself does poll it and would need to poll it to call MsgSetSuspend. The function itself is a light-weighted inline function, so its no problem to poll it once a second from cPlugin::MainThreadHook or similar. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Hi list, I've finished a second version of the shutdown rewrite. This time, there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x. http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown - Fixed negative time in shutdown confirm in case a VPS timer is in run-out phase. Will now be shown as 'running' recording. - If power pressed while background activity: VDR will shut down later. Press power to force. - Countdown timer will now start 5 minutes *before* Min User Inactivity is reached, unless there's background activity. In any case the countdown will run for 5 minutes. SHUTDOWNRETRY is now 6 minutes, so the next shutdown countdown will start 1 minute after the last one did run out. - Playback of recordings now counts as background activity and requires confirmation on shutdown. If not confirmed, VDR will shut down at the end of playback. (sleeptimer!) - Plugins can schedule to wake up VDR from shutdown by returning a time_t from cPlugin::NextWakeupEvent(). Any time that is not in the future will be ignored. To keep VDR awake, the plugin should also reply on Active() at the given time. If needed, I can provide a simple example code that wakes VDR every day at a given time for 5 minutes or similar. - The scheduled wakeup time of the last call to the shutdown script is now remembered in setup.conf. If VDR wakes up within 10 minutes of this time, VDR assumes that this was an automatic start. - Introduced separated shutdown retry counter that ensures the SHUTDOWNRETRY wait time. That way VDR will stay in non-interactive mode after an shutdown attempt. - The shutdown script may now be called with a wakeup time but with 0 channel and no file, in case a plugin requested the wakeup. - The shutdown command is now called in the background in a separate session, so it can run separately from VDR and can continue to run after the VDR process got killed. - Dropped cRemote::TouchLastActivity() from 1.5 version of the patch, as it is not needed any more. Todo / Possible changes: - Maybe make backgrounding of shutdown script selectable like this: -s /my/shutdown/script - this could also be adapted for recording commands and command menu commands - What to do with SVDRP NEXT command? This was once the same as the time passed to the shutdown script, but it sill can be less than min event pause, even negative, and does not honor plugin scheduled restarts. - Move SystemExecSession into tools.c and/or merge it with the existing SystemExec. - Adapt newplugin and PLUGINS.html - Add i18n entries Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Klaus Schmidinger wrote: However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be up, along with a time period for which it shall stay up. That way external tools could be scheduled using cron, and they could rely on VDR being up at that time. The downside of this would be that again several external tasks would fight for one resource: the time set in VDR. And it wouldn't be much different from the current possible solution to compare the VDR wakeup time with other wakeup times in the shutdown script. For the 0.2 patch, I've added the interface for plugins to modify the wakeup time. That way it shouldn't be too difficult to implement a task scheduler plugin that can be extended to everyone's need, and to implement basic scheduling in existing plugins. (epgsearch for example could implement a wakeup-at-night feature quite easily.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Udo Richter wrote: Klaus Schmidinger wrote: However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be up, along with a time period for which it shall stay up. That way external tools could be scheduled using cron, and they could rely on VDR being up at that time. The downside of this would be that again several external tasks would fight for one resource: the time set in VDR. I don't see why several external tasks would fight for that time. This is something the user would set up the way he wants it. If he wants one or more external tools to have access to VDR at, say, 04:00 in the morning, then he could configure VDR so that it is up at that time. Of course he would also have to make sure that the external tools would use that time slot accordingly. What would be a scenario where external tools would fight for this time? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Klaus Schmidinger wrote: Udo Richter wrote: The downside of this would be that again several external tasks would fight for one resource: the time set in VDR. I don't see why several external tasks would fight for that time. This is something the user would set up the way he wants it. If he wants one or more external tools to have access to VDR at, say, 04:00 in the morning, then he could configure VDR so that it is up at that time. I'm not sure whether all external tools will agree on one time, or whether several tools all want to set 'their' time. Anyway, with the plugin interface, this could be done as a very simple sample plugin. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
[EMAIL PROTECTED] wrote: The alternative would be to implement a generic task scheduler and make timers one special type of schedule. This would get REALLY big. Yes, but it will be the much better design. It will open the option to do VDR related timed and maintainance tasks. There must be some limit. IMHO VDR is a video recorder, not a task scheduler. And I think that Klaus probably agrees with that. Don't reply this should be external scripts, as there is no way external scripts know what state VDR currently has without a lot more complexity. What additional internal state info do you need? Providing interfaces to cooperate with external schedulers should be no problem. These are EPG scans (internal, infosatepg, nextview), sleeptimers, switchonly timers, cleanup tasks of plugins and so on. Think about external EPGs, especilly the ones that need VDR to tune to a channel, like infosatepg or nextview. This is painfull hack doing his outside VDR as these tasks mutually collide with VDRs internal activities and need to be integrated Do you suggest to put all these EPG collectors as integral schedule events into core VDR??? At most, such things may be done as plugin. And for plugins, the ability to wake up at a non-timer time was already suggested. for realy using a KISS principle. In my eyes, KISS also applies to VDR itself. Meaning, why add a full-featured scheduler to VDR that VDR doesn't need? also cause by Klaus's reluctance to take over patches. Where there are patches there is need to change some VDR behaviour, so this behaviour should be changed. In limits, yes. But Klaus being very conservative on integrating patches and features is one of the reasons why VDR is still a very stable and easy to use program. What sounds like a nice enhancement now may soon turn into a dead end, a burden kept for compatibility. There are lots of programs that are overloaded with features that no one really knows, with an user interface to get lost in it. The idea to create now a external Shutdown class by a second person seems like a good starter. It should be done for other functionalities too. This is not the first bigger chunk of work contributed by others, and definitely not the first smaller feature that was contributed. Its also a matter of engagement: If you start off with I'll do it as independent patch, Klaus wont add it anyway, then you'll get what you want. The reason I am working on this is that AFAIK Klaus doesn't use the shutdown mechanisms, and the code really needed an overhaul by someone who's interested in it. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Udo Richter wrote: [EMAIL PROTECTED] wrote: The alternative would be to implement a generic task scheduler and make timers one special type of schedule. This would get REALLY big. Yes, but it will be the much better design. It will open the option to do VDR related timed and maintainance tasks. There must be some limit. IMHO VDR is a video recorder, not a task scheduler. And I think that Klaus probably agrees with that. I do. However, (don't know exactly if this has already been suggested as such) maybe a simple feature in the new shutdown code could be to allow the user to specify *one* time at which VDR shall be guaranteed to be up, along with a time period for which it shall stay up. That way external tools could be scheduled using cron, and they could rely on VDR being up at that time. But that's about as far as I'd go. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Matthias Schwarzott wrote: I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin). That would be the way I would do it. Reconstructing the reason for shutdown after the restart is ok for just timers, but with different reasons this is way too complex and error-prone. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Matthias Schwarzott wrote: In gentoo vdr package we added a small hack (attached), which implements a svdrp call down to tell vdr it is inactive and will shutdown in X minutes. We call this from shutdown-scripts to let vdr retry shutdown in 5 min (or other value if needed). Question is: Is this still needed? VDR already retries after an acceptable time, and VDR probably knows better whether an user is currently active or not. The only reason I could think of is that VDR was started without a timer nearby, and the start script knows that this is not an user start. And sending a kPower key press will also let VDR go inactive. Things were different in old versions, where VDR retried shutdown after 3 hours or so, but that has changed. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Christian Wieninger wrote: perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that? This would be a dirty ugly hack. There must be some pseudo-recording running so VDR does not restart the recording over and over again. And then we'll end up with a recording hack that looks like a timer but does not block devices and does not write to disk and has no recording folder and and and... The alternative would be to implement a generic task scheduler and make timers one special type of schedule. This would get REALLY big. Yes, but it will be the much better design. It will open the option to do VDR related timed and maintainance tasks. Don't reply this should be external scripts, as there is no way external scripts know what state VDR currently has without a lot more complexity. These are EPG scans (internal, infosatepg, nextview), sleeptimers, switchonly timers, cleanup tasks of plugins and so on. Think about external EPGs, especilly the ones that need VDR to tune to a channel, like infosatepg or nextview. This is painfull hack doing his outside VDR as these tasks mutually collide with VDRs internal activities and need to be integrated for realy using a KISS principle. The only benefit of scripting is that more people tend to write and change scripts that writing plugin or extend VDR code. The second is also cause by Klaus's reluctance to take over patches. Where there are patches there is need to change some VDR behaviour, so this behaviour should be changed. Of couse Klaus should be one deciding the way to implement it but he should be more open here to stimulate more people to contribute to VDR. It's like Linux and Linus, the first is a scaling system the second not. Same for VDR and Klaus ;-) The idea to create now a external Shutdown class by a second person seems like a good starter. It should be done for other functionalities too. kind regards Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I'm kind of surprised people even bother to shutdown vdr at all. Didn't really how big of an issue this was until reading this thread. That's all I have to offer the discussion at this point. My apologies. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
2006/12/30, Udo Richter [EMAIL PROTECTED]: However, it might be worth thinking about giving plugins the ability to set a different wakeup time, so that a scheduled EPG scan plugin can be written. I also think that this would be very helpful for some plugins. Manual start detection could also include a call to the plugins. A plugin that did schedule an EPG-scan or similar could tell VDR during start up, that VDR woke up because of this scheduled event set by this plugin. At the moment I use a relatively complex patch that does some maintainance task during the night. If it would be possible to modify the wakeup-time in a plugin I could re-implement the complete patch as a plugin. Regards, Joachim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
2006/12/31, Matthias Schwarzott [EMAIL PROTECTED]: I think a much easier solution (implementable in runvdr/vdr-initscript) is: Write down wakeup-time when shutting down and comparing that to time when system/vdr starts (with some margin). Thats right, this is even more robust. But I think this should be implemented in the vdr core not in scripts. Regards, Joachim. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Hi, Udo Richter wrote: Actually, whether this is internally or externally, the complexity stays the same. It would probably work mostly the same way: Tweak the wakeup time, detect this on wakeup, start the EPG scan, go offline. perhaps this is too trivial, but why not create a daily or whatever timer as you suggested before with a special name like '@epgscan' and react on that? VDR would not create a recording for this timer but start an EPG scan and shut down, if no other timer is active. I think this is quite simple to implement. One could even extend this to a more generic approach: '@command1' as timer file could execute a command in line 1 of commands.conf, that is e.g. an external EPG update script. BR, Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Hi, Udo Richter wrote: I now want to publish a first draft version for testing and further comments. Not all issues are fixed yet, but it already gives an impression of the new code. Further feature request: At least on single card systems it would be nice to have VDR wakeup e. g. at 03:01 to do just an EPG scan and shutdown afterwards. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
Hi Udo, thanks for your great work. Possible changes: - Make the 'inactive' mode (waiting for background activity to end, then shut down) more visible to the user: - Suggestion was to put up a message 'VDR will shut down when idle. Press power button again to force shutdown' before starting the confirms. - Alternative may be a message 'VDR will shut down later when idle' if shutdown was not confirmed - Alternative may be to permanently put up a message 'VDR is waiting for background tasks to complete'. How about taking epgsearch's behavior and put up a message 'VDR is waiting for background tasks to complete. Press ok for details'. Pressing ok would bring up an osd list containing all plugins, which didn't return null in their Active()-method, with their todo-Text. So a user could then see, what's going on. Sure, those key-presses should not be taken into account as regular key-presses in order to not cancel the shutdown. - A 'bug' in the old code allows to automatically shut down VDR at the end of a playback, though this was probably never intended. It could however be re-added as 'feature'. Really? I never knew that. But I consider it as a nice feature a la I just want to watch that movie and sleep afterwards. As most of us know, sometimes tiredness is stronger and end of the movie was never seen while vdr stays on until UserMinActivity strikes. Hope it will be implemented and this time on purpose. ;oD Marius a.k.a. DMH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
