Re: [vdr] Ring Buffer Overflow with streamdev

[Simon Baxter]

Hi

Am running the latest streamdev cvs, patched with
http://cobradevil.org/downloads/streamdev-xbmc.patch
but am getting frozen live video (recordings are fine) in XBMC and the 
following:


Mar 30 06:27:35 freddy vdr: [12662] ERROR: 1 ring buffer overflow (188 
bytes dropped)
Mar 30 06:27:41 freddy vdr: [12662] ERROR: 51 ring buffer overflows (9588 
bytes dropped)
Mar 30 06:27:47 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:53 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:27:59 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:05 freddy vdr: [12662] ERROR: 60 ring buffer overflows (11280 
bytes dropped)
Mar 30 06:28:10 freddy vdr: [12856] streamdev-livestreaming thread ended 
(pid=12656, tid=12856)
Mar 30 06:28:10 freddy vdr: [12855] streamdev-writer thread ended 
(pid=12656, tid=12855)

Mar 30 06:28:10 freddy vdr: [12674] buffer stats: 63920 (1%) used

How do I diagnose?

Can I expand the buffer (even temporarily) to see if this is what's 
causing the frozen video?


Any other ideas?



I've just tried running vdr-1.7.14 with (s2-liplianin drivers) the same 
version on streamdev and xbmc, all on the local machine running 
2.6.27.30-170.2.82.fc10.x86_64.  Have also installed on another machine 
running 2.6.27.29-170.2.78.fc10.x86_64.


Am still getting the same results, with "ring buffer overflow" messages and 
frozen picture after 3-5 seconds.  Again, playing recordings works fine.


Any ideas? 



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] LiveBuffer patch for vdr 1.7.14 (timeshift)

[Goga777]

any news about Livebuffer patch for ts format and vdr 1.7.14 ?

Goga

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 20:55, Petri Helin wrote:
> On 04/05/2010 12:57 PM, Klaus Schmidinger wrote:
>> On 05.04.2010 00:55, Teemu Rantanen wrote:
>>   
>>> Hi,
>>>
>>> There's a new version of the patch implemented as a plugin. It seems to
>>> work, but there are few things to notice:
>>>
>>> - Plugin does not cache which devices are Reddo devices, instead it
>>> probes sysfs every time QAM256 channel is being tuned into (on any
>>> device). It would be nice if cDeviceHook added a mechanism for a hook to
>>> store context for each device. Hooking into device probe (like full
>>> feature card plugin does) would be much nicer way, but it would
>>> interfere with other plugins which need the same mechanism.
>>>  
>> The proper way of doing this is to check the modulation types
>> in cDvbDevice::ProvidesTransponder(), as in the attached patch (which
>> will
>> be part of VDR 1.7.15). If the "reddo" driver doesn't set the
>> FE_CAN_QAM_256
>> flag correctly, it needs to be fixed there.
>>
>>
> 
> I used your patch as an example and created a simple test patch for
> dvb-c (I think yours is for dvb-s(2) only) in order to test the
> approach.

You're right. I guess the attached version should cover all frontend types.

> I also disabled FE_CAN_QAM256 from the driver. After that VDR
> no longer used Reddo for QAM256 channels as expected. The approach is
> very limited: It disables QAM256 for the every TDA10023 frontend, not
> just for Reddo's,

Well, then the driver needs to make a finer distinction and *properly*
set FE_CAN_QAM256.

> and it doesn't make VDR to prefer Reddo for non QAM256
> channels, which would make sense in order to keep QAM256 channels
> available as much as possible.

First the driver needs to properly report whether a device can handle
a given modulation type. Then VDR can decide whether to use that
device for a channel requiring that modulation. *Then* we can talk
sparing such devices for recordings ;-)

