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.