Klaus Schmidinger wrote:
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".C.Y.M wrote:Klaus Schmidinger wrote: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?C.Y.M wrote:Anssi Hannula wrote: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.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.
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()???
For the moment I suggest to revert the above code. I'll look into this further later, when I have finished my current work.