Klaus
--- dvbdevice.c	2010/03/07 13:58:24	2.32
+++ dvbdevice.c	2010/04/05 20:13:05
@@ -886,12 +886,20 @@
 {
   if (!ProvidesSource(Channel->Source()))
  return false; // doesn't provide source
-  if (!cSource::IsSat(Channel->Source()))
- return DeviceHooksProvidesTransponder(Channel); // source is sufficient for non sat
   cDvbTransponderParameters dtp(Channel->Parameters());
-  if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
+  if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
+ dtp.Modulation() == QPSK && !(frontendInfo.caps & FE_CAN_QPSK) ||
+ dtp.Modulation() == QAM_16 && !(frontendInfo.caps & FE_CAN_QAM_16) ||
+ dtp.Modulation() == QAM_32 && !(frontendInfo.caps & FE_CAN_QAM_32) ||
+ dtp.Modulation() == QAM_64 && !(frontendInfo.caps & FE_CAN_QAM_64) ||
+ dtp.Modulation() == QAM_128 && !(frontendInfo.caps & FE_CAN_QAM_128) ||
+ dtp.Modulation() == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256) ||
+ dtp.Modulation() == QAM_AUTO && !(frontendInfo.caps & FE_CAN_QAM_AUTO) ||
+ dtp.Modulation() == VSB_8 && !(frontendInfo.caps & FE_CAN_8VSB) ||
+ dtp.Modulation() == VSB_16 && !(frontendInfo.caps & FE_CAN_16VSB))
  return false; // requires modulation system which frontend doesn't provide
-  if (!Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
+  if (!cSource::IsSat(Channel->Source()) ||
+ !Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
  return DeviceHooksProvidesTransponder(Channel);
   return false;
 }
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] Do not override externally defined `INCLUDES`.

[Paul Menzel]

In some environments, i. e. when cross building, include files are not located 
in the standard path like `/usr/includes/freetype2`. Make it possible to 
provide the correct path without needing to patch `Makefile`.

Signed-off-by: Paul Menzel 
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 31f05b0..c7af79c 100644
--- a/Makefile
+++ b/Makefile
@@ -21,7 +21,7 @@ MANDIR   = $(PREFIX)/share/man
 BINDIR   = $(PREFIX)/bin
 LOCDIR   = ./locale
 LIBS = -ljpeg -lpthread -ldl -lcap -lrt -lfreetype -lfontconfig
-INCLUDES = -I/usr/include/freetype2
+INCLUDES ?= -I/usr/include/freetype2
 
 PLUGINDIR= ./PLUGINS
 PLUGINLIBDIR= $(PLUGINDIR)/lib
-- 
1.7.0.3


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Petri Helin]

On 04/05/2010 12:57 PM, Klaus Schmidinger wrote:

On 05.04.2010 00:55, Teemu Rantanen wrote:
   

Hi,

There's a new version of the patch implemented as a plugin. It seems to
work, but there are few things to notice:

- Plugin does not cache which devices are Reddo devices, instead it
probes sysfs every time QAM256 channel is being tuned into (on any
device). It would be nice if cDeviceHook added a mechanism for a hook to
store context for each device. Hooking into device probe (like full
feature card plugin does) would be much nicer way, but it would
interfere with other plugins which need the same mechanism.
 

The proper way of doing this is to check the modulation types
in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will
be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256
flag correctly, it needs to be fixed there.

   


I used your patch as an example and created a simple test patch for 
dvb-c (I think yours is for dvb-s(2) only) in order to test the 
approach. I also disabled FE_CAN_QAM256 from the driver. After that VDR 
no longer used Reddo for QAM256 channels as expected. The approach is 
very limited: It disables QAM256 for the every TDA10023 frontend, not 
just for Reddo's, and it doesn't make VDR to prefer Reddo for non QAM256 
channels, which would make sense in order to keep QAM256 channels 
available as much as possible. The patches are inline below:


--- dvbdevice.c.orig   2010-02-21 19:10:35.0 +0200
+++ dvbdevice.c   2010-04-05 17:20:06.080525344 +0300
@@ -872,8 +872,12 @@
 {
   if (!ProvidesSource(Channel->Source()))
  return false; // doesn't provide source
-  if (!cSource::IsSat(Channel->Source()))
+  if (!cSource::IsSat(Channel->Source())) {
+ cDvbTransponderParameters dtp(Channel->Parameters());
+ if (dtp.Modulation() == QAM_256 && !(frontendInfo.caps & 
FE_CAN_QAM_256))

+return false;
  return DeviceHooksProvidesTransponder(Channel); // source is 
sufficient for non sat

+  }
   cDvbTransponderParameters dtp(Channel->Parameters());
   if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
  return false; // requires modulation system which frontend 
doesn't provide


--- v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c.orig  
 2010-04-05 15:28:22.605844128 +0300
+++ v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c   2010-04-05 
15:27:54.934343796 +0300

@@ -553,7 +553,7 @@
#endif
   .caps = 0x400 | //FE_CAN_QAM_4
  FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |
- FE_CAN_QAM_128 | FE_CAN_QAM_256 |
+ FE_CAN_QAM_128 | //FE_CAN_QAM_256 |
  FE_CAN_FEC_AUTO
},

