[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