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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr