vdr January 2014

vdr@linuxtv.org

26 participants
19 discussions

Re: [vdr] VDR test series about frame detector
by cedric.dewijs＠telfort.nl 15 Jan '14

15 Jan '14

>Then you compile the attached C++ file (unziped, of course): >> g++ -c framedetectortest.cpp > >Then you're linking it: >g++ -o framedetectortest framedetectortest.o remux.o ringbuffer.o thread.o tools.o i18n.o sections.o channels.o device.o audio.o ci.o receiver.o transfer.o player.o osdbase.o >status.o skins.o osd.o config.o font.o sources.o menu.o recording.o videodir.o timers.o epg.o dvbplayer.o menuitems.o remote.o keys.o interface.o plugin.o cutter.o themes.o >svdrp.o eit.o eitscan.o shutdown.o filter.o sourceparams.o dvbsubtitle.o pat.o sdt.o nit.o dvbdevice.o diseqc.o recorder.o dvbci.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl - >ljpeg > >Now you've got an application called framedetectortest, which you can feed your vdr recordings (*.ts files) to: >> ./framedetectortest 00002.ts > >The output looks about like this: > >Checking file at offset 0 >Without frame limit... Found I frame after 99452 bytes >With frame limit 5... Found I frame after 220336 bytes >With frame limit 6... Found I frame after 99452 bytes >TS package frame size needed for this video block: 6 >Maximum TS package frame size needed for this video recording: 6 > >I need reports which number your stream resulted in (the "Maximum TS package frame size") and what you've tested >(Cable? Satellite? Terrestrical? HD, SD? Your country?). The result is interesting even if it is 5 or 6. > >Thanks in advance, >Eike Hi Eike, In vdr 2.0.4 I have to add -lrt to the link command: $ g++ -c framedetectortest.cpp $ g++ -o framedetectortest framedetectortest.o remux.o ringbuffer.o thread.o tools.o i18n.o sections.o channels.o device.o audio.o ci.o receiver.o transfer.o player.o osdbase.o status.o skins.o osd.o config.o font.o sources.o menu.o recording.o videodir.o timers.o epg.o dvbplayer.o menuitems.o remote.o keys.o interface.o plugin.o cutter.o themes.o svdrp.o eit.o eitscan.o shutdown.o filter.o sourceparams.o dvbsubtitle.o pat.o sdt.o nit.o dvbdevice.o diseqc.o recorder.o dvbci.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg tools.o: In function `cTimeMs::Now()': /storage/home/ingeborg/Downloads/vdr-2.0.4/tools.c:674: undefined reference to `clock_gettime' /storage/home/ingeborg/Downloads/vdr-2.0.4/tools.c:655: undefined reference to `clock_getres' /storage/home/ingeborg/Downloads/vdr-2.0.4/tools.c:659: undefined reference to `clock_gettime' collect2: error: ld returned 1 exit status $ g++ -o framedetectortest framedetectortest.o remux.o ringbuffer.o thread.o tools.o i18n.o sections.o channels.o device.o audio.o ci.o receiver.o transfer.o player.o osdbase.o status.o skins.o osd.o config.o font.o sources.o menu.o recording.o videodir.o timers.o epg.o dvbplayer.o menuitems.o remote.o keys.o interface.o plugin.o cutter.o themes.o svdrp.o eit.o eitscan.o shutdown.o filter.o sourceparams.o dvbsubtitle.o pat.o sdt.o nit.o dvbdevice.o diseqc.o recorder.o dvbci.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg -lrt I see the following when running the command on recordings from digitenne, Netherlands: $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 165816 bytes With frame limit 5... Found I frame after 165816 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 324864 bytes With frame limit 5... Found I frame after 324864 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 276736 bytes With frame limit 5... Found I frame after 276736 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 141376 bytes With frame limit 5... Found I frame after 141376 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 273916 bytes With frame limit 5... Found I frame after 273916 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 205484 bytes With frame limit 5... Found I frame after 205484 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 $ ./framedetectortest ~/tmp/00001.ts Checking file at offset 0 Without frame limit... Found I frame after 243836 bytes With frame limit 5... Found I frame after 243836 bytes TS package frame size needed for this video block: 5 Maximum TS package frame size needed for this video recording: 5 Kind regards, Cedric

1 0

Frame detector glitch
by Eike 14 Jan '14

14 Jan '14

