The backend does not detect when a transcoding job has died

[hdtv@…]

Every now and again the mythtranscode process will die - if it dies on a recording it is usually repeatable.

The problem is the backend still thinks there is a transcoding job in progress and will not start any new jobs.

Ideally the backend should detect that the process has died, mark it as failed, and move on to the next job.

A related issue is that the when the transcoding process has died it is not possible to delete the job in mythfrontend - the only options are to "stop" or "pause", neither of which do anything in this situation.

Workaround - deleting the recording will also delete the transcoding job and the backend will move on to the next job.

Running svn trunk 10407.

Nick

[cpinkham]

I need some more info on this one. Can you send me the mythbackend logs from when this happens? Since you say it is usually repeatable, run mythbackend with the "-v jobqueue" command line option and it should give some more useful debug info. Attach the logs starting at the point you can see mythtranscode running until the point where it looks like mythtranscode has died and myth isn't detecting it. Attach the log here and I'll take a look.

[Janne <janne-mythtv@…>]

If the myth_system call returns anything different than "MYTHSYSTEMEXITEXECL_ERROR", "MYTHSYSTEMEXITCMD_NOT_FOUND" or "TRANSCODE_EXIT_RESTART" and mythtrancode wasn't succesful the status isn't changed.

Easiest way to reproduce should be killing mythtranscode.

Attached patch fixes the problem.

[anonymous]

Messed this up yesterday, meant to set the milestone to 0.20 since we have a patch now.

[cpinkham]

(In [10621]) Apply Janne's patch to fix the JobQueue? where it would not handle the case where mythtranscode died instead of quitting with a proper exit code. This situation led to entries in the queue that could not be deleted except by deleting the actual recording itself.

Closes #2035.