VDR developer version 1.7.19 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.19.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.18-1.7.19.diff
MD5 checksums:
1eb04ecdc2b11ab8641ebfaa2cb93f42 vdr-1.7.19.tar.bz2 db16ce7bb51e0db837ed56ef4744a67e vdr-1.7.18-1.7.19.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
This version introduces functions to determine the "signal strength" and "signal quality" through cDevice. If you are using a DVB card that contains an stb0899 frontend chip (like the TT-budget S2-3200) you may want to apply the patches from
ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches
to the LinuxDVB driver source in order to receive useful results from that frontend. Since apparently the various frontend drivers return different maximum values in their FE_READ_SIGNAL_STRENGTH and FE_READ_SNR functions (some deliver a value in the range 0x0000...0xFFFF, while others return values as "dB/10" or "dBm/10" (the latter with an offset to make the value positive, since the parameter is unsigned), the functions cDvbTuner::GetSignalStrength() and cDvbTuner::GetSignalQuality() use the device's "subsystem ID" to map these values into the range 0...100, which is the normalized return value of these functions. Take a look at these two functions and maybe remove the comment characters from the lines //#define DEBUG_SIGNALSTRENGTH //#define DEBUG_SIGNALQUALITY in dvbdevice.c to get some debug output if your device doesn't return any directly useful values and may have to be added appropriately to the 'switch (subsystemId)' statement. The channel display of the 'sttng' skin uses these values to implement a signal strength/quality display.
The changes since version 1.7.18:
- Fixed cString's operator=(const char *String) in case the given string is the same as the existing one (thanks to Dirk Leber). - Avoiding a gcc 4.6 compiler error in the skincurses plugin (thanks to Tobias Grimm). - TsGetPayload() now checks if there actually is a payload in the given TS packet (reported by Dirk Leber). - Now sorting the source file names in the call to xgettext, to make sure the results are not dependent on the sequence of the files. Plugin authors may want to change the line containing the xgettext call in their Makefile accordingly by changing "$^" to "`ls $^`". - The primary device is now only avoided for recording if it is an old SD full featured card. This is done through the new function cDevice::AvoidRecording(). - Subtitle PIDs are now also decrypted (thanks to Reinhard Nissl). - Fixed a possible race condition in cDiseqc::Execute() (reported by Marco Göbenich). The return value of cDiseqcs::Get() is now const, so plugin authors may need to adjust their code if they use this function. - The new functions cDevice::SignalStrength() and cDevice::SignalQuality() can be used to determine the signal strength and quality of a given device (thanks to Rolf Ahrenberg for some input on how to use BER and UNC values to generate a "quality" value). - The 'sttng' skin now displays two colored bars at the bottom of the channel display, indicating the strength (upper bar) and quality (lower bar) of the received signal. The number to the left of these bars indicates the actual device the current channel is being received with. - Fixed detecting frames in case the Picture Start Code or Access Unit Delimiter extends over TS packet boundaries (reported by Johan Andersson). In order to fix this, the semantics of cFrameDetector had to be changed a little. See cRecorder::Action() and cIndexFileGenerator::Action() on how to use the new cFrameDetector::NewPayload() function. - The frame detector now only starts collecting PTS values after it has seen the first I-frame, otherwise it might get MaxPtsValues values and stop analyzing even though the incoming data is still garbage (reported by Derek Kelly). - The info file of a recording is now only overwritten with a new fps value if that new value is not the default value (thanks to Derek Kelly for reporting a problem with the fps value being overwritten in case a recording was interrupted and resumed, and the fps value could not be determined after resuming recording). - The initial channel is now stored by the channel ID in the setup.conf file, in order to avoid problems in case channels are reordered or deleted (reported by Lars Bläser). - Added support for "content identifier descriptor" and "default authority descriptor" to 'libsi' (thanks to Dave Pickles).
Have fun!
Klaus
On 19.06.2011 12:41, Klaus Schmidinger wrote:
... The changes since version 1.7.18:
...
- Fixed detecting frames in case the Picture Start Code or Access Unit Delimiter
extends over TS packet boundaries (reported by Johan Andersson). In order to fix this, the semantics of cFrameDetector had to be changed a little. See cRecorder::Action() and cIndexFileGenerator::Action() on how to use the new cFrameDetector::NewPayload() function.
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Klaus
Am 19.06.2011 22:57, schrieb Klaus Schmidinger:
On 19.06.2011 12:41, Klaus Schmidinger wrote:
- Fixed detecting frames in case the Picture Start Code or Access Unit
Delimiter extends over TS packet boundaries (reported by Johan Andersson).
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;)
Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;)
Cheers,
Udo
In article 4DFE76AC.9030700@gmx.de you write:
Am 19.06.2011 22:57, schrieb Klaus Schmidinger:
On 19.06.2011 12:41, Klaus Schmidinger wrote:
- Fixed detecting frames in case the Picture Start Code or Access Unit
Delimiter extends over TS packet boundaries (reported by Johan Andersson).
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;)
Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;)
I just tried this, does it make sense to just revert all of the changes to vdr-1.7.19/recorder.c, vdr-1.7.19/recording.c, and vdr-1.7.19/remux.[ch] ? If this works I might commit the FreeBSD port that way...
Thanx! :) Juergen
On 20.06.2011 18:48, Juergen Lock wrote:
In article4DFE76AC.9030700@gmx.de you write:
Am 19.06.2011 22:57, schrieb Klaus Schmidinger:
On 19.06.2011 12:41, Klaus Schmidinger wrote:
- Fixed detecting frames in case the Picture Start Code or Access Unit
Delimiter extends over TS packet boundaries (reported by Johan Andersson).
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;)
Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;)
I just tried this, does it make sense to just revert all of the changes to vdr-1.7.19/recorder.c, vdr-1.7.19/recording.c, and vdr-1.7.19/remux.[ch] ? If this works I might commit the FreeBSD port that way...
Pretty much so. You'll miss out on a few other fixes, too, but that's no big deal.
Klaus
On Mon, Jun 20, 2011 at 07:32:52PM +0200, Klaus Schmidinger wrote:
On 20.06.2011 18:48, Juergen Lock wrote:
In article4DFE76AC.9030700@gmx.de you write:
Am 19.06.2011 22:57, schrieb Klaus Schmidinger:
On 19.06.2011 12:41, Klaus Schmidinger wrote:
- Fixed detecting frames in case the Picture Start Code or Access Unit
Delimiter extends over TS packet boundaries (reported by Johan Andersson).
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;)
Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;)
I just tried this, does it make sense to just revert all of the changes to vdr-1.7.19/recorder.c, vdr-1.7.19/recording.c, and vdr-1.7.19/remux.[ch] ? If this works I might commit the FreeBSD port that way...
Pretty much so. You'll miss out on a few other fixes, too, but that's no big deal.
Very good, thank you! :)
Juergen
On 20.06.2011 00:22, Udo Richter wrote:
Am 19.06.2011 22:57, schrieb Klaus Schmidinger:
On 19.06.2011 12:41, Klaus Schmidinger wrote:
- Fixed detecting frames in case the Picture Start Code or Access Unit
Delimiter extends over TS packet boundaries (reported by Johan Andersson).
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;)
Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;)
Please try the attached patch with VDR 1.7.19.
cRecorder::Action() now buffers TS packets in case the frame type is not yet known when a new payload starts. This adds no overhead for channels that broadcast the frame type within the first TS packet of a payload; it only kicks in if that information is not in the first TS packet.
For testing you may want to set MaxVideoFileSize (in setup.conf) to a lower value, so that recordings are split into many files.
Since I don't know of any channel I can receive that doesn't encode the picture type in the first TS packet of a new payload, I was only able to test whether the distortion problem is gone for "normal" channels ("unnormal" being those that don't encode the picture type in the first TS packet ;-). Therefore the actual buffering functionality is untested.
If you get a "frame type not in first packet of payload - buffering" or any other of the new log messages, please let me know.
Klaus
Hi!
Which linuxDVB driver did you use. Could not find one where all patches apply cleanly.
Regards
Marco
Am 19.06.2011 12:41, schrieb Klaus Schmidinger:
This version introduces functions to determine the "signal strength" and "signal quality" through cDevice. If you are using a DVB card that contains an stb0899 frontend chip (like the TT-budget S2-3200) you may want to apply the patches from
ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches
to the LinuxDVB driver source in order to receive useful results from that frontend.
Il 30/06/2011 22:32, Marco Göbenich ha scritto:
Hi!
Which linuxDVB driver did you use. Could not find one where all patches apply cleanly.
Regards
Marco
# Download sources git clone git://linuxtv.org/media_build.git
# Download drivers cd ./media_build/linux wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2&& tar -jxf linux-media-LATEST.tar.bz2 cd ..
Ciao, Pizzak :)
Il 30/06/2011 22:32, Marco Göbenich ha scritto:
Hi!
Which linuxDVB driver did you use. Could not find one where all patches apply cleanly.
Regards
Marco
# Installiamo le dipendenze apt-get install patchutils libdigest-sha1-perl libproc-processtable-perl
# Scarichiamo i sorgenti git clone git://linuxtv.org/media_build.git
# Scarichiamo e decomprimiamo l'ultima versione dei drivers cd ./media_build/linux wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2&& tar -jxf linux-media-LATEST.tar.bz2 cd ..
wget ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/01-stb0899_if_agc_gain.diff wget ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/02-stb0899_signal_flag.diff wget ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/03-stb0899_signal_strength_limits.diff
patch -p1< 01-stb0899_if_agc_gain.diff patch -p1< 02-stb0899_signal_flag.diff patch -p1< 03-stb0899_signal_strength_limits.diff
Source: http://wiki.vdr-italia.org/doku.php?id=vdr:installazione_di_vdr_con_debian_w...
Ciao, Pizzak
Hi!
Thanks for your guide, the repository name was the information I searched. But I didn't read Klaus annoncement carefully, he mentioned the TT S2-3200 but I got the TT S2-3600 USB device and it's driver is only in s2-liplianin repo and this is currently not compatible with 2.6.39
Regards
Marco
Am 02.07.2011 13:59, schrieb Gianni Zacchia:
Il 30/06/2011 22:32, Marco Göbenich ha scritto:
Hi!
Which linuxDVB driver did you use. Could not find one where all patches apply cleanly.
Regards
Marco
# Installiamo le dipendenze apt-get install patchutils libdigest-sha1-perl libproc-processtable-perl
# Scarichiamo i sorgenti git clone git://linuxtv.org/media_build.git
# Scarichiamo e decomprimiamo l'ultima versione dei drivers cd ./media_build/linux wget http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2&& tar -jxf linux-media-LATEST.tar.bz2 cd ..
wget ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/01-stb0899_if_agc_gain.diff wget ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/02-stb0899_signal_flag.diff wget ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches/03-stb0899_signal_strength_limits.diff
patch -p1< 01-stb0899_if_agc_gain.diff patch -p1< 02-stb0899_signal_flag.diff patch -p1< 03-stb0899_signal_strength_limits.diff
Source: http://wiki.vdr-italia.org/doku.php?id=vdr:installazione_di_vdr_con_debian_w...
Ciao, Pizzak
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 19.06.2011 12:41, schrieb Klaus Schmidinger:
- The initial channel is now stored by the channel ID in the setup.conf file, in order to avoid problems in case channels are reordered or deleted (reported by Lars Bläser).
This change includes a change to cMenuEditChanItem to accept a cString to a channel id as parameter, however the changes are never written back. As consequence, the initial channel always reverts to the previous value when leaving the misc setup menu.
The attached patch fixes this.
Cheers,
Udo