FreeBSD Terratec Cinergy Piranha DVB driver updated
ganael.laplanche at martymac.com
Thu Oct 8 06:34:49 UTC 2009
On Wed, 7 Oct 2009 12:29:11 +0200 (CEST), Joerg Pulz wrote
> I own a Hauppauge WinTV MiniStick (Model 1295 usb_vid 0x2040 usb_prod
> 0x5500) and i'm using your driver together with the firmware from
> successfully on FreeBSD-8.0-RC1.
I'm glad to read the driver works with your hardware :)
> I've patched the mplayer port to support DVB input and this is working for
> the initial tuned channel as well (mplayer dvb://"Channel Name") but as
> soon as i hit the "h" or "k" key to switch interactively to another
> channel directly with mplayer, i get an error from mplayer and the video
> output freezes.
Unfortunately, I have never tried the driver with mplayer's DVB module. Are
you using a channels.conf (~/.mplayer/channels.conf.ter) file to tell mplayer
which PIDs has to be set on a given frequency ?
Also, do you know if new PIDs has been successfully sent to the USB key once you
have hit the zapping keys ? Has the USB key started to stream data on the new
channel ? To check that, you can build the driver with 'make debug' and tune the
debug sysctl to 0xfdff. Be careful, logging will be *very* verbose :p
> I've also tried a patched version of the famous VDR
> (http://www.cadsoft.de/people/kls/vdr/) togehter with my device and your
> driver and it is working for the initial tuned channel as well. But after
> some minutes i get a lot of demux0.* devices (from 0 to 15) and a message
> that no more filters are available.
> Interactive channel switching is not working here too and in the worst case
> the whole machine freezes.
> Could the problem be the cloning of the demux0 device? IIRC in Linux there
> is only one /dev/dvb/adapter0/demux0 device but i may be wrong here. Most
> probably the applications (mplayer and VDR) are not aware of the demux0
> device cloning and stumble over it, but i'm not sure about this.
You are right, demux handling is done in a different way on FreeBSD. demux0
does not really exist and a demux0.n device clone is created each time a
lookup is performed on the master demux0 device filename (try to
'ls /dev/dvb/adapter0/demux0', a new clone will be created).
An application opening the demux0 device is *not* aware of
the underlying cloning mechanism. It thinks it has just opened the demux0 device
and is working with it, while in fact it is working with the last created clone.
Each close() will then destroy the clone. If the file descriptor
is not closed, then the demux0.n device clone remains created, leaving less
clones available in the pool.
Maybe the defaut MAX_FILTERS value (16) is too low for your application ?
You can try to increase it and see how it goes. This macro is defined in the
I'll try to have a look at VDR to see if I can reproduce the problem.
> I also tried xine from ports but i had no success. It's always reporting
> that "there is no handler for MRL dvb://"
Strange, it works for me (though I have not tried zapping once xine is started).
Have you copied your channels.conf file to ~/.xine/channels.conf ?
ganael.laplanche at martymac.org
More information about the freebsd-multimedia