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 add
On 4 April 2010 03:37, Georg Acher wrote:
> On Sun, Apr 04, 2010 at 12:35:04AM +0200, Udo Richter wrote:
>> Am 03.04.2010 21:17, schrieb Teemu Rantanen:
>> > now that I've moved from pci dvb-c cards to usb dvb-c cards, I started
>> > to think what happens if dvb-devices are inserted/ejected when v
On 3 April 2010 21:17, Teemu Rantanen wrote:
> Hi,
> now that I've moved from pci dvb-c cards to usb dvb-c cards, I started to
> think what happens if dvb-devices are inserted/ejected when vdr is running.
> I haven't actually tried what happens, but it looks like hotswapping isn't
> supported? I g
Yes, the file is ff_audio_decoder.c
You must put the line
this->context->request_channels = 2;
after
this->context->codec_tag = _x_stream_info_get(this->stream,
XINE_STREAM_INFO_AUDIO_FOURCC);
Jose Alberto
El Sábado, 27 de Marzo de 2010, zaverel escribió:
> Is ff_audio_decoder.c to patch ?
>
On Sun, Apr 04, 2010 at 10:54:02AM +0200, Udo Richter wrote:
> How did you solve the case that a device disappears while being used? If
> this happens for a recording, then VDR would terminate with a VDSB, or?
> Do you silently switch the device to another resource?
As long as the device is used
Am 04.04.2010 03:37, schrieb Georg Acher:
> It is now solved by the mcli plugin by allocating all (16) devices at
> startup. When the various Provides*-methods are called for tuning, the
> plugin searches in its internal resource database for an appropriate tuner
> and assigns it to the vdr-device.