Opened 14 years ago

Closed 14 years ago

#835 closed defect (invalid)

mythtranscode failure

Reported by: xris Owned by: Isaac Richards
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

upgraded to latest svn last night, and have been doing some nuvexport exports...

mythtranscode works fine once, but any subsequent attempt results in it complaining about "Transcoding aborted, cutlist changed"... restarting the backend lets it go once more (but only once, then requiring another backend restart). And I'm never actually touching the cutlist other than presumably mythtranscode reading it.

Change History (3)

comment:1 Changed 14 years ago by Geoffrey Hausheer <mythtv0368@…>

This can only happen in 2 cases: The 'editing' flag is set: SELECT editing FROM recorded WHERE chanid = <chanid> AND starttime = <starttime>;

or commflag is running: SELECT status FROM jobqueue WHERE type = 2 AND chanid = <chanid> AND starttime = <starttime>;

I can't see any way you'd get the message unless one of those 2 was true, and the transcoder has no way to set either of those that I'm aware of. How are you calling mythtranscode?

comment:2 Changed 14 years ago by xris

nuvexport calls it more or less like so:

/bin/nice -n19 mythtranscode --showprogress -p autodetect -c 1110 -s 2005-12-15-15-58-00 -f "/tmp/fifodir_28495/" --honorcutlist 2>&1

I ran nuvexport again, it succeeded on the first pass of the encoding but failed on the second. I restarted mythbackend and ran nuvexport again and it worked both times.

Comm flagging might be the answer, but what does commflag have to do with the cutlist, though? I thought that was completely separate.

comment:3 Changed 14 years ago by Geoffrey Hausheer <mythtv0368@…>

Resolution: invalid
Status: newclosed

We don't allow comm-flagging at the same time because in the common case, we will overwrite the original file, which may change the the key-frame locations, making the comm-flagging data wrong if it is in process. I'm closing this ticket. If you can show that neither of the above 2 cases are occurring by supplying the results of the SELECT statements at the time of the failure, then reopen, and I'll look at it some more.

Note: See TracTickets for help on using tickets.