VDR version 1.4.0 is now available at
ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2
A summary of all the major changes since the last stable version 1.2.6 can be found at
http://www.cadsoft.de/vdr/changelog.htm
When updating from version 1.2.6 please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version.
Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR.
Have fun!
Klaus
On Sonntag 30 April 2006 14:22, Klaus Schmidinger wrote:
VDR version 1.4.0 is now available at
ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2A summary of all the major changes since the last stable version 1.2.6 can be found at
http://www.cadsoft.de/vdr/changelog.htmWhen updating from version 1.2.6 please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version.
Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR.
Have fun!
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
VDR 1.4.0 is running :))
just downloaded, Bigpatch (1.3.49) applied (ignored a reject in vdr.c due to rejected feature sems to be already includes in vdr), compiled (with pugins) installed and started
Many thanks to Klaus!
Geeets Jörg Wendel
Congratulations to Klaus on reaching the next stable phase of an excellent piece of software!
On 4/30/06, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
VDR version 1.4.0 is now available at
ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2A summary of all the major changes since the last stable version 1.2.6 can be found at
http://www.cadsoft.de/vdr/changelog.htmWhen updating from version 1.2.6 please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version.
Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR.
Have fun!
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-- Jaakko Kemppainen jaakko.kemppainen@gmail.com
Hello Klaus,
* Klaus Schmidinger Klaus.Schmidinger@cadsoft.de [30-04-06 14:22]:
VDR version 1.4.0 is now available at
ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2
thx a lot for this fantastic peace of software, I could not life without it anymore.
Best regards, Matthias
Great work & congratulations on reaching the next milestone in the ongoing life of VDR!
On Sun, 30 Apr 2006, Klaus Schmidinger wrote:
VDR version 1.4.0 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2
# make VFAT=1 REMOTE=LIRC NO_KBD=1 [...] g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_LIRC -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DVFAT vdr.c vdr.c:34:28: error: sys/capability.h: No such file or directory vdr.c: In function 'bool SetCapSysTime()': vdr.c:113: error: 'cap_t' was not declared in this scope vdr.c:113: error: expected `;' before 'caps' vdr.c:114: error: 'caps' was not declared in this scope vdr.c:118: error: 'caps' was not declared in this scope vdr.c:118: error: 'cap_set_proc' was not declared in this scope vdr.c:120: error: 'cap_free' was not declared in this scope vdr.c:123: error: 'caps' was not declared in this scope vdr.c:123: error: 'cap_free' was not declared in this scope make: *** [vdr.o] Error 1
# locate capability.h /usr/include/linux/capability.h /usr/src/linux-2.4.32/include/linux/capability.h
Changing the include line to #include <linux/capabilities.h> yields # make VFAT=1 REMOTE=LIRC NO_KBD=1 g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_LIRC -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DVFAT vdr.c vdr.c: In function 'bool SetCapSysTime()': vdr.c:113: error: 'cap_t' was not declared in this scope vdr.c:113: error: expected `;' before 'caps' vdr.c:114: error: 'caps' was not declared in this scope vdr.c:118: error: 'caps' was not declared in this scope vdr.c:118: error: 'cap_set_proc' was not declared in this scope vdr.c:120: error: 'cap_free' was not declared in this scope vdr.c:123: error: 'caps' was not declared in this scope vdr.c:123: error: 'cap_free' was not declared in this scope make: *** [vdr.o] Error 1
# g++ --version g++ (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
1. Any pointers concerning the cap_t problem?
2. A small note on what kernel is required for the hg driver download on http://www.cadsoft.de/vdr/download.htm would be nice.
3. What about the runvdr script? It's fairly clear how it is supposed to work on Linux 2.4 systems, but what about 2.6 systems? There is no ../DVB/driver dir there...
Nevertheless, I'm quite impressed that users who do not closely follow the VDR development are not forgotten (i.e., an UPGRADE-1.2-0 document exists :-). Thanks!
Regards
Hi,
vdrdir/INSTALL You will also need to install the "libjpeg" and "libcap" libraries, as well as their "devel" packages to get the necessary header files for compiling VDR. If the "capability" module is not compiled into your kernel, you may need to do "modprobe capability" before running VDR.
On So, Apr 30, 2006 at 08:01:10 +0200, M.Kiesel wrote:
On Sun, 30 Apr 2006, Klaus Schmidinger wrote:
VDR version 1.4.0 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2
# make VFAT=1 REMOTE=LIRC NO_KBD=1 [...] g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_LIRC -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DVFAT vdr.c vdr.c:34:28: error: sys/capability.h: No such file or directory vdr.c: In function 'bool SetCapSysTime()': vdr.c:113: error: 'cap_t' was not declared in this scope vdr.c:113: error: expected `;' before 'caps' vdr.c:114: error: 'caps' was not declared in this scope vdr.c:118: error: 'caps' was not declared in this scope vdr.c:118: error: 'cap_set_proc' was not declared in this scope vdr.c:120: error: 'cap_free' was not declared in this scope vdr.c:123: error: 'caps' was not declared in this scope vdr.c:123: error: 'cap_free' was not declared in this scope make: *** [vdr.o] Error 1
# locate capability.h /usr/include/linux/capability.h /usr/src/linux-2.4.32/include/linux/capability.h
Changing the include line to #include <linux/capabilities.h> yields # make VFAT=1 REMOTE=LIRC NO_KBD=1 g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_LIRC -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DVFAT vdr.c vdr.c: In function 'bool SetCapSysTime()': vdr.c:113: error: 'cap_t' was not declared in this scope vdr.c:113: error: expected `;' before 'caps' vdr.c:114: error: 'caps' was not declared in this scope vdr.c:118: error: 'caps' was not declared in this scope vdr.c:118: error: 'cap_set_proc' was not declared in this scope vdr.c:120: error: 'cap_free' was not declared in this scope vdr.c:123: error: 'caps' was not declared in this scope vdr.c:123: error: 'cap_free' was not declared in this scope make: *** [vdr.o] Error 1
# g++ --version g++ (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
Any pointers concerning the cap_t problem?
A small note on what kernel is required for the hg driver download on
http://www.cadsoft.de/vdr/download.htm would be nice.
- What about the runvdr script? It's fairly clear how it is supposed to
work on Linux 2.4 systems, but what about 2.6 systems? There is no ../DVB/driver dir there...
Nevertheless, I'm quite impressed that users who do not closely follow the VDR development are not forgotten (i.e., an UPGRADE-1.2-0 document exists :-). Thanks!
Regards
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sun, 30 Apr 2006, M.Kiesel wrote:
VDR version 1.4.0 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.0.tar.bz2
# make VFAT=1 REMOTE=LIRC NO_KBD=1 [...] g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_LIRC -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DVFAT vdr.c vdr.c:34:28: error: sys/capability.h: No such file or directory vdr.c: In function 'bool SetCapSysTime()': vdr.c:113: error: 'cap_t' was not declared in this scope
Uh, sorry. Read the archives, checked INSTALL file again, apt-get install libcap-dev, everything compiles fine :-).
Regards
M.Kiesel wrote:
... 2. A small note on what kernel is required for the hg driver download on http://www.cadsoft.de/vdr/download.htm would be nice.
See http://www.cadsoft.de/vdr/software.htm for information on which kernel I'm using (currently 2.6.13).
- What about the runvdr script? It's fairly clear how it is supposed to
work on Linux 2.4 systems, but what about 2.6 systems? There is no ../DVB/driver dir there...
Ouch, I totally missed that one when converting everything to the new version.
Since the runvdr script is just a suggestion on how to allow VDR to recover from a driver crash, I'll change it like the attached script. There the user can fill in the functions necessary to detect, load and unload the driver.
Klaus
#!/bin/sh
# runvdr: Loads the DVB driver and runs VDR # # If VDR exits abnormally, the driver will be reloaded # and VDR restarted. # # In order to actually use this script you need to implement # the functions DriverLoaded(), LoadDriver() and UnloadDriver() # and maybe adjust the VDRPRG and VDRCMD to your particular # requirements. # # Since this script loads the DVB driver, it must be started # as user 'root'. Add the option "-u username" to run VDR # under the given user name. # # Any command line parameters will be passed on to the # actual 'vdr' program. # # See the main source file 'vdr.c' for copyright information and # how to reach the author. # # $Id: runvdr 1.16 2006/02/04 15:20:48 kls Exp kls $
VDRPRG="./vdr" VDRCMD="$VDRPRG -w 60 $*"
LSMOD="`/sbin/lsmod | grep -w '^dvb' | wc -l`" KILL="/usr/bin/killall -q -TERM"
# Detect whether the DVB driver is already loaded # and return 0 if it *is* loaded, 1 if not: function DriverLoaded() { return 1 }
# Load all DVB driver modules needed for your hardware: function LoadDriver() { }
# Unload all DVB driver modules loaded in LoadDriver(): function UnloadDriver() { }
# Load driver if it hasn't been loaded already: if ! DriverLoaded; then LoadDriver fi
while (true) do $VDRCMD if test $? -eq 0 -o $? -eq 2; then exit; fi echo "`date` reloading DVB driver" $KILL $VDRPRG sleep 10 UnloadDriver LoadDriver echo "`date` restarting VDR" done
Klaus Schmidinger wrote:
Since the runvdr script is just a suggestion on how to allow VDR to recover from a driver crash, I'll change it like the attached script. There the user can fill in the functions necessary to detect, load and unload the driver.
while (true) do $VDRCMD
I suggest using eval "$VDRCMD" here. This avoids nasty problems with plugins that use parameters. Some discussion around that happened at vdr-portal in the 1.3.43 release thread:
http://www.vdr-portal.de/board/thread.php?threadid=46118
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
Since the runvdr script is just a suggestion on how to allow VDR to recover from a driver crash, I'll change it like the attached script. There the user can fill in the functions necessary to detect, load and unload the driver.
while (true) do $VDRCMD
I suggest using eval "$VDRCMD" here. This avoids nasty problems with plugins that use parameters. Some discussion around that happened at vdr-portal in the 1.3.43 release thread:
Done.
Klaus
Since vdr 1.3.47 also the Suse runvdr (i know it from Suse 9.2 up to the last 10.1RC2) didnt work anymore if a plugin has an "-" in the name like streamdev-server and streamdev-client. Maybe someone fixed this prob already ?
Regards Mike
Klaus Schmidinger schrieb:
- What about the runvdr script? It's fairly clear how it is supposed
to work on Linux 2.4 systems, but what about 2.6 systems? There is no ../DVB/driver dir there...
Ouch, I totally missed that one when converting everything to the new version.
Since the runvdr script is just a suggestion on how to allow VDR to recover from a driver crash, I'll change it like the attached script. There the user can fill in the functions necessary to detect, load and unload the driver.
Klaus
#!/bin/sh
# runvdr: Loads the DVB driver and runs VDR # # If VDR exits abnormally, the driver will be reloaded # and VDR restarted. # # In order to actually use this script you need to implement # the functions DriverLoaded(), LoadDriver() and UnloadDriver() # and maybe adjust the VDRPRG and VDRCMD to your particular # requirements. # # Since this script loads the DVB driver, it must be started # as user 'root'. Add the option "-u username" to run VDR # under the given user name. # # Any command line parameters will be passed on to the # actual 'vdr' program. # # See the main source file 'vdr.c' for copyright information and # how to reach the author. # # $Id: runvdr 1.16 2006/02/04 15:20:48 kls Exp kls $
VDRPRG="./vdr" VDRCMD="$VDRPRG -w 60 $*"
LSMOD="`/sbin/lsmod | grep -w '^dvb' | wc -l`" KILL="/usr/bin/killall -q -TERM"
# Detect whether the DVB driver is already loaded # and return 0 if it *is* loaded, 1 if not: function DriverLoaded() { return 1 }
# Load all DVB driver modules needed for your hardware: function LoadDriver() { }
# Unload all DVB driver modules loaded in LoadDriver(): function UnloadDriver() { }
# Load driver if it hasn't been loaded already: if ! DriverLoaded; then LoadDriver fi
while (true) do $VDRCMD if test $? -eq 0 -o $? -eq 2; then exit; fi echo "`date` reloading DVB driver" $KILL $VDRPRG sleep 10 UnloadDriver LoadDriver echo "`date` restarting VDR" done
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Michael Müllner wrote:
Since vdr 1.3.47 also the Suse runvdr (i know it from Suse 9.2 up to the last 10.1RC2) didnt work anymore if a plugin has an "-" in the name like streamdev-server and streamdev-client. Maybe someone fixed this prob already ?
How? You didn't tell anyone that there is a bug.
cu Ludwig
Well, sorry me subscribed yesterday and dont know whats posted before and its also not a Suse Prob (there is no vdr 1.4.0 from suse). Here a short info what happen:
Starting with 1.3.47 me got this message when the runvdr try to load streamdev-server:
Starting Video Disk Recorder [ epgsearch streamdev-server ] configuration error, check log file
if i rename the lib to streamdevserver or move it in the config file from VDR_PLUGINS= to VDR_ADDITIONAL_ARGS= (without renaming) all is ok also starting vdr + streamdev-server from the commandline without runvdr works.
me also add some echo to my runvdr to see a bit more and thats what i see:
Starting Video Disk Recorder [ epgsearch streamdev-server] /usr/sbin/vdr -c "/etc/vdr" -l "3.6" -w "60" -t "/dev/tty8" "-Pepgsearch" "-Pstreamdev-server -server" -v video -g /tmp status=2 vdr exited normally
Looks like some splitting is wrong but me dont have a clue about scripting so me cant find the prob myself.
Regards Mike
Ludwig Nussel schrieb:
Michael Müllner wrote:
Since vdr 1.3.47 also the Suse runvdr (i know it from Suse 9.2 up to the last 10.1RC2) didnt work anymore if a plugin has an "-" in the name like streamdev-server and streamdev-client. Maybe someone fixed this prob already ?
How? You didn't tell anyone that there is a bug.
cu Ludwig
Am 30.04.2006 um 14:22 schrieb Klaus Schmidinger:
Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR.
I noticed that VDR does not warn anymore if you press the power button (on the remote) and there is a timer within the next X minutes. VDR Menu Einstellungen/Sonstiges says now "Brückenzeit zwischen Timern" - mine is set to 40. Instead of showing "Timer startet in den nächsten X Minuten", VDR just shows the usual power-off Dialog where you can press a button to stop the shutdown, no word of pending timer in the next x minutes.
Ciao, Dominique
Dominique Simon wrote:
I noticed that VDR does not warn anymore if you press the power button (on the remote) and there is a timer within the next X minutes.
Confirmed. Referring to http://www.linuxtv.org/pipermail/vdr/2006-April/009123.html
This is a regression from ForceShutdown being always true after pressing power button. This over-rules the question. VDR however honors the minimum gap time for auto-shutdown.
The problem is that we don't know whether a plugin causing activity was over-ruled by user confirm (don't ask again because of recording) or no plugin had activity (do ask).
One way to fix this would be to always ask, and skip the && !ForceShutdown before asking "Recording in %ld minutes, shut down anyway?". This would result in up to three confirms on shutdown: Running recording, plugin activity and soon recording. For better consistency, its probably a good idea to move this question into the kPower handler, where the other two confirms reside.
Cheers,
Udo
Udo Richter wrote:
Dominique Simon wrote:
I noticed that VDR does not warn anymore if you press the power button (on the remote) and there is a timer within the next X minutes.
One way to fix this would be to always ask, and skip the && !ForceShutdown before asking "Recording in %ld minutes, shut down anyway?". This would result in up to three confirms on shutdown: Running recording, plugin activity and soon recording. For better consistency, its probably a good idea to move this question into the kPower handler, where the other two confirms reside.
The attached patch moves the "Recording in %ld minutes, shut down anyway?" confirmation into the kPower handler, where all the other shutdown confirms reside. I *hope* that this time it doesn't cause yet another regression. ;)
Cheers,
Udo
--- vdr-1.4.0-orig/vdr.c 2006-05-04 00:07:45.000000000 +0200 +++ vdr-1.4.0/vdr.c 2006-05-04 00:22:43.052229240 +0200 @@ -970,7 +970,7 @@ } break; // Power off: - case kPower: + case kPower: { isyslog("Power button pressed"); DELETE_MENU; if (!Shutdown) { @@ -985,8 +985,21 @@ } if (cPluginManager::Active(tr("shut down anyway?"))) break; + + cTimer *timer = Timers.GetNextActiveTimer(); + time_t Next = timer ? timer->StartTime() : 0; + time_t Delta = timer ? Next - time(NULL) : 0; + if (Next && Delta <= Setup.MinEventTimeout * 60) { + char *buf; + asprintf(&buf, tr("Recording in %ld minutes, shut down anyway?"), Delta / 60); + bool confirm=Interface->Confirm(buf); + free(buf); + if (!confirm) break; + } + ForceShutdown = true; break; + } default: break; } Interact = Menu ? Menu : cControl::Control(); // might have been closed in the mean time @@ -1121,15 +1134,6 @@ else LastActivity = 1; } - if (UserShutdown && Next && Delta <= Setup.MinEventTimeout * 60 && !ForceShutdown) { - char *buf; - asprintf(&buf, tr("Recording in %ld minutes, shut down anyway?"), Delta / 60); - if (Interface->Confirm(buf)) - ForceShutdown = true; - else - UserShutdown = false; - free(buf); - } if (!Next || Delta > Setup.MinEventTimeout * 60 || ForceShutdown) { ForceShutdown = false; if (timer)
Am 04.05.2006 um 00:45 schrieb Udo Richter:
The attached patch moves the "Recording in %ld minutes, shut down anyway?" confirmation into the kPower handler, where all the other shutdown confirms reside. I *hope* that this time it doesn't cause yet another regression. ;)
Thanks! I'll attach the patch to my VDR 1.4 and will report back!
Ciao, Dominique
Am 04.05.2006 um 00:45 schrieb Udo Richter:
The attached patch moves the "Recording in %ld minutes, shut down anyway?" confirmation into the kPower handler, where all the other shutdown confirms reside. I *hope* that this time it doesn't cause yet another regression. ;)
It works as expected by now. Shutdown is interrupted if a timer is near or a timer is running, good work!
Ciao, Dominique
Udo Richter schrieb:
Udo Richter wrote:
Dominique Simon wrote:
I noticed that VDR does not warn anymore if you press the power button (on the remote) and there is a timer within the next X minutes.
One way to fix this would be to always ask, and skip the && !ForceShutdown before asking "Recording in %ld minutes, shut down anyway?". This would result in up to three confirms on shutdown: Running recording, plugin activity and soon recording. For better consistency, its probably a good idea to move this question into the kPower handler, where the other two confirms reside.
The attached patch moves the "Recording in %ld minutes, shut down anyway?" confirmation into the kPower handler, where all the other shutdown confirms reside. I *hope* that this time it doesn't cause yet another regression. ;)
Hello,
Without testing it, I would guess, that this leads to another problem: If the shutdown is caused by user inactiviy vdr will shutdown even if a recording will be within the next xxx minutes.
I have posted another fix here: http://www.htpc-forum.de/forum/index.php?act=ST&f=12&t=2387&st=0...
Helmut Auer wrote:
Hello,
Without testing it, I would guess, that this leads to another problem: If the shutdown is caused by user inactiviy vdr will shutdown even if a recording will be within the next xxx minutes.
No, the moved part just covers the "Recording in %ld minutes, shut down anyway?" UI question, and this question only appears on manual shutdown.
The following block in the code covers automatic shutdown:
if (!Next || Delta > Setup.MinEventTimeout * 60 || ForceShutdown)
I have posted another fix here: http://www.htpc-forum.de/forum/index.php?act=ST&f=12&t=2387&st=0...
Since you query cPluginManager::Active() twice (no comment on style...) to differentiate between no activity and confirmed shutdown, you're setting UserShutdown=true and ForceShutdown=false the old way if no questions were asked. So why do you need to modify the "Recording in..." block at all?
Cheers,
Udo
Hi
Without testing it, I would guess, that this leads to another problem: If the shutdown is caused by user inactiviy vdr will shutdown even if a recording will be within the next xxx minutes.
No, the moved part just covers the "Recording in %ld minutes, shut down anyway?" UI question, and this question only appears on manual shutdown.
You're right :-)
The following block in the code covers automatic shutdown:
if (!Next || Delta > Setup.MinEventTimeout * 60 || ForceShutdown)
I have posted another fix here: http://www.htpc-forum.de/forum/index.php?act=ST&f=12&t=2387&st=0...
Since you query cPluginManager::Active() twice (no comment on style...)
If you don't want to comment then be quiet - what you've written is a comment ! But to call it twice is the only way to differentiate between no active plugin active and a user interaction.
So why do you need to modify the "Recording in..." block at all?
There's no need, but the code is clearer in my eyes. Anyway, if you talk about style you should recode the whole shutdown part, because it wouldn't pass any code review ;)
Cio Helmut
Helmut Auer wrote:
Since you query cPluginManager::Active() twice (no comment on style...)
If you don't want to comment then be quiet - what you've written is a comment !
Yeah, sorry for for doing a NULL comment. ;)
But to call it twice is the only way to differentiate between no active plugin active and a user interaction.
Calling it twice is creative, but not very elegant. Active() could be modified, but I didn't want to go that far. In the end, I liked the idea being asked separately for each reason not to shut down, so there's no need to know how forced the shutdown was.
Anyway, if you talk about style you should recode the whole shutdown part, because it wouldn't pass any code review ;)
The shutdown part, and lots of things in the main loop, but unfortunately 1.4.0 is supposed to be a stable version. ;)
Cheers,
Udo
Udo Richter wrote:
Helmut Auer wrote:
Since you query cPluginManager::Active() twice (no comment on style...)
If you don't want to comment then be quiet - what you've written is a comment !
Yeah, sorry for for doing a NULL comment. ;)
But to call it twice is the only way to differentiate between no active plugin active and a user interaction.
Calling it twice is creative, but not very elegant. Active() could be modified, but I didn't want to go that far. In the end, I liked the idea being asked separately for each reason not to shut down, so there's no need to know how forced the shutdown was.
Anyway, if you talk about style you should recode the whole shutdown part, because it wouldn't pass any code review ;)
The shutdown part, and lots of things in the main loop, but unfortunately 1.4.0 is supposed to be a stable version. ;)
Please let's focus on the actual problem ;-)
Klau
Hi,
But to call it twice is the only way to differentiate between no active plugin active and a user interaction.
Calling it twice is creative, but not very elegant. Active() could be modified, but I didn't want to go that far. In the end, I liked the idea being asked separately for each reason not to shut down, so there's no need to know how forced the shutdown was.
That's also correct, but if the variable ForceShutdown exists, then it should be set whenever the user commits a question, and not only on some questions :)
Anyway I think both patches will fix the actual problem so it doesn't matter which one to take ..
-
Dominique Simon -
Halim Sahin -
Helmut Auer -
Jaakko Kemppainen -
Jörg Wendel -
Klaus Schmidinger -
Ludwig Nussel -
M.Kiesel -
Matthias Fechner -
Michael Müllner -
Mlists -
Udo Richter -
VDR User