[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