vdr

vdr@linuxtv.org

2 participants
6731 discussions

preventing vdr from using a device to record
by syrius.ml＠no-log.org 27 Apr '11

27 Apr '11

Hi, I'm now running one vdr instance with 4 dvb devices. One device is crashing quite often and I haven't find a way to automatically detect when it's crashed. (vdr used to issues "unknown picture type message in the past) I'd like to prevent vdr from using it for recordings. Do you know of any plugin or patch that help achieving this ? Ideally I'd love to be able to set priorities and properties to devices. Something like: device #1: can_record, can_do_epg_scan, can_do_liveview, devprio=100 device #2: can_record, can_do_epg_scan, can_do_liveview, devprio=90 device #3: can_do_liveview, devprio=10 Is there a way for plugins to alter *cDevice::GetDevice behavior ? Are there any plans on that matter ? --

5 9

DVBSubtitle support in VDR when dvbsubtitle stream is crypted
by crow 25 Apr '11

25 Apr '11

Finaly this is done, and VDR users who watch Ex-Yu channels and packages like TotalTV can now enjoy even more while watching HBO and such channels. Fix that Reinhard Nißl provided on IRC while debuging this issue is attached and confirmed from me that works. Issue was that dvbsubtitle stream provided by this providers is crypted, but VDR didnt send Spid to decrypt and after all wasn't able to decode and render it. Patched is ci.c file to add Spid and send it to decryption.

1 0

Can VDR match EIT on SID only?
by John Klimek 25 Apr '11

25 Apr '11

It looks like my DVB provider is broadcasting incorrect EIT information. The SIDs listed are correct but the ONID and TSID are invalid. Can VDR ignore the ONID/TSID and match EIT information solely on the SID? Would this be hard to patch? It looks like eit.c would need to be modified so it can retrieve a channel based on SID. Currently it calls Channels.GetByChannelID(getOriginalNetworkId(), getTransportStreamId(), getServiceId()); Would it require anything besides adding a Channels.GetBySIDOnly() function and using that instead?

2 1

non standard `.c` extension for C++ files
by Paul Menzel 24 Apr '11

24 Apr '11

Dear VDR developers, I am curious why the C++ source files have the extension `.c` and not `.c{c,pp,xx}`. I am asking because I tried to use `scan-build` from Clang/LLVM and by default – and I did not find an option to change that – it treats `.c` files as C files and not C++. Running Clang directly on the `.c` files the following message is displayed. clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated The folks an #llvm helped me and by verifying this putting #ifndef __cplusplus #error Not C++ #endif in a file. Clang can be passed `-x c++` to override that behavior. In the end I renamed the files and adapted `Makefile` to get `scan-build` working and it did not find any errors. Thanks, Paul

2 1

Re: [vdr] TT Premium S2-6400 (F?ley Istv?n)
by serge pecher 21 Apr '11

21 Apr '11

This seems to be very promising ! I was a little bit surprised to see in the specifications that it needs a CPU minimum P4 2 Ghz. That is a pity, because it should be great if it could be used in a thinclient like the HP T5000 series with 1 Ghz and 1 Gb. Did anyone gave it a try ? thanks, SP > I know that some of you (especially Klaus :) ) already own this card, as > a few arrived to dvbshop. > I'm asking you to share some experiences, as I hardly understand german > discussions on vdrportal. > Currently I'm having two VDR machines, one with DVB-S Premium + CRT TV, > and another one with DVB-S2 budget + xine. > What I would like to know: with the new S2-6400 card does VDR works as > rock solid as worked with FF DVB-S cards? > This means for me: > - OSD and remote are working instanly > - even if I'm watching a HD playback, fast forward (and backward) works > as expected > - output device does not crash > - I can leave the whole system to work for weeks and to be operated by > my family, and it always will work as expected (as a VDR + FF DVB-S > combo does) > > thanks for your answers. > > Istvan -- Serge PECHER Director SDMO nv/sa Wijnegembaan 2 B-2900 Belgium T : +32 3 620 16 41 Mobile : +32 475 78 20 28

4 6

TT Premium S2-6400
by Füley István 20 Apr '11

20 Apr '11

I know that some of you (especially Klaus :) ) already own this card, as a few arrived to dvbshop. I'm asking you to share some experiences, as I hardly understand german discussions on vdrportal. Currently I'm having two VDR machines, one with DVB-S Premium + CRT TV, and another one with DVB-S2 budget + xine. What I would like to know: with the new S2-6400 card does VDR works as rock solid as worked with FF DVB-S cards? This means for me: - OSD and remote are working instanly - even if I'm watching a HD playback, fast forward (and backward) works as expected - output device does not crash - I can leave the whole system to work for weeks and to be operated by my family, and it always will work as expected (as a VDR + FF DVB-S combo does) thanks for your answers. Istvan

