Opened 14 years ago

Closed 13 years ago

#996 closed defect (worksforme)

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

Reported by: anonymous Owned by: cpinkham
Priority: minor Milestone: 0.20
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (1)

jqerr.log.bz2 (48.9 KB) - added by anonymous 14 years ago.
Errors appear to begin around 21:42

Download all attachments as: .zip

Change History (11)

comment:1 Changed 14 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham

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

comment:2 Changed 14 years ago by 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.

comment:3 Changed 14 years ago by anonymous

Resolution: worksforme
Status: newclosed

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

Changed 14 years ago by anonymous

Attachment: jqerr.log.bz2 added

Errors appear to begin around 21:42

comment:4 Changed 14 years ago by anonymous

Resolution: worksforme
Status: closedreopened

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.

comment:5 Changed 14 years ago by anonymous

Summary: mythtrancode fails to transition from "stopping" to "finished" if transcode jobs remain in queuemythjobqueue fails to transition from "stopping" to "finished" if new jobs enter queue

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.

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by cpinkham

Milestone: 0.20

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.

comment:8 Changed 13 years ago by anonymous

Milestone: 0.20

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.

comment:9 Changed 13 years ago by anonymous

Milestone: 0.20

comment:10 Changed 13 years ago by cpinkham

Resolution: worksforme
Status: reopenedclosed

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)).

Note: See TracTickets for help on using tickets.