vdr August 2011

vdr@linuxtv.org

40 participants
61 discussions

[ANNOUNCE] VDR developer version 1.7.19
by Klaus Schmidinger 10 Aug '11

10 Aug '11

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 … [View More]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 [View Less]

5 11

PES packets sent to cDevice::PlayVideo: only audio and video?
by Laz 07 Aug '11

07 Aug '11

Hi, I'm tidying up changes made to the softdevice plugin to get it working with vdr > 1.7.0 which uses TS for recordings. It all works fine pretty much most of but I have some errors I'd like to track down. Are the PES packets provided to the primary device's PlayVideo function purely video and audio packets? It looks to me like the PAT and PMT are stripped out so that only MPEG2 (no HD for me at the moment) audio and video packets should get to PlayVideo(), and so the primary device … [View More]

2 3

VPS fallback patch
by Dave 06 Aug '11

06 Aug '11

For some time (at least since 2008) Mandriva Linux have been including the attached patch in the version of vdr shipped with their distribution. It allows timers to be triggered directly by the Now/Next data in the EIT provided that a new parameter is set in the config file. Looking back in the mailing list archives I see the question of including this feature in vdr is an old one; see for example: http://www.linuxtv.org/pipermail/vdr/2005-August/003975.html However I wonder if the time … [View More]

4 6

Transfer mode vs TS playback: any difference in TS streams for vdr.1.7.19?
by Laz 06 Aug '11

06 Aug '11

Hi, I'm currently updating the softdevice plugin to work with the changes to TS format that started with vdr-1.7.1 and also current versions of ffmpeg (libavcodec does the actual decoding). I've made some progress with vdr-1.7.19: Old PES recordings play fine (as I'd hoped they would!) New TS recordings play: the video looks fine. PlayTSVideo convertes to PES and passes that to PlayVideo of the output device (I assume it would be relatively straightforward to implement a proper PlayTs … [View More]

3 5

Re: [vdr] AAC LATM audio issue on dvb-t israeli service
by Barak Nahari 04 Aug '11

04 Aug '11

I've used dvbsnoop to analyze my ts file. Audio stream of the first channel PID is 2562. PES PID of the from dvbsnoop is 0xc1 and state that is ISO/IEC 13818-3 or ISO/IEC 11172-3 audio stream. The audio encoded ac aac latm, is that means the the PES PID is set wrong in the stream ? Info from dvbsnoop Sync-Byte 0x47: 71 (0x47) Transport_error_indicator: 0 (0x00) [= packet ok] Payload_unit_start_indicator: 1 (0x01) [= Packet data starts] transport_priority: 0 (0x00) PID: 2562 (0x0a02) [= ] … [View More]

1 0

Re: [vdr] AAC LATM audio issue on dvb-t israeli service
by Barak Nahari 04 Aug '11

04 Aug '11

I'm not a programmer but i've done some reading, trying to understand what is wrong. I've looked in the vdr source and found that vdr should be recognizing the acc latm encoded audio, so the problem may not be in vdr. http://git.gekrumbel.de/vdr.git?p=vdr.git;a=blob;f=remux.c;h=c3f07fb7074754… For what i understand the aac latm should have PID 0x11. I've looked inside the vnsiserver source and didn't found any PID's only PES PID's. https://github.com/pipelka/vdr-plugin-vnsiserver/blob/… [View More]

1 0

Re: [vdr] HDHomerun and streamdev
by Kirk Bromfield 03 Aug '11

03 Aug '11

I had the same problem until I downgraded to streamdev 0.5.0 and hdhomerun_atsc_firmware_20100828.bin. I am not sure both of these changes are necessary as I changed both at the same time. :( http://download.silicondust.com/hdhomerun/hdhomerun_atsc_firmware_20100828.… On Jul 16, 2011 6:00 AM, <vdr-request(a)linuxtv.org> wrote:

3 5

blacklisting providers
by Davide Chiarini 02 Aug '11

02 Aug '11

Hi all I was wondering if there is already a way, or a plugin, to 'blacklist' some providers from the channel updates. The fact is, I like to have channel updates set to 'new transponders' (there are often changes with my provider). However, this always leads to hardly manageable channel lists with literally thousands of entries. It would help if the channel updates could automatically discard/ignore certain pay-for providers that I'm not interested in (and could not view anyway, as they are … [View More]

1 0

will VDR run on this?
by Arturo Martinez 01 Aug '11

01 Aug '11

http://www.geek.com/articles/chips/raspberry-pi-25-pc-goes-into-alpha-produ… Any thoughts?

6 5

[Announce] svdrposd-0.1.1
by Frank Schmirler 01 Aug '11

01 Aug '11

Hi there, I just published a new release of svdrposd at http://vdr.schmirler.de. The plugin publishes the contents of the OSD menu on SVDRP. It's primarily used by the remoteosd plugin. The new release fixes a minor bug which caused problems when using the svdrp4j Java client. Have fun! Frank

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr August 2011