Opened 10 years ago

Closed 9 years ago

#6443 closed defect (duplicate)

Transcode job doesn't exit

Reported by: paul [at] planar.id.au Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: MythTV - Mythtranscode Version: unknown
Severity: low Keywords:
Cc: Ticket locked: no

Description

I'm running trunk, latest version ().

I noticed the other day that I had a large number of mythtranscode jobs running on my machine - 20 or 30 of them. They were all idle, and of various ages. I killed them all, and upgraded to the latest version to see if it still was doing it. Yesterday morning I again had a couple of spare jobs.

I was trying to work out how to debug this. I used ps -efl to get the full command line, and then ran that job with the extra "-v most" option, and output stdout and stderr to a log.

The command I ran was: /usr/bin/mythtranscode -j 5217 -V 3 -p 28 -v most > transcode_log 2>&1

The end of that log shows what appears to be a clean exit (refer bottom of this message for last 20 lines of the log) and the command from my command line claims to have ended: [1]+ Done /usr/bin/mythtranscode -j 5217 -V 3 -p 28 -v most > transcode_log 2>&1

However, when I run

ps -ef |grep transcode

I still see the job running: mythtv 1179 1 0 07:10 pts/8 00:00:00 /usr/bin/mythtranscode -j 5217 -V 3 -p 28 -v most

This seems very weird to me - that linux would think the job has ended when it is still there. It sort of seems like it would most likely be some sort of user error on my part, but I can't imagine what I would have done that would cause it. It wasn't happening a month or so ago, and is happening now, and I don't recall changing any material settings in that time.

Extract last 20 lines of log: 2009-04-02 07:10:39.595 read <- 10 51 BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE[]:[]empty 2009-04-02 07:10:39.603 MythEvent?: RECORDING_LIST_CHANGE 2009-04-02 07:10:39.617 JobQueue?: ChangeJobStatus?(5217, Stopping, ) 2009-04-02 07:10:39.617 Transcoding /usr/share/mythtv/recordings/6008_20090330112000.nuv done 2009-04-02 07:10:39.653 SG(Default): FindRecordingFile?: Searching for '6008_20090330112000.nuv' 2009-04-02 07:10:39.653 SG(Default): FindRecordingDir?: Checking '/usr/share/mythtv/recordings' for '/usr/share/mythtv/recordings/6008_20090330112000.nuv' 2009-04-02 07:10:39.653 SG(Default): FindRecordingFile?: Found '/usr/share/mythtv/recordings/6008_20090330112000.nuv' 2009-04-02 07:10:39.653 ProgramInfo?: GetPlaybackURL: File is local: '/usr/share/mythtv/recordings/6008_20090330112000.nuv' 2009-04-02 07:10:39.751 mythtranscode: About to unlink/delete file: /usr/share/mythtv/recordings/6008_20090330112000.nuv.old 2009-04-02 07:10:39.767 Truncating /usr/share/mythtv/recordings/6008_20090330112000.nuv.old. 2009-04-02 07:10:39.769 Truncating /usr/share/mythtv/recordings/6008_20090330112000.nuv.old in the background. 2009-04-02 07:10:40.205 JobQueue?: ChangeJobStatus?(5217, Finished, ) 2009-04-02 07:10:40.206 MythSocket?(8f3ad40:11): DownRef?: -1 2009-04-02 07:10:40.206 MythSocket?(8f3ad40:11): state change Connected -> Idle 2009-04-02 07:10:40.206 MythSocket?(8f3ad40:-1): delete socket 2009-04-02 07:10:40.206 MythSocket?(8f3c798:10): DownRef?: 0 2009-04-02 07:10:40.232 MythSocket?(8f3c798:10): DownRef?: -1 2009-04-02 07:10:40.232 MythSocket?(8f3c798:10): state change Connected -> Idle 2009-04-02 07:10:40.232 MythSocket?(8f3c798:-1): delete socket 2009-04-02 07:10:40.489 MythSocket?: readyread thread exit

Change History (4)

comment:1 Changed 10 years ago by paul [at] planar.id.au

Further thought. I wonder whether it is because my file system is ext3, and I have "delete files slowly" selected. It appears to have finished transcoding, and has renamed the new file. Perhaps it is waiting on the deletion to finish before exiting, and that deletion isn't finishing?

comment:2 Changed 10 years ago by octavsly@…

I have the same issue. Due to this mythbackend cannot go to idle and cannot shutdown.

I noticed that all mythtranscode jobs have init (PID 1) as parent.

comment:3 Changed 10 years ago by Octavian <octavsly@…>

this might be a duplicate of #7315

comment:4 Changed 9 years ago by sphery

Resolution: duplicate
Status: newclosed

Closing as a duplicate of #7315. If you can reproduce the issue with current trunk, please reopen. Note that the fix for #7315 is not yet in 0.23-fixes.

Note: See TracTickets for help on using tickets.