Project

General

Profile

News

pvrinput uses udev-interface of dynamite (6 comments)

Added by lhanisch about 13 years ago

dynamite now offers a service-interface for adding udev-filters to "add"-actions. If you plug in a pvrusb2 udev will generate an event in the video4linux-subsystem with the devicepath the driver created.
pvrinput just has to call the dynamite-service in its initialization:

AddUdevMonitor video4linux /dev/video

If the udev-monitor of dynamite grabs an event of the subsystem "video4linux" whose devnode starts with "/dev/video" it tries to attach this device by calling all "cDynamicDeviceProbe"s. And since pvrinput has registered a handler it will create a cPvrDevice for this video-device. VoilĂ !

What I have to test now is what happens if an ivtv-device is added - there would be more than one /dev/video and only the first should be used. I think, cPvrDevice::Probe should only react on device-numbers less than 16, what do you think?

attach/detach pvrinput-devices while vdr is running (7 comments)

Added by lhanisch over 13 years ago

The dynamite-plugin is a helper plugin which allows to dynamically attach and detach devices while vdr is running.
This is useful for slow USB-DVB-Sticks or other hardware which would delay the start of vdr and increase boot time.

pvrinput supports some USB hardware (e.g. the "HD PVR" and "PVR USB2" from Hauppauge). These (and of course the PCI cards as well) can now be attached/detached from vdr without stopping it. Just send the right SVDRP command:

svdrpsend plug dynamite attd /dev/video0

or

svdrpsend plug dynamite detd /dev/video0

If you don't use dynamite or have an unpatched vdr - don't worry - pvrinput will behave as it always has... :-)

The source for the dynamite plugin is available at the VDR Portal:
http://vdrportal.de/board/thread.php?threadid=102903

dynamite compatible pvrinput:
http://projects.vdr-developer.org/attachments/download/471/vdr-pvrinput-2011-01-20.tgz

vdr 1.7.13 obsoletes pluginparam-patch (42 comments)

Added by lhanisch about 14 years ago

If you are using vdr 1.7.13 or the 'bleeding edge' pvrinput-plugin, you have to make some changes to your channels.conf.

old channels.conf entry:

RTL:217250:PVRINPUT|TV:P:0:301+101:300:305:0:12003:1:1089:0

With 1.7.13 the source 'V' was assigned to pvrinput so we don't have to share the source parameters with other plugins like iptv etc. You must omit the "PVRINPUT|" prefix.
RTL:217250:TV:V:0:301+101:300:305:0:1:1:12003:0

And there's another change in pvrinput. Now we do proper section handling, so filters of vdr and other plugins (e.g. streamdev-server) are able to catch the PAT and PMT of the stream. TS-mode-streaming is working now... :-)

So even with vdr 1.7.12 or older you need to change it to:

RTL:217250:PVRINPUT|TV:P:0:301+101:300:305:0:1:1:12003:0

The reason: The SID of the channel has to match the program number of the PMT. Since the hdpvr and cx18 driven cards produce a TS on their own with a program number of 1, we decided to set the same SID at the generated PMT of ivtv based cards. Till now the w_pvrscan resp. wirbelscan-plugin sets a value related to the frequency in the SID field. This will work in environments with only ivtv cards but won't if you have a mix of ivtv and cx18. vdr will constantly change the PIDs according to the card which deliveres the channel.

On the other hand the combination of SID, NID and TID has to be distinct so the vdr can distinguish the channels. All you have to do is, move the old SID to the TID and set the SID to 1.

If you receive epg-data with tvmovie2vdr or the tvm2vdr-plugin make sure you update the channel map.

    (1-3/3)

    Also available in: Atom