Re: [vdr] *** GMX Spamverdacht *** Re: Can VDR use one specific transponder for EPG information?
Am 18.04.2011 00:15, schrieb VDR User: > On Sun, Apr 17, 2011 at 1:31 PM, Timothy D. Lenz wrote: >> Just a thought but you could set up a daily or weekly timer with a very low >> priority on the recording so it auto deletes it. I've never used the auto >> delete after set time because I never know how long it will be before I get >> back to watching the recording. > > Are you sure the epg scanner is active if the device is recording? AFAICT all the automatic scanning mechanisms get attached to a device whenever a transponder is tuned. (section handler) That way, the EPG of the current channel is always up to date, and changes to subtitles and audio tracks get updated. BTW: For starting up VDR at a given time to do some EPG scanning, you might want to take a look at the scheduler plugin [1]. Cheers, Udo [1] http://winni.vdr-developer.org/scheduler/index_eng.html ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
On Sun, Apr 17, 2011 at 1:31 PM, Timothy D. Lenz wrote: > Just a thought but you could set up a daily or weekly timer with a very low > priority on the recording so it auto deletes it. I've never used the auto > delete after set time because I never know how long it will be before I get > back to watching the recording. Are you sure the epg scanner is active if the device is recording? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
Just a thought but you could set up a daily or weekly timer with a very low priority on the recording so it auto deletes it. I've never used the auto delete after set time because I never know how long it will be before I get back to watching the recording. On 4/17/2011 9:18 AM, John Klimek wrote: Thanks for the reply. What's the best way to tune to that transponder? Using SVDRP? (ie. I'm new to VDR but would I issue a CHAN command, then wait 10 minutes (or whatever), then issue another CHAN command?) Could I disable automatic EPG grabbing and manually tell it to grab EPG in my script? (using SVDRP?) On Sun, Apr 17, 2011 at 11:54 AM, VDR User wrote: On Sun, Apr 17, 2011 at 6:39 AM, John Klimek wrote: 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? AFAIK VDR isn't capable of that. I just remember to tune an EEPG transponder every few days. You could write a little cron script to tune your EEPG transponder each day at some hour like 4am (assuming you're sleeping at that time), let it sit for however long it takes to populate, and then tune back to the channel it was on previously. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
Hi, Am 16.04.2011 16:28, schrieb syrius...@no-log.org: 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 ? Please modify the attached plugin, telling that device 3 doesn't provide any transponder. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de vdr-transponderconstraints-0.0.1.tgz Description: GNU Unix tar archive ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
VDR User writes: > On Sun, Apr 17, 2011 at 2:36 AM, wrote: >> vdr-sxfe output complains it can't demultiplex the stream, but that >> won't work when I'm away and nobody's watching tv. That won't prevent >> vdr from using the bad card. > > If the vdr-sxfe log gives you useful text for this, why can't you > simply write a script that runs in the background and checks for such > text every X seconds. If the text is found, it can do whatever you > normally do to fix the problem. > > I do something similar to detect xine crashes and it works fine. > Although my preference would be the "buffer usage: 100%" crash would > be fixed once and for all. ;) But that's another issue.. Thanks for your answer, but you should reckon that checking vdr-sxfe won't help preventing vdr from using a crashed card for the timed recordings. I could do something similar if the driver was reporting that the card had crashed, and thanks to the dynamite patch I could remove the device, reload the driver and re-insert it. I'm going to patch getdevice so that the faulty card is only used for live view. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
Klaus Schmidinger writes: > You could start by patching the function > > cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, > bool LiveView) ok thanks, that's what i thought. > But wouldn't it be better to just replace that faulty > device altogether? it's a dvb-ttpci rev1.5 card, i'll try the full-ts mod. I haven't planned to buy a new card yet, I'd rather patch and get dirty with vdr :-) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
On Sun, Apr 17, 2011 at 9:18 AM, John Klimek wrote:
> What's the best way to tune to that transponder? Using SVDRP?
>
> (ie. I'm new to VDR but would I issue a CHAN command, then wait 10
> minutes (or whatever), then issue another CHAN command?)
Yeah, svdrp, sorry forgot to mention that. You can issue CHAN without
a channel number to obtain the current channel. An example could be
something like:
==
#!/bin/bash
eepg_chan=
prev_chan=$(svdrpsend.pl chan |sed -n 2p |awk '{print $2}')
svdrpsend.pl CHAN $eepg_chan
svdrpsend.pl SCAN
sleep 10m
svdrpsend.pl CHAN $prev_chan
==
> Could I disable automatic EPG grabbing and manually tell it to grab
> EPG in my script? (using SVDRP?)
The SCAN svdrp command forces a scan, but I don't know how disabling
EPG grabbing in VDR setup would affect that. I would expect the
behavior of a _forced_ scan to scan regardless of any settings since
the point is to force it.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
Thanks for the reply. What's the best way to tune to that transponder? Using SVDRP? (ie. I'm new to VDR but would I issue a CHAN command, then wait 10 minutes (or whatever), then issue another CHAN command?) Could I disable automatic EPG grabbing and manually tell it to grab EPG in my script? (using SVDRP?) On Sun, Apr 17, 2011 at 11:54 AM, VDR User wrote: > On Sun, Apr 17, 2011 at 6:39 AM, John Klimek wrote: >> 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? > > AFAIK VDR isn't capable of that. I just remember to tune an EEPG > transponder every few days. You could write a little cron script to > tune your EEPG transponder each day at some hour like 4am (assuming > you're sleeping at that time), let it sit for however long it takes to > populate, and then tune back to the channel it was on previously. > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
On Sun, Apr 17, 2011 at 6:39 AM, John Klimek wrote: > 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? AFAIK VDR isn't capable of that. I just remember to tune an EEPG transponder every few days. You could write a little cron script to tune your EEPG transponder each day at some hour like 4am (assuming you're sleeping at that time), let it sit for however long it takes to populate, and then tune back to the channel it was on previously. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
On Sun, Apr 17, 2011 at 2:36 AM, wrote: > vdr-sxfe output complains it can't demultiplex the stream, but that > won't work when I'm away and nobody's watching tv. That won't prevent > vdr from using the bad card. If the vdr-sxfe log gives you useful text for this, why can't you simply write a script that runs in the background and checks for such text every X seconds. If the text is found, it can do whatever you normally do to fix the problem. I do something similar to detect xine crashes and it works fine. Although my preference would be the "buffer usage: 100%" crash would be fixed once and for all. ;) But that's another issue.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.18
Dear Klaus, thank you for this new release. Am Sonntag, den 17.04.2011, 16:50 +0200 schrieb Klaus Schmidinger: > 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 I do not know if this has been discussed before, but could you please add the output of `md5sum` or `sha256sum` of the above files to your announcements. […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.7.18
On 17.04.2011 17:15, Dave wrote: On Sunday 17 April 2011 15:50:44 Klaus Schmidinger wrote: 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 Compiling the new version I get lots of compiler errors in the new dvbhddevice plugin. I don't use this plugin and the rest of vdr seems to be fine. A sample: g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -march=native -pipe - fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE - D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I../../../include hdffcmd.c hdffcmd.c: In member function ‘uint32_t HDFF::cHdffCmdIf::CmdGetFirmwareVersion(char*, uint32_t)’: hdffcmd.c:57: error: ‘osd_raw_cmd_t’ was not declared in this scope hdffcmd.c:57: error: expected ‘;’ before ‘osd_cmd’ hdffcmd.c:59: error: ‘osd_cmd’ was not declared in this scope hdffcmd.c:65: error: ‘OSD_RAW_CMD’ was not declared in this scope hdffcmd.c: In member function ‘uint32_t HDFF::cHdffCmdIf::CmdGetInterfaceVersion(char*, uint32_t)’: hdffcmd.c:83: error: ‘osd_raw_cmd_t’ was not declared in this scope hdffcmd.c:83: error: expected ‘;’ before ‘osd_cmd’ hdffcmd.c:85: error: ‘osd_cmd’ was not declared in this scope hdffcmd.c:91: error: ‘OSD_RAW_CMD’ was not declared in this scope Sorry, I guess I should have added a note regarding the driver version that's necessary for this plugin. You can get a suitable driver from http://powarman.dyndns.org/hg/v4l-dvb-saa716x/ Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.7.18
On Sunday 17 April 2011 15:50:44 Klaus Schmidinger wrote: > 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 Compiling the new version I get lots of compiler errors in the new dvbhddevice plugin. I don't use this plugin and the rest of vdr seems to be fine. A sample: g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -march=native -pipe - fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE - D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I../../../include hdffcmd.c hdffcmd.c: In member function ‘uint32_t HDFF::cHdffCmdIf::CmdGetFirmwareVersion(char*, uint32_t)’: hdffcmd.c:57: error: ‘osd_raw_cmd_t’ was not declared in this scope hdffcmd.c:57: error: expected ‘;’ before ‘osd_cmd’ hdffcmd.c:59: error: ‘osd_cmd’ was not declared in this scope hdffcmd.c:65: error: ‘OSD_RAW_CMD’ was not declared in this scope hdffcmd.c: In member function ‘uint32_t HDFF::cHdffCmdIf::CmdGetInterfaceVersion(char*, uint32_t)’: hdffcmd.c:83: error: ‘osd_raw_cmd_t’ was not declared in this scope hdffcmd.c:83: error: expected ‘;’ before ‘osd_cmd’ hdffcmd.c:85: error: ‘osd_cmd’ was not declared in this scope hdffcmd.c:91: error: ‘OSD_RAW_CMD’ was not declared in this scope # gcc -v Using built-in specs. Target: x86_64-manbo-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with- slibdir=/lib64 --with-bugurl=https://qa.mandriva.com/ --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable- languages=c,c++,ada,fortran,objc,obj-c++,java --build=x86_64-manbo-linux-gnu --host=x86_64-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable- threads=posix --enable-shared --enable-objc-gc --enable-long-long --enable- __cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable- java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --with- ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo --disable-libjava- multilib --enable-ssp --disable-libssp --disable-werror --with-ppl --with- cloog --with-python-dir=/lib/python2.6/site-packages Thread model: posix gcc version 4.4.3 (GCC) Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.18
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Can VDR use one specific transponder for EPG information?
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? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
On 17.04.2011 11:36, syrius...@no-log.org wrote: VDR User writes: On Sat, Apr 16, 2011 at 7:28 AM, wrote: 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) If you're not seeing anything useful to your VDR log to determine if the card has crashed, you may want to look at dmesg to see if something in there could be used. Some years ago vdr was reporting the bad picture types when they occured. Now i've got no means to detects them on the server (neither in vdr logs nor in kernel messages) vdr-sxfe output complains it can't demultiplex the stream, but that won't work when I'm away and nobody's watching tv. That won't prevent vdr from using the bad card. My question still remains :) I don't mind patching vdr (changing getdevice or something else). If there's no existing patch or plugin, could you give me some input on what to change to prevent vdr from using one card for recordings and epg scans ? You could start by patching the function cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) But wouldn't it be better to just replace that faulty device altogether? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
VDR User writes: > On Sat, Apr 16, 2011 at 7:28 AM, wrote: >> 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) > > If you're not seeing anything useful to your VDR log to determine if > the card has crashed, you may want to look at dmesg to see if > something in there could be used. Some years ago vdr was reporting the bad picture types when they occured. Now i've got no means to detects them on the server (neither in vdr logs nor in kernel messages) vdr-sxfe output complains it can't demultiplex the stream, but that won't work when I'm away and nobody's watching tv. That won't prevent vdr from using the bad card. My question still remains :) I don't mind patching vdr (changing getdevice or something else). If there's no existing patch or plugin, could you give me some input on what to change to prevent vdr from using one card for recordings and epg scans ? TIA. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