Hello! I'm experiencing what I'd call a glitch of VDR's frame detector class. There's a define #define MIN_TS_PACKETS_FOR_FRAME_DETECTOR 5. According to my experiences, this number of TS packages in not always enough to detect frames as early as possible. Thus it is a matter of chance if detection will be fed with enough data to detect the first frame or if it will glitch through to another one. I think we should avoid such situations. I attached demo code (needs some includes and to be compiled and linked with VDR) which shows the behaviour and I stored a short TS sample at http://ein-eike.de/wordpress/wp-content/uploads/2014/01/vdr-sample.ts The code checks when an I frame is found, at first with full data available, and then with data dripping in with a frame size of 5, 6 ... until the dripping data yields the same result as the flooding data. I get the following output from the given example: Checking file at offset 0 Without frame limit... Found I frame after 190256 bytes With frame limit 5... Found I frame after 398560 bytes With frame limit 6... Found I frame after 190256 bytes TS package frame size needed for this video block: 6 Maximum TS package frame size needed for this video recording: 6 Unfortunately, I cannot tell if 6 is the definite number to avoid such glitches or if other circumstances would need a higher number. I wrote the code such as people might try it out on their video files so we could experiment. (I could provide a Linux executable as well.) Ciao, Eike

3 3

vdr-xine and vdr-2.1.3
by Joerg Riechardt 11 Jan '14

11 Jan '14

Hi, Reinhard Nissl’s vdr-xine is still my favorite output plugin. The additional parameter in cDevice::TrickSpeed() breaks fast forward, instead of increasing the speed in three steps, it is always most fast. Has anybody a patch for this, or is planning to create one? Joerg

2 2

Best IDE for VDR development?
by cedric.dewijs＠telfort.nl 08 Jan '14

08 Jan '14

Hi All, What is the best IDE to use for VDR development under linux? Up to now I have used nano, but then I can only view one file at a time, and there's no source code analysis. Kind regards, Cedric

2 1

[ANNOUNCE] VDR version 2.0.5 released
by Klaus Schmidinger 07 Jan '14

07 Jan '14

VDR version 2.0.5 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.0.5.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.0.4-2.0.5.diff MD5 checksums: f58b9836a60440fde84480a2e37ee91d vdr-2.0.5.tar.bz2 3a1788b3c178eda372dd25071c06e763 vdr-2.0.4-2.0.5.diff This version fixes a few minor bugs that came up after the release of version 2.0.4. The changes since version 2.0.4: - The LIRC remote control now connects to the socket even if it doesn't yet exist when VDR is started (thanks to Lars Hanisch). - Fixed a missing initialization in the c'tor of cSkinLCARSDisplayChannel (thanks to Marko Mäkelä). - Fixed uninitialized item area coordinates in cSkinLCARSDisplayMenu (reported by Marko Mäkelä). - Fixed a possible crash if the recordings list is updated externally while the Recordings menu is open (reported by Lars Hanisch). - Added a missing closing ')' in the help and man page entry of the --vfat option (reported by Lars Hanisch). - Fixed setting the name of the video directory to avoid a crash when using --genindex, and also to use the correct directory with --edit (the latter reported by Marko Mäkelä). Have fun! Klaus

1 0

[ANNOUNCE] VDR developer version 2.1.3
by Klaus Schmidinger 07 Jan '14

07 Jan '14

