mythjobqueue fails to transition from "stopping" to "finished" if new jobs enter queue

[anonymous]

This problem becomes apparent when several recordings are scheduled back-to-back and transcoding of one does not finish before the next recording is finished. If a transcoding job finishes while other transcoding jobs remain in the queue the state remains at "stopped" and prevents the .mpg and .tmp files associated with the job from being cleaned. This, in turn, can lead to excessive disk space usage and recordings being autodeleted before they should need to be. Please let me know what type of logs are needed to try to track this down.

[cpinkham]

I need to see some backend logs from when this happens, preferably running mythbackend as "mythbackend -v jobqueue".

[anonymous]

Strangely, with a whole bunch of jobs still in the queue, it seems to be transitioning to "finished" just fine. I will keep logging to see if this happens when a recording is in progress.

[anonymous]

Closing ticket for now. If the problem reoccurs, you can reopen and attach the logs.

[anonymous]

Errors appear to begin around 21:42

[anonymous]

I've reopened and attached logs from where the first repetition of jobs in the "Stopiing" state appears. That's at around 1/11/06 21:42. I'm not sure if it's related, but this is right after a mythfilldatabase run.

[anonymous]

I think I can give a slightly better description of this problem now. It appears that the jobqueue is leaving transcoding jobs in the "stopping" state and commflag jobs at 99% if new jobs enter the jobqueue while all available queue slots are in use.

[anonymous]

When this happens again, can you check to see if the mythtranscode process actually stopped or if it is actually still running? If the mythtranscode process actually finished and exitted, then myth_system() would have completed and then a message should have been printed in the logs showing the current status (which would have been one of Finished, Errored, or Aborted). Since you are seeing this still in a Stopping status, it sounds like mythtranscode isn't finishing or something. If you want to try a test, you can put a VERBOSE debug statement after the myth_system() call in jobqueue.cpp in the JobQueue::DoTranscodeThread?() method.

I don't think this has anything to do with new jobs being scheduled, I don't see anything that indicates that in your logs.

[cpinkham]

Marking this as 0.20 milestone. If the JobQueue? or mythtranscode were really broken like this, then it would be affecting a large number of people and no one else seems to be experiencing this issue. If you are, please post a message to the -devel list and I'll look into it more.

[anonymous]

I thought I had this licked after I was able to add another machine running mythjobqueue, but I've noticed it again the last two days. mythtranscode has finished and only the running instance appears via "ps aux | grep myth". I'll try adding a VERBOSE statement and see what happens. Interestingly, yesterday it appeared when a half hour recording and a one hour recording were started at the same time (the half hour recording stuck in the stopping state) and today with two one hour recordings, one ending a half hour before the other, the first one is stuck in the stopping state.

[cpinkham]

Marking this as works for me again since there's no update from the poster in almost 5 weeks. I've been unable to reproduce this even once and I record quite a bit (even more during the Olympics (TM)).