[vdr] Memory access error while attach player?

[Patrick Fischer]

now I have written a workaround and it works.

I have written cMyReplayControl inherit from cReplayControl.


//---------------cIvvonReplayControl.h-------------------
class cIvvonReplayControl: public cReplayControl{
public:
        cIvvonReplayControl();
        virtual ~cIvvonReplayControl();
        eOSState ProcessKey(eKeys Key);       
};
//---------------cIvvonReplayControl.c-------------------
cMyReplayControl::cMyReplayControl():cReplayControl(){}

cMyReplayControl::~cMyReplayControl(){}

eOSState cMyReplayControl::ProcessKey(eKeys Key){
    if(!cReplayControl::Active()){
        dsyslog("ReplayControl is not Active. Use workaround1");
        cControl::Attach();       
    }
    eOSState tmp = cReplayControl::ProcessKey(Key);
    if(tmp==osEnd){
        dsyslog("ReplayControl is not Active. Use workaround2");
        cControl::Attach();
        tmp = cReplayControl::ProcessKey(Key);
    }
    if(tmp==osEnd){
        //only for debug
        dsyslog("cMyPlayerControl is still not attached and Active!!!!!");
        exit(0);   
    }
    return tmp;
}


I think it would be nice if we have a function(e.g. main) in each 
Plugin, that will be called from the mail loop each time.
In my case I could do this:
-set an bool from the thread that signal that the thread want to attach 
a player
-on the next call of the Plugin main function, my Plugin can check this 
bool and attach the player

I know that this will have side effects if the work in the plugins main 
function takes to long time. But this would be a nice way to sync 
threads with the main thread.

Patrick

Patrick Fischer schrieb:

> I have implemanded a mutex but the problem might be the same.
>
> Now I know the real problem.
>
> If I make a cControl::Launch(new cReplayControl); from a thread, you 
> told me that the main loop will Attach it. The Attach call is at the 
> beginning of the main loop.
> But if my Thread will call the Launch(..) only a short time after the 
> main loop has called the Attach(..), then the line 814 will call 
> ProcessKey from my cReplayControl. But if this cReplayControl is not 
> activ it will return osEnd and the main loop will call 
> cControl::Shutdown() my ReplayControl.
>
> Its an vicious circle :-(
> I can defuse it by calling cControl::Attach(); directly after 
> cControl::Launch(new cReplayControl); but this will not fix the problem.
>
> Tomorrow I will test if it works better if I inherit from 
> cReplayControl and don't return osEnd from calling ProcessKey().
>
> Cu
> Patrick
>
> Klaus Schmidinger schrieb:
>
>> Patrick Fischer wrote:
>>
>>>
>>>> You could remove the
>>>>
>>>>   cControl::Attach();
>>>>
>>>> call from your code (this is done in VDR's main loop in the
>>>> foreground thread) and add a mutex to cControl that guards
>>>> all calls to its member functions.
>>>>
>>>> Klaus
>>>
>>>
>>>
>>>
>>> What did you mean by "add"? I can't find a mutex in cControl.
>>
>>
>>
>> That's why I wrote "add" ;-)
>>
>>> Did you mean this?: (myMutex is a private cMutex from cMyPlayer)
>>>
>>> bool cMyPlayer::start(const char *path)
>>> {
>>>    cMutexLock MutexLock(&myMutex);      cRecording *recording = 
>>> Recordings.GetByName(path);
>>>    if (recording) {
>>>        cReplayControl::SetRecording(NULL, NULL);
>>>        cControl::Shutdown();
>>>        cResumeFile resume(recording->FileName());
>>>        resume.Delete();
>>>        cReplayControl::SetRecording(recording->FileName(), 
>>> recording->Title());
>>>        cControl::Launch(new cReplayControl);
>>>       // cControl::Attach(); //will done in the foreground thread
>>>        return true;
>>>    }else
>>>        return false;
>>> }
>>>
>>> In this case I only protect my own function. This will protect that 
>>> my thread can't recall start until it is done. Thats OK.
>>> Or did you mean that I need to patch the cControl by adding a Mutex 
>>> and protect all memberfunctions?
>>
>>
>>
>> Yes.
>>
>>> If I do so, will you add this patch to
>>> upcoming vdr versions? I don't want to patch all upcoming versions.
>>
>>
>>
>> If it works, yes.
>>
>> Klaus
>>
>> _______________________________________________
>> vdr mailing list
>> vdr at linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>
>
>
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>