VDR developer version 2.1.3 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.3.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.2-2.1.3.diff MD5 checksums: 054f80e0045aa6fad118e9285b52f4f2 vdr-2.1.3.tar.bz2 3c5ab05d5c4d0b984b34e84190e80949 vdr-2.1.2-2.1.3.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. Originally I intended to release this version only after the new DiSEqC configuration dialog was finished. But in the meantime quite a few other things have come up, so I decided to postpone that dialog and first release what has piled up so far. The changes since version 2.1.2: - Changed the return value of cPositioner::HorizonLongitude() to 0 in case the latitude of the antenna location is beyond +/-81 degrees. - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed some compiler warnings with gcc-4.6.3 (thanks to Rolf Ahrenberg). - Changed the name of the SVDRP command RENR to MOVR (suggested by Rolf Ahrenberg). - When cutting a recording it is now checked whether there is already an edited version of this recording (with the same name, but starting with '%'), and the user is prompted for confirmation to overwrite it (suggested by Rolf Ahrenberg). - Revoked "Added maximum signal strength value for TechniSat SkyStar 2 DVB-S rev 2.3P" because it broke things for the "TechniSat AirStar 2" DVB-T card. - The LIRC remote control now connects to the socket even if it doesn't yet exist when VDR is started (thanks to Lars Hanisch). - Changed the absolute latitude limit for visible satellites to 81.2 degrees. - Added code for parsing LCN and AVC descriptors to libsi (thanks to Rolf Ahrenberg). - In the "Select folder" menu pressing Ok now selects the folder, even if this is a folder that contains sub folders (marked with "..."). To open such a folder you can press the Red key. - Fixed a possible access to uninitialized data in cEIT::cEIT() (reported by Dominik Strasser). - The new menu category mcRecordingEdit is now used to mark menus that edit recording properties (suggested by Stefan Braun). - Changes in the teletext PID no longer cause retuning (and thus interrupting a recording). - Removed '_' from the FileNameChars and CharMap translations in uk_UA.po. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed a missing initialization in the c'tor of cSkinLCARSDisplayChannel (thanks to Marko Mäkelä). - Simplified some conditional expressions in skinlcars.c and skinsttng.c (suggested by Marko Mäkelä). - Fixed uninitialized item area coordinates in cSkinLCARSDisplayMenu (reported by Marko Mäkelä). - Fixed a possible crash if the recordings list is updated externally while the Recordings menu is open (reported by Lars Hanisch). - Added a missing closing ')' in the help and man page entry of the --vfat option (reported by Lars Hanisch). - Fixed setting the name of the video directory to avoid a crash when using --genindex, and also to use the correct directory with --edit (the latter reported by Marko Mäkelä). - The Recordings menu can now be called with a cRecordingFilter, which allows the caller to have it display only a certain subset of the recordings (thanks to Lars Hanisch). - Added handling UTF-8 'umlaut' characters to cKbdRemote (thanks to Lars Hanisch). - Made it clear that the Data parameter in cDevice::StillPicture() may point to a series of packets, not just a single one (thanks to Thomas Reufer). - cDevice::TrickSpeed() now has an additional parameter named Forward, which indicates the direction in which replay is being done (suggested by Thomas Reufer). This information may be necessary for some output devices in order to properly implement trick modes. Authors of plugins that implement output devices will need to add this parameter to their derived cDevice class, regardless of whether they will make use of it or not. - Added a note to ePlayMode in device.h that VDR itself always uses pmAudioVideo when replaying a recording (suggested by Thomas Reufer). - Fixed some spellings in positioner.h and Doxyfile (thanks to Ville Skyttä). - Changed '%a' to the POSIX compliant '%m' in all scanf() calls (thanks to Ville Skyttä). - The new function cCamSlot::Decrypt() can be used by derived classes to implement a CAM slot that can be freely assigned to any device, without being directly inserted into the full TS data stream in hardware. A derived class that implements Decrypt() will also need to set the new parameter ReceiveCaPids in the call to the cCamSlot base class constructor to true, in order to receive the CA pid TS packets that contain data necessary for decrypting. - Many member functions of cCamSlot have been made virtual to allow for easier implementation of derived classes. - cTSBuffer now provides the number of available bytes in its Get() function. - cDvbDevice::GetTSPacket() now calls CamSlot()->Decrypt() in order to allow CAM slots that can be freely assigned to any device access to the TS data stream. - Added a check to avoid a possible NULL pointer dereference in cCiSession::SendData() (reported by Ville Skyttä). - Deleted a superfluous assignment in cPipe::Open() (reported by Ville Skyttä). - The script given to VDR with the '-r' option is now also called after the recording process has actually started (thanks to Christian Kaiser). - Avoiding unnecessary pkg-config warnings in plugin Makefiles (thanks to Ville Skyttä). Plugin authors may want to apply the following change to their Makefile: -PKGCFG = $(if $(VDRDIR),$(shell pkg-config --variable=$(1) $(VDRDIR)/vdr.pc),$(shell pkg-config --variable=$(1) vdr || pkg-config --variable=$(1) ../../../vdr.pc)) +PKGCFG = $(if $(VDRDIR),$(shell pkg-config --variable=$(1) $(VDRDIR)/vdr.pc),$(shell PKG_CONFIG_PATH="$$PKG_CONFIG_PATH:../../.." pkg-config --variable=$(1) vdr)) - Eliminated MAXDVBDEVICES (suggested by Oliver Endriss). - Channels that are no longer contained in the current SDT of a transponder are now marked with the keyword OBSOLETE in their name and provider fields. That way you can identify obsolete channels when you switch to them, and you can get the complete overview of all obsolete channels by sorting the Channels list by provider (by pressing the 0 key twice). Automatic deletion of obsolete channels may follow later. Have fun! Klaus

