Problem with transfer mode, xine plugin and ActualDevice

  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.