-Petri

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 18:14, Teemu Rantanen wrote:
> Ok, so the sysfs names of vendor/product are driver-dependent... All my
> usb devices have idVendor/idProduct even though only one of them is "Reddo".

I'm not saying that what the FuSI driver does is correct, either ;-)
Somebody with more knowledge should clarify this and fix the driver
that is faulty.

> Tried to create the hook on Initialize(), still crashes on exit().

Well, then I guess you'll need to do some debugging to find out what
really goes wrong here.

> Haven't tried your patch, because as far as I know the driver claims it
> can do QAM256, and even if that was disabled today it would take some
> time to get into all linux distributions... Btw it even claims to
> support QAM256 on the product package, but it still doesn't work. I
> guess that's the reason they are so inexpensive here...

At any rate, these things *must* be fixed in the driver!
Even if it takes a while for a fix to get into the main kernel source.

Klaus

> 2010/4/5 Klaus Schmidinger  >
> 
> On 05.04.2010 12:43, Teemu Rantanen wrote:
> > Hi,
> >
> > I tried also without delete cDeviceHook but it still crashed...
> 
> Please try creating the cReddoDeviceHook in
> cPluginDisableReddoQAM256::Initialize(),
> as suggested in PLUGINS.html.
> 
> > Well, the fixes are basically available in the plugin, as I copied the
> > probe method (and modified slightly to suit the plugin). Those are:
> > - The sysfs filenames are idVendor (subsystem_vendor) and idProduct
> > (subsystem_device)
> 
> This is what I get here:
> 
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/subsystem_*
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
> 
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/id*
> ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such
> file or directory
> 
> Maybe a bug in the driver?
> 
> > - You need to set strtoul() base as 16 as the files don't have 0x in
> > front of the hex
> 
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> 0x
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
> 0x13c2
> 
> Maybe the "reddo" driver behaves differently than the FuSi driver?
> 
> > What about making this an utility method in VDR? Give device file name
> > and return id...
> 
> Will do.
> 
> 
> Have you tried whether it works with my patch?
> In that case you wouldn't even need the whole plugin.
> 
> Klaus
> 
> 
> 
> 
> ___
> 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] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Ok, so the sysfs names of vendor/product are driver-dependent... All my usb
devices have idVendor/idProduct even though only one of them is "Reddo".

Tried to create the hook on Initialize(), still crashes on exit().

Haven't tried your patch, because as far as I know the driver claims it can
do QAM256, and even if that was disabled today it would take some time to
get into all linux distributions... Btw it even claims to support QAM256 on
the product package, but it still doesn't work. I guess that's the reason
they are so inexpensive here...


Teemu

2010/4/5 Klaus Schmidinger 

> On 05.04.2010 12:43, Teemu Rantanen wrote:
> > Hi,
> >
> > I tried also without delete cDeviceHook but it still crashed...
>
> Please try creating the cReddoDeviceHook in
> cPluginDisableReddoQAM256::Initialize(),
> as suggested in PLUGINS.html.
>
> > Well, the fixes are basically available in the plugin, as I copied the
> > probe method (and modified slightly to suit the plugin). Those are:
> > - The sysfs filenames are idVendor (subsystem_vendor) and idProduct
> > (subsystem_device)
>
> This is what I get here:
>
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/subsystem_*
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
>
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/id*
> ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such file or
> directory
>
> Maybe a bug in the driver?
>
> > - You need to set strtoul() base as 16 as the files don't have 0x in
> > front of the hex
>
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> 0x
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
> 0x13c2
>
> Maybe the "reddo" driver behaves differently than the FuSi driver?
>
> > What about making this an utility method in VDR? Give device file name
> > and return id...
>
> Will do.
>
>
> Have you tried whether it works with my patch?
> In that case you wouldn't even need the whole plugin.
>
> Klaus
>
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] vdr-sudoku-0.3.5

[Thomas Günther]

Hi!

This is the first release of the VDR Sudoku plug-in from
http://projects.vdr-developer.org.

New development site:
  http://projects.vdr-developer.org/projects/show/plg-sudoku

Downloads:
  http://projects.vdr-developer.org/projects/list_files/plg-sudoku

Git-Web:
   http://projects.vdr-developer.org/git/?p=vdr-plugin-sudoku.git

Anonymous Git-access :
   git://projects.vdr-developer.org/vdr-plugin-sudoku.git