6 7

Can VDR use one specific transponder for EPG information?
by John Klimek 19 Apr '11

19 Apr '11

My DVB-S provider sends a 9-day EPG guide only one one specific transponder. Is it possible to use only that transponder for EPG grabbing? ...or can I specify which channels/transponders to use somehow?

4 7

[Announce] remotetimers-0.1.5
by Frank Schmirler 18 Apr '11

18 Apr '11

Hi there, remotetimers-0.1.5 is available from http://vdr.schmirler.de. Older versions no longer compile with VDR 1.7.18. Changelog: - Always update help keys when changing user filter in recordings menu - Fixed wrong help keys in recordings menu when user filter is active - The "red" key to open a recordings directory didn't work - No longer using cRecordingInfo::Read(FILE) in VDR 1.7.3+. It's going to be a private member in VDR 1.7.18 - Added Slovak translation (thanks to Milan Hrala) Have fun, Frank

1 0

[ANNOUNCE] VDR developer version 1.7.18
by Klaus Schmidinger 17 Apr '11

17 Apr '11

VDR developer version 1.7.18 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.18.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17-1.7.18.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. The changes since version 1.7.17: - Changed -O2 to -O3 in Make.config.template (reported by Matti Lehtimäki). - Added a missing 'default' case in cPixmapMemory::DrawEllipse(). - Fixed some direct comparisons of double values. - Fixed detecting frames on channels that broadcast with separate "fields" instead of complete frames. - Made updating the editing marks during replay react faster in case the marks file has just been written (with a patch from Udo Richter). - Fixed horizontal scaling of subtitles (reported by Reinhard Nissl). - Stripped the note "The data returned by this function is only used for informational purposes (if any)" from the description of cDevice::GetVideoSize(). The VideoAspect is now used to properly scale subtitles. - Fixed cUnbufferedFile::Seek() in case it is compiled without USE_FADVISE (thanks to Juergen Lock). - Fixed the Language header of the Serbian translation file (thanks to Ville Skyttä). - Added anti-aliasing when upscaling bitmaps, which improves the display of SD subtitles when replayed on an HD OSD (thanks to Reinhard Nissl for his help in debugging). - Renamed cBitmap::Scale() to Scaled(), because it doesn't modify the bitmap itself, but rather returns a scaled copy. - Fixed the description of cReceiver in PLUGINS.html, regarding detaching a receiver from its device before deleting it (reported by Winfried Köhler). This change in behavior was introduced in version 1.5.7. - Fixed scaling subtitles in case the OSD size is exactly the same as the display size of the subtitles. - Added a missing initialization to sDvbSpuRect (reported by Sergiu Dotenco). - Replaced "%lld" and "%llX" print format specifiers with "PRId64" and "PRIX64" to avoid compiler warnings with gcc 4.5.2 (thanks to Sergiu Dotenco). On a personal note: I find it a step in the totally wrong direction that there have been macros introduced to work around this problem in the first place. There should have been "real" format specifiers defined that address this. These macros are nothing but an ugly workaround. - Added Cancel(3) to ~cTrueColorDemo() in the "osddemo" plugin (thanks to Reinhard Nissl). - Added a missing font deletion in cTrueColorDemo::Action() in the "osddemo" plugin (thanks to Reinhard Nissl). - Fixed a buffer overflow in cFont::Bidi() (thanks to Reinhard Nissl). - Added HD stream content identifiers to vdr.5 (thanks to Christoph Haubrich). - Made cRecordingInfo::Read(FILE *f) private to avoid calls to it from outside cRecordingInfo or cRecording (reported by Mika Laitio). - The dvbhddevice plugin is now part of the VDR distribution archive (thanks to Andreas Regel). - Removed an obsolete local variable in dvbsdffosd.c (thanks to Paul Menzel). - Fixed a possible NULL pointer dereference in osddemo.c (reported by Paul Menzel). - Now using pkg-config to get fribidi, freetype and fontconfig cflags and libs (thanks to Ville Skyttä). - The Makefile now also installs the include files (thanks to Ville Skyttä). - Added handling of "ANSI/SCTE 57" descriptors (thanks too Rolf Ahrenberg). - Avoiding an unecessary call to Recordings.ResetResume() (thanks to Reinhard Nissl). Have fun! Klaus

3 3

I just downgraded from vdr 1.7.17 to 1.7.15
by Arturo Martinez 15 Apr '11

15 Apr '11

I realized after upgrading to 1.7.17 (from 1.7.15) that encrypted recordings (TVE1, Antena3) were unwatchable (visibly dropping many frames) So using the same Make.config and the same set of plugins I downgrade to 1.7.15 and the recordings work fine. Is this somehow a known problem? Any point in trying 1.7.16 ?

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr