[mythtv] Ticket #9773: Deadlocked BE
warpme
warpme at o2.pl
Fri Jun 3 13:47:56 UTC 2011
Hi,
According to 9792 it looks like this ticket is related to thesame problem (described in 9792).
After changing DB query cache optimization settings to:
"Do not cache results in or retrieve results from the query cache"
I do 2 weeks of extended tests:
-2 weeks with 50 rec per day (half of them with multirec + overlap + starting on thesame time on thesame mplex and 2 diferent mplexes)
-2 weeks with stress LiveTV by user as possible (at every FE after zap though all channels; 14mplexes; 45channels. This practically emulates mythtv as classical stb zapper)
-launch script for walking LiveTV on 14 mplexes staying with 15sec on every mplex. 55 iterations=780 channel changes.
Result: all OK. No single deadlock or hang or segfault.
After mythtv-rec2 code meger I'm really impressed with master reliability and excellent myth resiliency on environment failures (instability of my dvb system/provider and tuners/drivers).
Basically durring last 2 weeks I was trying to replicate all usage scenarios leading 0.24-fixes to famous "Myth_PROTO" error (and BE deadlock) and so far on master I wasn't able to reproduce any of them.
E.g. during 1st week of tests I had BE segfault which leaves tuners in state unable to tune. It was nice to see myth had failure only on LiveTV/Recording and rest be functions were fully usable. This is really good news as system seems to reaching now real industy grade resiliency.
Milion thx for recent code !
More information about the mythtv-dev
mailing list