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.
Bye
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.
En/na Reinhard Nissl ha escrit:
Hi,
Luca Olivetti wrote:
[....]
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.
no ;-) I find this feature really handy
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?
I tried that and there's no such problem (I used the dvb setup menu, I couldn't find the SVDRP command to switch the primary device). The difference is that when I do that through the menu vdr will show a message telling me that it's switching the primary interface, while I see no such message when xine automatically changes over (btw, now with xine-plugin 0.7.6 and vdr 1.3.35)
Bye
Hi,
Luca Olivetti wrote:
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?
I tried that and there's no such problem (I used the dvb setup menu, I couldn't find the SVDRP command to switch the primary device). The difference is that when I do that through the menu vdr will show a message telling me that it's switching the primary interface, while I see no such message when xine automatically changes over (btw, now with xine-plugin 0.7.6 and vdr 1.3.35)
Please test the attached patch.
Bye.
En/na Reinhard Nissl ha escrit:
Please test the attached patch.
It doesn't work (i.e. it works like without the patch, only there's a message telling that the primary device is changing).
Bye
En/na Luca Olivetti ha escrit:
En/na Reinhard Nissl ha escrit:
Please test the attached patch.
It doesn't work (i.e. it works like without the patch, only there's a message telling that the primary device is changing).
Correction: it works when switching to xine, it doesn't when switching *from* xine (you forgot the cControl::Shutdown() in the other direction). BTW, shouldn't the "originalPrimaryDevice = primaryDevice" be inside the "if (this != primaryDevice)" ?
Bye
Hi,
Luca Olivetti wrote:
Please test the attached patch.
It doesn't work (i.e. it works like without the patch, only there's a message telling that the primary device is changing).
Correction: it works when switching to xine, it doesn't when switching *from* xine (you forgot the cControl::Shutdown() in the other direction). BTW, shouldn't the "originalPrimaryDevice = primaryDevice" be inside the "if (this != primaryDevice)" ?
So the revised patch (see attachment) should work now as expected, isn't it?
Bye.
En/na Reinhard Nissl ha escrit:
So the revised patch (see attachment) should work now as expected, isn't it?
I'm really puzzled (since now the plugin is doing exactly the same as vdr) but it doesn't :-(
Bye
En/na Luca Olivetti ha escrit:
En/na Reinhard Nissl ha escrit:
So the revised patch (see attachment) should work now as expected, isn't it?
I'm really puzzled (since now the plugin is doing exactly the same as vdr) but it doesn't :-(
Could it be that OnClientConnect is asyncrhonous wrt the main vdr thread and SetPrimaryDevice should be called only from the main thread (so that if it works or not is basically random?).
Bye
Hi,
Luca Olivetti wrote:
So the revised patch (see attachment) should work now as expected, isn't it?
I'm really puzzled (since now the plugin is doing exactly the same as vdr) but it doesn't :-(
Could it be that OnClientConnect is asyncrhonous wrt the main vdr thread and SetPrimaryDevice should be called only from the main thread (so that if it works or not is basically random?).
Well yes, this could be a problem. OnClientConnect() is driven by an own thread in xineLib.c.
Bye.
En/na Reinhard Nissl ha escrit:
Hi,
Luca Olivetti wrote:
So the revised patch (see attachment) should work now as expected, isn't it?
I'm really puzzled (since now the plugin is doing exactly the same as vdr) but it doesn't :-(
Could it be that OnClientConnect is asyncrhonous wrt the main vdr thread and SetPrimaryDevice should be called only from the main thread (so that if it works or not is basically random?).
Well yes, this could be a problem. OnClientConnect() is driven by an own thread in xineLib.c.
Well, juggling around the instructions (i.e., calling the cControl::Shutdown() after the Skins.Message or after the SetPrimaryDevice, having previously removed the call to cControl::Shutdown() in MakePrimaryDevice) sometimes it works, sometimes it doesn't, so it's most probably a timing issue. If so there's no easy way out. I can live with this problem, it seems ActualDevice it's only used by some plugins (e.g. femon).
Bye
Hi,
Luca Olivetti wrote:
Well, juggling around the instructions (i.e., calling the cControl::Shutdown() after the Skins.Message or after the SetPrimaryDevice, having previously removed the call to cControl::Shutdown() in MakePrimaryDevice) sometimes it works, sometimes it doesn't, so it's most probably a timing issue. If so there's no easy way out. I can live with this problem, it seems ActualDevice it's only used by some plugins (e.g. femon).
Please provide me a showcase with femon. I could hack vdr-xine for multiple devices and try to reproduce this problem here too.
Bye.
En/na Reinhard Nissl ha escrit:
Please provide me a showcase with femon. I could hack vdr-xine for multiple devices and try to reproduce this problem here too.
femon uses ActualDevice to open the frontend, if it cannot it will simply not show anything (that's how I spotted the problem, btw, and looking at syslog to see that there was a transfer thread stopping after the new one had started).
In femonosd.c, method cFemonOsd::Show:
asprintf(&dev, FRONTEND_DEVICE, cDevice::ActualDevice()->CardIndex(), 0); m_Frontend = open(dev, O_RDONLY | O_NONBLOCK);
I added right after that an
printf("frontend %s\n",dev);
to see what it's getting.
Grepping for ActualDevice I can see that it's also used in eitscan.c, actuator[*], streamdev, subtitles, ttxtsubs.
[*]I copied that part from rotor, so it's probably using ActualDevice too.
Bye.
En/na Reinhard Nissl ha escrit:
Please provide me a showcase with femon. I could hack vdr-xine for multiple devices and try to reproduce this problem here too.
Btw, this is the patch I'm using now (against original 0.7.6), and it seems to work, but I'm not sure it's due to simple luck or it is working by design (e.g. if I switch the order of cControl::Shutdown() and Skins.Message in the OnClientConnect handler it won't work).
Bye
Hi,
Luca Olivetti wrote:
Btw, this is the patch I'm using now (against original 0.7.6), and it seems to work, but I'm not sure it's due to simple luck or it is working by design (e.g. if I switch the order of cControl::Shutdown() and Skins.Message in the OnClientConnect handler it won't work).
As you wrote in a previous email: it's a threading issue.
Please try the attached patch against 0.7.6, which now uses VDR's main thread to switch the primary device.
Bye.
En/na Reinhard Nissl ha escrit:
Hi,
Luca Olivetti wrote:
Btw, this is the patch I'm using now (against original 0.7.6), and it seems to work, but I'm not sure it's due to simple luck or it is working by design (e.g. if I switch the order of cControl::Shutdown() and Skins.Message in the OnClientConnect handler it won't work).
As you wrote in a previous email: it's a threading issue.
Please try the attached patch against 0.7.6, which now uses VDR's main thread to switch the primary device.
It works, thanks.
Bye
-
Luca Olivetti -
Reinhard Nissl