Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#11547 closed Bug Report - General (Works for me)

mytharchivehelper exit status unreliable

Reported by: J.Pilk@… Owned by:
Priority: minor Milestone: unknown
Component: Plugin - MythArchive Version: 0.26-fixes
Severity: medium Keywords: mytharchivehelper
Cc: Ticket locked: no

Description usually tests the exit status after calls to mytharchivehelper, and in some cases a non-zero value is treated as a fatal error. DVD creation stops.

A value of 2 is a special case.

Since the most recent revisions I have sometimes seen return values of 11 and 34, which can apparently be ignored. If the failed job is restarted it will usually run to completion. Feels like an uninitialised value.

Change History (3)

comment:1 Changed 8 years ago by J.Pilk@…

This may have gone away. It often caused a failure exit but a second or third attempt at DVD creation would usually succeed. I'm still running the same MythTV build from rpmfusion, but now in F18, and don't remember seeing a status failure for some days. Recent DVDs have a full complement of chapter thumbnail videos, too; earlier, several (out of 8) were often blank after a bad exit status.

I have no idea if there is a credible link here, but I've recently taken steps to undo a tangle of old hostnames that were affecting Storage Group definitions; rather like this:

comment:2 Changed 8 years ago by paulh

Component: MythTV - GeneralPlugin - MythArchive
Resolution: Works for me
Status: newclosed

You can't just ignore the return codes from mytharchivehelper they tell the script if something went wrong. Most of the commands return 0 for success or 1 for an error.

I'd need to know what parameters were passed to mytharchivhelper when it failed and what the exitcode was to help any further. I think 11 would be a segfault in which case a bt would be required. No idea what 34 would be possibly an abort which would also require a bt.

comment:3 Changed 8 years ago by J.Pilk@…

I would normally agree that status codes shouldn't be ignored; in practice the outcome then is that the whole process fails with no workaround other than actually fixing the real or illusory fault. I have often found that declaring and accepting a 'non-fatal error' has allowed the creation of a DVD with no obvious defect. Anyway, I haven't seen this one during the past week or so; maybe it was a system problem.

Note: See TracTickets for help on using tickets.