8 9

diseqc.conf for Spaun and quad-LNBs
by Martin Lang 06 Jan '14

06 Jan '14

Hi all, I recently moved to Australia and now an looking to make my vdr work. I have two quad LNBs (single local oscillator frequency) attached to a Spaun 9x7 multi-switch. The spaun is set to "Quad mode". For the S156E position ("satellite A") I can tune to both H+V and run a channel scan. For the satellite "B" (S160E) I cannot tune anything - neither with vdr nor with dvbscan. On S156E I have a Foxtel (Sky-equivalent) box attached and it tunes nicely, too. So maybe the Foxtel box did send some commands to the LNB which made it work, whereas on S160E this did not happen (yet) ? Can anybody please help with the correct diseqC.conf ? My attempt (see below) to modify the one from http://www.vdr-portal.de/index.php?page=Thread&postid=927921 did not work so far. Thanks Martin # from this thread # http://www.vdr-portal.de/index.php?page=Thread&postid=927921 # multiswitch + 2x Quad LNBs ##Multischalter Eingang A #S13.0E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t #S13.0E 99999 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T #S13.0E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t #S13.0E 99999 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T ##Multischalter Eingang B #S19.2E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t #S19.2E 99999 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T #S19.2E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t #S19.2E 99999 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T # #Multischalter Eingang A S156E 99999 V 10700 t v W15 [E0 10 38 F0] W15 A W15 t #S156E 99999 V 10700 t v W15 [E0 10 38 F1] W15 A W15 T S156E 99999 H 10700 t V W15 [E0 10 38 F2] W15 A W15 t #S156E 99999 H 10700 t V W15 [E0 10 38 F3] W15 A W15 T #Multischalter Eingang B #S160E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t S160E 99999 V 10700 t v W15 [E0 10 38 F5] W15 B W15 T #S160E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t S160E 99999 H 10700 t V W15 [E0 10 38 F7] W15 B W15 T

1 0

[PATCH] Update satellites in default sources.conf
by Antti Hartikainen 06 Jan '14

06 Jan '14

Hi. I thought it would be time to finally update outdated sources.conf. Patch is against sources.conf delivered with VDR 2.1.3. Some things came up, and I would like to hear some opinions about them. There was/is entries like: S28.2E for Astra 2 satellites and S28.5E for Eutelsat satellite at almost same orbital position Both satellites are supposed to be watched with one dish and LNB, but still they have their own entries in sources.conf. Similar example is "S1W Thor 5/6 & Intelsat 10-02". Thor satellites are positioned 0.2 degrees apart from Intelsat. So should these satellites nearby eachother to be combined as one, or should every one to be separated as its own position? In this patch I have combined 28.2E and 28.5E positions as one 28.2E position, as atleast I have set them both up as one single position. I also wanted to change S1W to S0.8W, as it's more true, but I can imagine it would cause a lot of trouble for people who are using the default sources.conf file as their sources.conf, so for now I left it as is. It doesn't really matter, but improves signal strength for people using USALS. :)

2 4

xinelib / vdpau suddenly fails to detect Nvidia ION GPU
by Harald Milz 05 Jan '14

05 Jan '14

Hi all, I've been using a Zotac ION board with Nvidia GPU as XINE player for SD and HD for quite a while. The player is vdr-sxfe with "--video vdpau". This has worked fine until recently, when the combo started to throw spurious errors like (from the vdr-sxfe log): load_plugins: plugin /usr/lib/xine/plugins/2.0/xineplug_dmx_mngvo_vdpau: Can't create vdp device : unsupported GPU? [5837] [vdr-fe] fe_xine_init: xine_open_video_driver("vdpau") failed Error initializing xine Lately, this happens reproducibly every time I start vdr-sxfe. (I had to switch to xxmc which works fine for SD programs but gives me a bit of stutter for HD channels on the 1.6 GHz single core Atom.) Any idea where I should look? Why might xinelib or vdr-sxfe fail to correctly detect the ION (MCP79) chip when everything is unchanged? Yes I ran an apt-get upgrade on the underlying Ubuntu 12.04.3 OS but this didn't change anything, apparently. TIA! -- You will hear good news from one you thought unfriendly to you.

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr January 2014