VDR developer version 1.3.45 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.45.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.44-45.diff
Besides some other fixes and enhancements, I'm currently mainly trying to increase the reliability of VPS timers. This version brings some improvements in that area, but there will probably have to be some more changes in case a broadcast is shifted to a time after its advertised end time without the EPG data being updated accordingly, and the device receiving that channel is switched to an other channel in the meantime.
So please keep an eye on VPS recordings and report any irregularities you might observe. Please make sure you provide a proper log excerpt, with logging set to --log=3 (the default) for maximum information. You also may want to make sure that all of VDR's log messages go into *one* file (on some systems log messages are spread into several files, which makes it hard to use the data in order to track down a bug).
The changes since version 1.3.44
- Fixed updating the "Info" button in the "Timers" menu. - Reduced the number of events to actually check when setting events to timers. - cMenuEditIntItem now checks the given value and forces it to be between the given min and max limits. - The status changes of EPG events are now logged for all channels that have timers. - Removed the log message "deleting plugin: ..." when shutting down VDR (thanks to Christoph Haubrich for reporting that this is irritating when calling "vdr --help"). - Fixed cReadLine::Read() for lines that end with the infamous "\r\n" (thanks to Rolf Ahrenberg). - Fixed cDvbDevice::SetAudioBypass() in case setTransferModeForDolbyDigital is false (thanks to Werner Fink). - Updated 'sources.conf'. - Fixed the shutdown timeout (thanks to Alexander Wenzel). - Only calling RemoveEmptyVideoDirectories() once in case a recording has been deleted (reported by Hardy Flor). - Fixed deleting recordings that have been removed externally when running out of disk space (reported by Jan Lenz). - Fixed handling repeating VPS timers (they stopped recording too early). - Timer log messages now show "VPS" if this is a VPS timer. - Fixed getting the present EPG event in case none is currently 'running' (it then returns the one that just ended). - Fixed calling a plugin's main menu function while a message is being displayed (reported by Helmut Auer). - Updated the Russian OSD texts (thanks to Oleg Roitburd). - Made cMenuRecordings::GetRecording() 'protected' (suggested by Marius Heidenstecker). - Speeded up cRemux::ScanVideoPacket() (thanks to Reinhard Nissl). - Enhanced logging EPG event data. - Fixed format string handling (thanks to Darren Salt). - The new function cDevice::ForceTransferMode() can be used to force the primary device into transfer mode (thanks to Reinhard Nissl). - The 'version' of EPG events is now ignored when reading EPG data from 'epg.data' or via SVDRP/PUTE to avoid problems with double EPG events. - The 'running status' of EPG events is now only set to SI::RunningStatusNotRunning for events before the present event. - Fixed some #include sequences. - Single shot VPS timers are now only considered 'expired' if their associated EPG event has been explicitly set to SI::RunningStatusNotRunning. - The check for timers to be deleted is now done only every 30 seconds.
Have fun!
Klaus
On Sun, 2006-03-26 at 17:10 +0200, Klaus Schmidinger wrote:
- Removed the log message "deleting plugin: ..." when shutting down VDR (thanks to Christoph Haubrich for reporting that this is irritating when calling "vdr --help").
FWIW, when a plugin crashed at exit, this message was useful in finding out exactly what the culprit plugin was.
I demand that Ville Skyttä may or may not have written...
On Sun, 2006-03-26 at 17:10 +0200, Klaus Schmidinger wrote:
- Removed the log message "deleting plugin: ..." when shutting down VDR (thanks to Christoph Haubrich for reporting that this is irritating when calling "vdr --help").
FWIW, when a plugin crashed at exit, this message was useful in finding out exactly what the culprit plugin was.
This could be reintroduced, but handled as debug info...?
Ville Skyttä wrote:
On Sun, 2006-03-26 at 17:10 +0200, Klaus Schmidinger wrote:
- Removed the log message "deleting plugin: ..." when shutting down VDR (thanks to Christoph Haubrich for reporting that this is irritating when calling "vdr --help").
FWIW, when a plugin crashed at exit, this message was useful in finding out exactly what the culprit plugin was.
Well, originally Christoph Haubrich had suggested to give cPluginManager::Shutdown() a boolean parameter that controls whether or not to log the deleting, but I thought that would be overkill - who needs the "deleting plugin..." message, anyway?
I didn't think of plugins that crash upon exit ;-)
Klaus
Klaus Schmidinger wrote:
- Removed the log message "deleting plugin: ..." when shutting down VDR (thanks to Christoph Haubrich for reporting that this is irritating when calling "vdr --help").
While we're at --help and plugins: There is no way how a plugin can detect whether it was loaded regularly or just for displaying --help or --version. In the latter cases, ProcessArgs() will be called with empty parameters and cannot fail because it is missing a parameter. If it does fail, VDR stops loading plugins and shows --help and --version only for plugins loaded before the failed one.
(do we need to call ProcessArgs() at all for --help/--version?)
Cheers,
Udo
Udo Richter wrote:
Klaus Schmidinger wrote:
- Removed the log message "deleting plugin: ..." when shutting down
VDR (thanks to Christoph Haubrich for reporting that this is irritating when calling "vdr --help").
While we're at --help and plugins: There is no way how a plugin can detect whether it was loaded regularly or just for displaying --help or --version. In the latter cases, ProcessArgs() will be called with empty parameters and cannot fail because it is missing a parameter. If it does fail, VDR stops loading plugins and shows --help and --version only for plugins loaded before the failed one.
(do we need to call ProcessArgs() at all for --help/--version?)
What's the point in adding -P parameters to a 'vdr --help' call, anyway?
Klaus
Klaus Schmidinger wrote:
Udo Richter wrote:
While we're at --help and plugins: There is no way how a plugin can detect whether it was loaded regularly or just for displaying --help or --version. In the latter cases, ProcessArgs() will be called with empty parameters and cannot fail because it is missing a parameter. If it does fail, VDR stops loading plugins and shows --help and --version only for plugins loaded before the failed one.
(do we need to call ProcessArgs() at all for --help/--version?)
What's the point in adding -P parameters to a 'vdr --help' call, anyway?
Exactly my point...
Ok, an example. Load plugin foo, with parameter REQUIRED:
vdr -P "foo REQUIRED"
This works. This is supposed to not work:
vdr -P "foo"
error: foo requires an argument
But then this doesn't work either:
vdr --version
vdr (1.3.45) - The Video Disk Recorder error: foo requires an argument
Cheers,
Udo
En/na Klaus Schmidinger ha escrit:
- Updated 'sources.conf'.
I don't think that "A111.1W Anik F2" is a correct sources.conf line, neither does vdr, that refuses to work with that line. I have other problems with this sources.conf, but I have to investigate further.
Bye
Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
- Updated 'sources.conf'.
I don't think that "A111.1W Anik F2" is a correct sources.conf line, neither does vdr, that refuses to work with that line.
Sorry, I guess I should have copied this version into my /video directory first...
I guess
S111.1W Anik F2
should be correct. Unfortunately the person who sent that new file didn't provide his/her real name.
Klaus
On Sunday 26 March 2006 20:07, Luca Olivetti wrote:
En/na Klaus Schmidinger ha escrit:
- Updated 'sources.conf'.
I don't think that "A111.1W Anik F2" is a correct sources.conf line, neither does vdr, that refuses to work with that line. I have other problems with this sources.conf, but I have to investigate further.
Sorry, possible it's my mistake It must be S111.1W Anik F2 ^
Bye Oleg