C.Y.M wrote:
Klaus Schmidinger wrote:
C.Y.M wrote:
Rainer Zocholl wrote:
It starts with the end of a recording.
The life stream went black and stays black.
The only applied patch is the LNB_sharing patch.
Now VDR segfaults in the start phase.
I assume that something ist not OK with the thread locking in the
shut down phase.
For example: the TSbuffer resources is deleted while a thread is
still
using it. (Have not analyzed if it is so, it's only an example)
Yes, this is definitly a problem with the new threading of
vdr-1.3.17. I have confirmed it with many others reporting the same
error as you. If you search back on the list, you will find a patch
I posted for 1.3.17 to revert back to the previous threading model
of 1.3.16 (btw, the new thread.[ch] will not help).
You really should try to fix the plugins that are having trouble.
Just reverting back to the 1.3.16 thread handling won't do you
any good in the long run. Since VDR itself runs just fine with the
files at ftp://ftp.cadsoft.de/vdr/Developer/thread.[hc] I'm not
going to change anything in that area until somebody shows me proof
of a bug.
Klaus, I would be happy to assist you in debugging the new threading.
If there is anything I can do, please let me know.
Regards,
C.Y.M.
Well, run VDR without any plugin to see whether it runs stable.
Then load one plugin after the other to find out which one causes
problems. Once you have identified a plugin that causes trouble,
you'll need to find out why it does.
Streamdev, Xine, and the LNB Sharing patch seem to be culprits so far.
If anyone finds another conflicting plugin, please let me know. Symptoms
are buffer overflows during operation and segfaults when stopping vdr.
VDR will appear to run (sometimes) which seems like a race condition to
me. Streamdev sometimes works without any errors then the next time it
doesnt. As soon as I attempt to change the channel, the screen goes
black and VDR segfaults. There has also been reported ARM crashes
during recording (without even executing one of these conflicting
plugins) perhaps related to using the xine softdevice now that I think
about it.