[mythtv-users] everyday i have to make sure myth worked the day before

[Brian J. Murrell]

On 11-04-01 12:39 PM, Devin Heitmueller wrote:
> Indeed, these are often a challenge to debug since the
> developers usually cannot precisely reproduce the user's environment.

Yes, I full acknowledge this difficulty which is why I am aiming to at
least get a backtrace the next time it happens.

> And in those cases really the onus is on the user to come up with a
> sequence to reproduce or otherwise quantify the bug to sufficient
> detail to allow it to be fixed.

Yeah.  The kind of problem I am having though doesn't really have a
"reproducer" since it's likely some internal race or such.

> In 2011 we
> still don't have any comparable functionality in Myth (either in the
> main GUI or via some sort of email or other alerts).

When I first saw the new System Events functionality that went in I
immediately asked for a "missed recording" event:
http://www.mythtv.org/pipermail/mythtv-users/2010-May/288766.html

Seems like that would fill at least one aspect of your general request.

> Ask yourselves:  how many times have you sat down with some popcorn,
> turned on your MythTV box, hit play on a recording, and found out that
> there is a zero length file there?  Wouldn't it have been nice if Myth
> had proactively told you that much earlier?

And even better, didn't consider it a successful recording so put it
back into the schedule in case it was being shown again.

Indeed, one can keep a close eye and effect the same with Delete +
Rerecord and whatnot but sometimes the repeat showing is sufficiently
soon after the failed showing that one wouldn't reasonably get that
opportunity.

> Having a solution for the second problem makes the first class of
> problems much more bearable.

True enough.  I'm not sure it would help in my case though.  Will it be
noticed when something didn't record because of a deadlock?  I suppose a
run of the schedule after the deadlock situation is resolved (i.e. a
myth restart) where the recording was missed would just wind up
rescheduling it, if it's being shown again.  So that works.

If however the recording was in the process of being missed (i.e. a 60
minute program was supposed to be recorded at 8pm but was not being
recorded because of a bug and it is not yet 9pm) and the backend
restarts, it gets partially recorded and put into the database as
recorded.  That's just a general problem of starting the backend while
something was supposed to be getting recorded and I think the solution
there is to leave it on the disk and in the lineup but not consider it
recorded and allow a later showing to be recorded and dropped into it's
place (or as a substitute, delete the partial recording when the
rerecording is completed successfully).

b.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110401/7c74239c/attachment.bin