Opened 14 years ago
Closed 14 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)
Change History (11)
Changed 14 years ago by
| Attachment: | mythfrontend_log-deadlock_seek_to_end_in_edit.txt added |
|---|
Changed 14 years ago by
| Attachment: | gdb-deadlock_seek_to_end_in_edit.txt added |
|---|
gdb backtrace of hung process
Changed 14 years ago by
| Attachment: | mythtv-fix_nextcut_seek_to_end.patch added |
|---|
patch that prevents the hang, but may cause other problems.
comment:1 Changed 14 years ago by
| Status: | new → assigned |
|---|
comment:2 Changed 14 years ago by
| Owner: | changed from danielk to markk |
|---|
comment:3 Changed 14 years ago by
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 14 years ago by
comment:5 Changed 14 years ago by
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 14 years ago by
| Milestone: | unknown → 0.24 |
|---|---|
| Status: | assigned → accepted |
comment:7 Changed 14 years ago by
(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 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
(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.
-v important,general,playback log