[mythtv] Unresponsive BE

Warpme warpme at o2.pl
Wed Sep 8 19:33:01 UTC 2010


  Paul,

Unfortunately I'm not using slave BE - so I can't comment.

I think ticket 8526 is related to logic handling non-default states 
between MBE<->SBE.
In SBE-MBE setups, disconnected SBE shouldn't block basic functions of 
MBE. I can imagine degraded MBE functionality (e.g. scheduler) - but at 
least basic functions should work. Generally I think disconnected SBE 
should have impact only on relevant to SBE features.
Recording functions are in this category. Playback - not.

My issue have much heavier class. BE is not responding to any requests 
(FE, Web, etc). For user this if functionally equivalent to lock-up.
For me lock-up is most heavy type of system failure (only burning or 
electrical hazard is worse IMHO).

Sure - in my case root cause isn't myth related - it is hw/driver related.
Despite that, myth is so mature and advanced system, that advancement 
metric start move from nifty-ifty features to resilience/stability/ease 
of use.

Ideally for me will be appliance level of resilience/stability/ease of use.
Personally - way of approaching my issue will be good estimator how 
close we are to server world.

I want to underline: I absolutely don't want to push devs for quick 
resolution.
I fully understand they have priorities, plans and schedules. Quality 
software should not have half-solved parts...but critical nature of 
critical issues usually brake this with simple justification: having 
excellent software with some critical issues is worse than having good 
software with much less critical issues (as number of dissatisfied, by 
bad quality, developers is much less than number of dissatisfied, by 
critical issues, users).

br
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warpme.vcf
Type: text/x-vcard
Size: 83 bytes
Desc: not available
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100908/ed132e4d/attachment.vcf>


More information about the mythtv-dev mailing list