Re: [vdr] Updated patch for vdr 1.7.22 in gentoo
On 03/01/2012 00:16, René wrote: On 03.01.2012 1:00 , Marc wrote: I don't have livebuffer in the menu. I activated the livebuffer by setting 'Pause key handling' to 'Timeshit'. Ok, is this something you have to manually edit in setup.conf? I don't have this option in the setup for recording.. Here i have only "pause live video", "do not pause live video" and "confirm pause live video".. It's probably because the patch is not applied, this option is added in the menu by it. You should have something like this when you compile vdr : ... * Unifdef sources ... [ ok ] * Applying local patches * Applying livebuffer-1.7.22.patch ... [ ok ] >>> Source prepared. ... Do you btw have to press pause to activate livebuffer, or can you just press rewind in the middle of playback? In the 1.6.x patch i don't have to press pause, i just press rewind.. I checked and yes, the patch still works like this. I can either use pause or rewind. Regards, René ___ 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] Rotor / Rotor-NG not working with latest VDR
On Sun, Dec 25, 2011 at 12:32 PM, ilia mane wrote: > Thank you Lars Hanisch it work for me.I just disable the dynamite plugin in > /etc/vdr/plugins/order.conf and the rotorng plugin work now. Just returned from the Christmas period, merry Christmas all! Then it looks like dynamite is the problem. Rotorng has a setup option for the satellite adapter that is connected to the rotor and normally it is set to 1,2,3 etc depending on the allocated adapter # at boot up. I guess this might now change with this virtual proxy for the adapter that is setup by dynamite? How is this handled, for example by femon or other plugins that need to communicate with the required physical adapter #? Thanks, Morfsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Updated patch for vdr 1.7.22 in gentoo
On 03.01.2012 10:29 , Marc wrote: * Unifdef sources ... [ ok ] * Applying local patches * Applying livebuffer-1.7.22.patch ... [ ok ] >>> Source prepared. Ok, then i have something fishy going on.. I have the livebufer in the menu, but then as you said most likely it's not applied correctly. I have to check the build-log if it complains something I checked and yes, the patch still works like this. I can either use pause or rewind. Great! :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Rotor / Rotor-NG not working with latest VDR
Hi,
Am 03.01.2012 11:43, schrieb Morfsta:
On Sun, Dec 25, 2011 at 12:32 PM, ilia mane wrote:
Thank you Lars Hanisch it work for me.I just disable the dynamite plugin in
/etc/vdr/plugins/order.conf and the rotorng plugin work now.
Just returned from the Christmas period, merry Christmas all!
Then it looks like dynamite is the problem. Rotorng has a setup option
for the satellite adapter that is connected to the rotor and normally
it is set to 1,2,3 etc depending on the allocated adapter # at boot
up. I guess this might now change with this virtual proxy for the
adapter that is setup by dynamite?
How is this handled, for example by femon or other plugins that need
to communicate with the required physical adapter #?
A quick grep in the femon sources shows me, that femon opens the frontend on its own. It will use the device's
"CardIndex()" as adapter number and will always open frontend0 (which will break even without dynamite on
multi-frontend-devices). For now dynamite will not guarantee that adpater #0 will have cardindex #0. If you want to
correlate the shown info to your devices, you'll have to look in the dynamite settings -> list all devices (or use the
SVDRP command "plug dynamite lstd").
It is possible to assign adapters to specific cardindices with the udev environment variable "dynamite_cardindex". But
one should use this on all adapters since the logic behind this is not so smart to first attach all devices with a set
cardindex and then all others.
I think it might be a good idea if dynamite will use the adapter number as a
hint for the cardindex.
I can imagine these things, that will lead to problems with dynamite:
- new virtual functions in cDevice or cDvbDevice: they have to be patched into dynamite's cDynamicDevice so it can
forward calls to its subdevice
- new non-virtual member functions in cDevice/cDvbDevice: for every method it has to be evaluated if the "parent's" or
"subdevice's" value has to be return (e.g. CardIndex, DeviceNumber, PatPmtParser, CamSlot etc.). It depends from where
and in which context these functions are called (has the caller a pointer to a subdevice like a call from within
cDvbDevice - has it a pointer from the cDevice::device array which will point to the parent device etc.).
- dynamic_cast (like it is used with the new device bonding feature): plugins won't get the "real"
device like cDvbDevice or similar. It will always be a cDynamicDevice.
rotorng adds one new virtual function to cDevice: SendDiseqcCmd
In yavdr this is included in the dynamite plugin (as "nm -d
/usr/lib/vdr/plugins/libvdr-dynamite.so.1.7.22" confirms).
When I look at the cDevice-functions rotorng is using I don't see anything which will lead to problems. Maybe it's
just a cardindex mismatch?
There are two ways to test this (after reactivating dynamite with an * in /etc/vdr/plugins/order.conf, which will
ensure that dynamite loads as the last plugin):
1. The "fast" way: Detach all devices from vdr with "svdrpsend plug dynamite
dtad"
Reattach them in the "right" order with "svdrpsend plug dynamite attd
/dev/dvb/adapter0/frontend0" etc.
2. The other way: Add a udev rule to your system that will assign every
frontend a cardindex, it may look like:
ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend",
ENV{dynamite_cardindex}="%E{DVB_ADAPTER_NUM}"
Reload the modules and restart vdr. This assumes you have no card with
multiple frontends.
Thanks,
Lars.
Thanks,
Morfsta
___
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] Crystalhd support and help
Hello I got a BCM70015 card working with vdr-xineliboutput by using the crystalhd plugin for xine here : http://crystalhd.svn.sourceforge.net/viewvc/crystalhd/branches/xine-plugin-crystalhd-ffmpeg/ The install procedure is thoroughly explained in the README. Keep in mind you should compile it towards xine-lib 1.2, which is out since a few days. It works reliably with h.264 dvb-t streams on my D945GSEJT motherboard with not more than 30% CPU usage. The media player also works, even if it gets somewhat unresponsive when you try to fast forward or rewind some HD files. I don't know if the vaapi driver for crystalhd is usable too. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Crystalhd support and help
On 4 January 2012 08:54, Damien Bally wrote: > I got a BCM70015 card working with vdr-xineliboutput by using the crystalhd > plugin for xine here : > > http://crystalhd.svn.sourceforge.net/viewvc/crystalhd/branches/xine-plugin-crystalhd-ffmpeg/ > > It works reliably with h.264 dvb-t streams on my D945GSEJT motherboard with > not more than 30% CPU usage. The media player also works, even if it gets > somewhat unresponsive when you try to fast forward or rewind some HD files. What does interlaced material look like? I'd assume you could use tvtime output plugins to do deinterlacing, although it would increase cpu usage? -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Updated patch for vdr 1.7.22 in gentoo
On 03.01.2012 16:12 , René wrote: On 03.01.2012 10:29 , Marc wrote: * Unifdef sources ... [ ok ] * Applying local patches * Applying livebuffer-1.7.22.patch ... [ ok ] >>> Source prepared. Ok, then i have something fishy going on.. I have the livebufer in the menu, but then as you said most likely it's not applied correctly. I have to check the build-log if it complains something Marc, The patch is now found by the ebuild, but it wont' get applied. The problem is just that it does not work. For some reasons it get's errors like "can't find file to patch"... Here is the failed .out-file http://pastebin.com/MufLFssk My patchdir is /etc/vdr_patch_dir and this patch is here: /etc/vdr_patch_dir/1.7.22/livebuffer-1.7.22.patch What could here be wrong? René ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Crystalhd support and help
Le 04/01/2012 00:17, Torgeir Veimo a écrit : What does interlaced material look like? I'd assume you could use tvtime output plugins to do deinterlacing, although it would increase cpu usage? For the moment, my new vdr box is not in real operation, I should first build a vga2scart to connect it to my old CRT TV set. I will use frame rate control as described here : http://frc.easy-vdr.de/ (Anyway I know that the visual improvement between SD and HD content will be very tiny on a CRT display.) I see no image flaws on my PC monitor, though not using any deinterlacing filters. Only MPEG-2 material from SD channels, which seem to be decoded by software, not by the chip, look interlaced. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
