Opened 9 years ago

Closed 9 years ago

#8842 closed defect (fixed)

Seek to end in edit mode causes deadlock

Reported by: sphery Owned by: markk
Priority: minor Milestone: 0.24
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Hitting NEXTCUT (PgDown?) while in edit mode when there are no further cuts in the cut list locks the frontend after logging the message:

2010-08-29 19:46:18.309 Dec: DoFastForward?(): desiredFrame(107668) > last_frame(107640)

Attached are mythfrontend log file at -v important,general,playback; gdb backtrace after interrupting on hang; and a patch that prevents the hang, but may prevent frames after the last keyframe from being accessible.

Attachments (3)

mythfrontend_log-deadlock_seek_to_end_in_edit.txt (24.5 KB) - added by sphery 9 years ago.
-v important,general,playback log
gdb-deadlock_seek_to_end_in_edit.txt (79.8 KB) - added by sphery 9 years ago.
gdb backtrace of hung process
mythtv-fix_nextcut_seek_to_end.patch (1.5 KB) - added by sphery 9 years ago.
patch that prevents the hang, but may cause other problems.

Download all attachments as: .zip

Change History (11)

Changed 9 years ago by sphery

-v important,general,playback log

Changed 9 years ago by sphery

gdb backtrace of hung process

Changed 9 years ago by sphery

patch that prevents the hang, but may cause other problems.

comment:1 Changed 9 years ago by sphery

Status: newassigned

comment:2 Changed 9 years ago by markk

Owner: changed from danielk to markk

comment:3 Changed 9 years ago by sphery

Also, when seeking to the beginning of the recording in edit mode (using any seek--Left/Right/PgUp?, etc.), when you get to the first frame, pause is unset by something and the frontend starts logging:

2010-08-30 21:43:27.660 Player(0): Ignoring Play(), in edit mode.

until you seek away from the first frame. (Note that the seek to end issue is only triggered with NEXTCUT/PgDown.)

comment:4 Changed 9 years ago by markk

(In [26013]) Don't try and stop rewinding if we aren't rewinding.

Refs #8842

comment:5 Changed 9 years ago by sphery

For what it's worth, it seems it's not actually a deadlock when seeking to the end in edit mode, but the player actually plays all the frames from the current point until the end of the recording after the message:

2010-08-30 19:47:29.897 Dec: ConditionallyUpdatePosMap: Still not enough info in positionMap after sync,
                        we need frame 107668 but highest we have is 107640. Will attempt to seek frame-by-frame

So, if you're close to the end, it will recover before too long--delay is dependent on your starting point and the duration of the recording. I don't know if it's possible to seek to the last-known key frame, and /then/ play to the end rather than seeking from current position, but it seems that doing so would be faster.

(And, FWIW, the invalid log messages from comment:3 are now fixed.)

comment:6 Changed 9 years ago by markk

Milestone: unknown0.24
Status: assignedaccepted

comment:7 Changed 9 years ago by markk

(In [26485]) Add a bounds check to WaitForSeek? to ensure we do not try and seek beyond the end of the available stream.

This will fix potential lockups in most situations but there is still a bug in DecoderBase? that can be triggered under the correct conditions (e.g. trying to edit an in-progress recording). Fix to follow.

Refs #8842

comment:8 Changed 9 years ago by markk

Resolution: fixed
Status: acceptedclosed

(In [26486]) Fix seeking to near the end of an in progress recording.

We were hitting an infinite loop when frame by frame seeking as the position map wasn't actually getting updated - hence we were never going to break out of the seek loop for a file that didn't have an end (i.e. in progress).

I'm not sure whether this is a long standing issue that has been exposed or a subtle side effect of the thread changes in MythPlayer?.

Closes #8842 - though I'll also later add some sort of debug check to identify any other cases that trigger this condition.

Note: See TracTickets for help on using tickets.