Changes since version 0.3.4:
- Moved to http://projects.vdr-developer.org/projects/show/plg-sudoku.
- Changed repository from subversion to git.
- Removed subversion keywords ($Id).
- Added support for VDR >= 1.7.13 (Make.global).
- Added method Pos::interacts_with.
- Removed compatibility to VDR < 1.6.0.
- Converted documentation and source files to UTF-8.
- Added unit tests.
- Fixed segfault in History::current.
- Fixed null pointer handling in History::add.
- Updated url and email of the VDR project to tvdr.de.
- Updated Doxyfile to doxygen version 1.6.3.

This plug-in generates Number Place puzzles, so called Sudokus, and let
you solve it.

A Sudoku puzzle consists of 9 x 9 cells subdivided into 9 regions with
3 x 3 cells. The rules are simple. There have to be the numbers from 1
to 9 in every row, column and region. In the beginning some numbers are
given. These cells are painted with cyan background color. The aim of
the puzzle is to find the missing numbers. There is only one solution
of a Sudoku puzzle.

See the project's homepage for details: http://toms-cafe.de/vdr/sudoku/

Tom

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 12:43, Teemu Rantanen wrote:
> Hi,
> 
> I tried also without delete cDeviceHook but it still crashed...

Please try creating the cReddoDeviceHook in 
cPluginDisableReddoQAM256::Initialize(),
as suggested in PLUGINS.html.

> Well, the fixes are basically available in the plugin, as I copied the
> probe method (and modified slightly to suit the plugin). Those are:
> - The sysfs filenames are idVendor (subsystem_vendor) and idProduct
> (subsystem_device)

This is what I get here:

r...@video:/home/kls/vdr/VDR > ls -l 
/sys/class/dvb/dvb0.frontend0/device/subsystem_*
-r--r--r-- 1 root root 4096 2010-04-05 16:25 
/sys/class/dvb/dvb0.frontend0/device/subsystem_device
-r--r--r-- 1 root root 4096 2010-04-05 16:25 
/sys/class/dvb/dvb0.frontend0/device/subsystem_vendor

r...@video:/home/kls/vdr/VDR > ls -l /sys/class/dvb/dvb0.frontend0/device/id*
ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such file or 
directory

Maybe a bug in the driver?

> - You need to set strtoul() base as 16 as the files don't have 0x in
> front of the hex

r...@video:/home/kls/vdr/VDR > cat 
/sys/class/dvb/dvb0.frontend0/device/subsystem_device
0x
r...@video:/home/kls/vdr/VDR > cat 
/sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
0x13c2

Maybe the "reddo" driver behaves differently than the FuSi driver?

> What about making this an utility method in VDR? Give device file name
> and return id...

Will do.


Have you tried whether it works with my patch?
In that case you wouldn't even need the whole plugin.

Klaus

> 2010/4/5 Klaus Schmidinger  >
> 
> From PLUGINS.html:
> 
>  A plugin that creates a derived cDeviceHook ...
>  shall not delete this object. It will be automatically deleted when the
>  program ends
> 
> I have added a similar note to device.h now.
> 
> > ...
> > - The sysfs probe code in full feature card plugin is buggy :-)
> 
> Would you mind posting a patch that fixes this?
> 
> Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Hi,

I tried also without delete cDeviceHook but it still crashed...

Well, the fixes are basically available in the plugin, as I copied the probe
method (and modified slightly to suit the plugin). Those are:
- The sysfs filenames are idVendor (subsystem_vendor) and idProduct
(subsystem_device)
- You need to set strtoul() base as 16 as the files don't have 0x in front
of the hex

What about making this an utility method in VDR? Give device file name and
return id...


Teemu

2010/4/5 Klaus Schmidinger 

> From PLUGINS.html:
>
>  A plugin that creates a derived cDeviceHook ...
>  shall not delete this object. It will be automatically deleted when the
>  program ends
>
> I have added a similar note to device.h now.
>
> > ...
> > - The sysfs probe code in full feature card plugin is buggy :-)
>
> Would you mind posting a patch that fixes this?
>
> Klaus
>
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 00:55, Teemu Rantanen wrote:
> Hi,
> 
> There's a new version of the patch implemented as a plugin. It seems to
> work, but there are few things to notice:
> 
> - Plugin does not cache which devices are Reddo devices, instead it
> probes sysfs every time QAM256 channel is being tuned into (on any
> device). It would be nice if cDeviceHook added a mechanism for a hook to
> store context for each device. Hooking into device probe (like full
> feature card plugin does) would be much nicer way, but it would
> interfere with other plugins which need the same mechanism.

The proper way of doing this is to check the modulation types
in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will
be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256
flag correctly, it needs to be fixed there.

