Hi,
Luca Olivetti wrote:
> Well, I don't know where the problem actually lies (I guess the xine
> plugin), but:
>
> I'm using vdr with a dxr3 and the xine-newtork plugin (0.7.4, I know I
> should update it, but I couldn't spot anything related to this problem
> in HISTORY for 0.7.5 and 0.7.6).
> Normally the dxr3 is the primary device but when the xine plugin is in
> use it will switch itself as the primary. The problem is that right
> after the switch a new transfer thread starts *before* the previous one
> ends, so receiverDevice is left pointing to NULL, so that ActualDevice
> fails to report the correct device, until the next channel switch.
Hhm, you may want to disable this functionality in vdr-xine's setup
menu, but I don't think that this is the solution you are looking for.
Could you please proof the case, where this functionality is turned off
and you change the primary device in the ways which VDR offers, i. e.
setup menu respectively SVDRP interface?
Below is an excerpt of vdr-xine's code. I don't see here anything wrong
concerning SetPrimaryDevice(), but I have no possibilty to test this due
to the lack of primary devices (vdr-xine still cannot be run multiple
times). Maybe someone can enlighten me ;-)
void cXineDevice::OnClientConnect()
{
reshowCurrentOsd();
if (m_settings.LiveTV())
softStartTrigger = sstNormal;
if (m_settings.AutoPrimaryDevice())
{
cDevice *primaryDevice = cDevice::PrimaryDevice();
if (this != primaryDevice)
SetPrimaryDevice(1 + DeviceNumber());
originalPrimaryDevice = primaryDevice;
}
if (m_settings.ShallSwitchSkin())
switchSkin(true);
}
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
