[vdr] Re: poisoned vdr plugins

["C.Y.M" <syphir@syphir.sytes.net>]

C.Y.M wrote:
> Klaus Schmidinger wrote:
>
> > C.Y.M wrote:
> >
> > > Klaus Schmidinger wrote:
> > >
> > > > C.Y.M wrote:
> > > >
> > > > > Anssi Hannula wrote:
> > > > >
> > > > > > Klaus Schmidinger wrote:
> > > > > >
> > > > > > > Now, does anybody have any idea why these changes would cause all
> > > > > > > the described malfunctions in plugins?
> > > > > > >
> > > > > > > Is everybody who has encountered problems with plugins *ABSOLUTELY*
> > > > > > > *POSITIVELY* *ONEHUNDRED PERCENT* sure that they did
> > > > > > >
> > > > > > >   make plugins-clean clean vdr plugins
> > > > > > >
> > > > > > > before running VDR with the modified thread.[hc]?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yes, I did.
> > > > > I also am positive I cleaned the src tree before building.  Take a 
> > > > > look at the log when vdr attempts to initialize a stream (when 
> > > > > using the new threading).  What is happening is that VDR is 
> > > > > creating  THREE receiver threads when it should only be creating 
> > > > > ONE.  If I go back to the previous threading model, only one 
> > > > > receiver thread is initialized and everything is fine.
> > > > >
> > > > > Dec  5 09:25:28 poseidon vdr[17733]: Streamdev: Accepted new client 
> > > > > (HTTP) 127.0.0.1:33032
> > > > > Dec  5 09:25:28 poseidon vdr[17733]: streamdev-server: Detaching 
> > > > > current receiver
> > > > > Dec  5 09:25:28 poseidon vdr[17781]: transfer thread started 
> > > > > (pid=17781, tid=245769)
> > > > > Dec  5 09:25:28 poseidon vdr[17782]: receiver on device 1 thread 
> > > > > started (pid=17782, tid=262154)
> > > > > Dec  5 09:25:28 poseidon vdr[17783]: receiver on device 1 thread 
> > > > > started (pid=17783, tid=278539)
> > > > > Dec  5 09:25:29 poseidon vdr[17784]: receiver on device 1 thread 
> > > > > started (pid=17784, tid=294924)
> > > > > Dec  5 09:25:29 poseidon vdr[17784]: buffer stats: 0 (0%) used
> > > > > Dec  5 09:25:29 poseidon vdr[17785]: Streamdev: Live streamer 
> > > > > thread started (pid=17785, tid=311309)
> > > > > Dec  5 09:25:29 poseidon vdr[17786]: TS buffer on device 1 thread 
> > > > > started (pid=17786, tid=327694)
> > > > > Dec  5 09:25:29 poseidon vdr[17787]: TS buffer on device 1 thread 
> > > > > started (pid=17787, tid=344079)
> > > > > Dec  5 09:25:29 poseidon vdr[17788]: TS buffer on device 1 thread 
> > > > > started (pid=17788, tid=360464)
> > > > > Dec  5 09:25:32 poseidon vdr[17788]: ERROR: driver buffer overflow 
> > > > > on device 1
> > > > > Dec  5 09:25:32 poseidon vdr[17784]: ERROR: skipped 74 bytes to 
> > > > > sync on TS packet on device 1
> > > > > Dec  5 09:25:32 poseidon vdr[17784]: ERROR: skipped 114 bytes to 
> > > > > sync on TS packet on device 1
> > > > > Dec  5 09:25:32 poseidon vdr[17784]: ERROR: skipped 1316 bytes to 
> > > > > sync on TS packet on device 1
> > > > > Dec  5 09:25:32 poseidon vdr[17786]: buffer usage: 90% (tid=262154)
> > > > > Dec  5 09:25:32 poseidon vdr[17788]: buffer usage: 100% (tid=294924)
> > > > > Dec  5 09:25:32 poseidon vdr[17787]: buffer usage: 40% (tid=294924)
> > > > > Dec  5 09:25:32 poseidon vdr[17782]: ERROR: skipped 272 bytes to 
> > > > > sync on TS packet on device 1
> > > >
> > > >
> > > >
> > > >
> > > > There is apparently a race condition when starting the receiver thread
> > > > in a cDevice (just reported shortly ago by Reinhard Nissl).
> > > >
> > > > I assume just reverting this change in thread.c should work as an 
> > > > immediate fix:
> > > >
> > > >  {
> > > >    if (!childTid) {
> > > >       parentTid = pthread_self();
> > > > -     pthread_create(&childTid, NULL, (void *(*) (void 
> > > > *))&StartThread, (void *)this);
> > > > -     pthread_detach(childTid); // auto-reap
> > > > -     pthread_setschedparam(childTid, SCHED_RR, 0);
> > > > +     pthread_t Tid;
> > > > +     pthread_create(&Tid, NULL, (void *(*) (void *))&StartThread, 
> > > > (void *)this);
> > > > +     pthread_detach(Tid); // auto-reap
> > > > +     pthread_setschedparam(Tid, SCHED_RR, 0);
> > > >       }
> > > >    return true; //XXX return value of pthread_create()???
> > > Thanks Klaus.  So we are keeping the latest thread.[ch] but changing 
> > > this function or are we keeping the original thread.c in vanilla 
> > > vdr-1.3.17 with this change?
> >
> >
> > For the moment I suggest to revert the above code.
> > I'll look into this further later, when I have finished my current work.
> OK, but I cant figure out which version of thread.c you are applying 
> that diff to?  That function in vanilla thread.c is surrounded by 
> Lock()/Unlock() (so thats not it).  And the new thread.c already uses 
> "Tid" instead of "childTid".
Klaus, I know you are busy with the new features in 1.3.18 and switching 
back and forth between different things can be very distracting. So, for 
now Ill just go with what works for me.  If I use vanilla 1.3.17 and 
apply this patch, it all seems ok.  Unless anyone objects or sees an 
obvious problem with it, Ill just go with the patch I have here (and not 
use the new thread.[ch] you posted).

Thanks,

--- vdr-1.3.17/thread.c.orig	2004-11-22 09:51:24.000000000 -0800
+++ vdr-1.3.17/thread.c	2004-11-25 18:52:22.000000000 -0800
@@ -240,15 +240,12 @@
 
 bool cThread::Start(void)
 {
-  Lock();
   if (!childTid) {
      parentTid = pthread_self();
-     pthread_t Tid;
-     pthread_create(&Tid, NULL, (void *(*) (void *))&StartThread, (void *)this);
-     pthread_detach(Tid); // auto-reap
-     pthread_setschedparam(Tid, SCHED_RR, 0);
+     pthread_create(&childTid, NULL, (void *(*) (void *))&StartThread, (void *)this);
+     pthread_detach(childTid); // auto-reap
+     pthread_setschedparam(childTid, SCHED_RR, 0);
      }
-  Unlock();
   return true; //XXX return value of pthread_create()???
 }
 
@@ -287,12 +284,10 @@
             }
         esyslog("ERROR: thread %ld won't end (waited %d seconds) - cancelling it...", childTid, WaitSeconds);
         }
-     Lock();
      if (childTid) {
         pthread_cancel(childTid);
         childTid = 0;
         }
-     Unlock();
      }
 }