> - VDR crashes at very late in exit() when clearing some list (most
> likely cDeviceHook list), but I couldn't find a way to avoid that

>From PLUGINS.html:

  A plugin that creates a derived cDeviceHook ...
  shall not delete this object. It will be automatically deleted when the
  program ends

I have added a similar note to device.h now.

> ...
> - The sysfs probe code in full feature card plugin is buggy :-)

Would you mind posting a patch that fixes this?

Klaus

> The plugin is available here:
> 
> http://tvr.dy.fi/vdr/vdr-disablereddoqam256-0.0.1.tgz
--- dvbdevice.c	2010/03/07 13:58:24	2.32
+++ dvbdevice.c	2010/04/04 11:15:25	2.33
@@ -889,7 +889,16 @@
   if (!cSource::IsSat(Channel->Source()))
  return DeviceHooksProvidesTransponder(Channel); // source is sufficient for non sat
   cDvbTransponderParameters dtp(Channel->Parameters());
-  if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
+  if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
+ dtp.Modulation() == QPSK && !(frontendInfo.caps & FE_CAN_QPSK) ||
+ dtp.Modulation() == QAM_16 && !(frontendInfo.caps & FE_CAN_QAM_16) ||
+ dtp.Modulation() == QAM_32 && !(frontendInfo.caps & FE_CAN_QAM_32) ||
+ dtp.Modulation() == QAM_64 && !(frontendInfo.caps & FE_CAN_QAM_64) ||
+ dtp.Modulation() == QAM_128 && !(frontendInfo.caps & FE_CAN_QAM_128) ||
+ dtp.Modulation() == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256) ||
+ dtp.Modulation() == QAM_AUTO && !(frontendInfo.caps & FE_CAN_QAM_AUTO) ||
+ dtp.Modulation() == VSB_8 && !(frontendInfo.caps & FE_CAN_8VSB) ||
+ dtp.Modulation() == VSB_16 && !(frontendInfo.caps & FE_CAN_16VSB))
  return false; // requires modulation system which frontend doesn't provide
   if (!Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
  return DeviceHooksProvidesTransponder(Channel);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] vdr-pvrinput

[L. Hanisch]

Hi all,

The plugin for integrating analog MPEG2 cards by Hauppauge (et al.) into the 
vdr has a new home.

http://projects.vdr-developer.org/projects/show/plg-pvrinput

It's adapted to the latest changes of vdr (>= 1.7.13). For older versions the plugin-param-patch is still needed. Take a 
look at the README to adjust your channels.conf to the matching syntax of your vdr.


http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/README
http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/HISTORY

I think, it's stable enough to be tested by you. :-)
Use the new home page for documenting bugs you encounter.

A short changelog:

- the generated TS now contains valid PAT, PMT and PCR packets so streaming with streamdev-server now works in TS mode. 
The used PIDs are the same as in the TS of cx18 cards, so the vdr will not alter them in mixed environments.

 vpid: 301+101=2 ; apid: 300 ; tpid: 305
- the Hauppauge HD PVR is now supported but uses different PIDs as the 
cx18/ivtv cards.
 vpid: 4113+4097=27 ; apid: 0;4352
- for radio channels no more video packets are sent. If you use a PVR350 as output device make sure you have a recent 
version of the pvr350-plugin which generates black video on its own.
- if you use a PVRUSB2 make sure you have the latest driver otherwise you can see occasionally no picture after a 
channel switch. The corresponding patch of pvrusb2 will be integrated in kernel 2.6.34.
- if you experience stuttering video on switching channels you can tweak some buffers with some parameters in the 
setup.conf (stop your vdr before editing, of course)


pvrinput.ReadBufferSizeKB = 64 // size of buffer for reader in KB (default: 
64 KB)
pvrinput.TsBufferSizeMB = 3// ring buffer size in MB (default: 3 MB)
pvrinput.TsBufferPrefillRatio = 0  // wait with delivering packets to vdr till 
buffer is filled up to x%

If the default values don't make you happy, please report working values for your setup. Please report also your used 
input and output devices.


The latest versions of w_pvrscan and wirbelscan supports the new vdr 1.7.13 syntax if you don't want to change your 
channels.conf by hand.


 http://wirbel.htpc-forum.de/w_pvrscan/index2.html
 http://wirbel.htpc-forum.de/wirbelscan/index2.html

Here's the announcement in the vdr-portal:
http://www.vdr-portal.de/board/thread.php?threadid=95389


Have fun!
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr