Opened 11 years ago

Closed 11 years ago

#8843 closed defect (Fixed)

PLAY/PAUSE delay regression

Reported by: stuartm Owned by: markk
Priority: blocker Milestone: 0.24
Component: MythTV - Video Playback Version: Master Head
Severity: high Keywords:
Cc: Ticket locked: no


The time before the PAUSE action being received and the video actually pausing has regressed in trunk, there is a noticeable delay of a second or more.

This becomes even greater when rewinding, or fast-forwarding at a speed greater than 3x where it then takes several seconds to react. This means that even with the seek compensation you resume playback well past the point you were aiming for.

Attachments (1)

not-so-sluggish.diff (645 bytes) - added by markk 11 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 11 years ago by robertm

Owner: changed from janneg to markk
Status: newassigned

comment:2 Changed 11 years ago by markk

Resolution: Works for me
Status: assignedclosed

I'm not seeing this in any of 5 different frontends running r26274

comment:3 Changed 11 years ago by stuartm

Owner: changed from markk to stuartm

comment:4 Changed 11 years ago by stuartm

Resolution: Works for me
Status: closednew

comment:5 Changed 11 years ago by stuartm

Guess I'll have to debug it then.

comment:6 Changed 11 years ago by Kenni Lund [kenni a kelu dot dk]

Status: newassigned

comment:7 Changed 11 years ago by stuartm

Milestone: 0.240.25

I'm no longer able to consistently reproduce this and so it's unlikely that I'll be able to fix it for 0.24. I've see no changes which might have fixed it, so I can only assume that the bug still exists but is dependant on a variety of factors. To be clear, I'm still a delay in exiting from Rew/FF, it just isn't the several second delay that it was earlier.

There are some general problems with seeking anyway, Rewinding at 3x seems to instead move at 10x, in 6 seconds it will move a whole minute.

comment:8 Changed 11 years ago by stuartm

Milestone: 0.250.24
Owner: changed from stuartm to markk
Priority: majorblocker

Seems I can reliably reproduce with certain samples and both Mark and Taylor can too. Mark indicated that this was a more serious bug than first thought since it appears that the player timer is being delayed/blocked, so I'm moving it to a blocker for 0.24.

Changed 11 years ago by markk

Attachment: not-so-sluggish.diff added

comment:9 Changed 11 years ago by anonymous

The attached patch should improve keyboard response time when fast forwarding/rewinding. Fundamentally those large seeks are however blocking the UI thread - so I can't see a way of improving this any further.

comment:10 Changed 11 years ago by markk

Resolution: Fixed
Status: assignedclosed

(In [26869]) Improve MythPlayer?'s responsiveness to actions when fast forwarding and rewinding.

A little history:-

  • The OSD re-write moved media playback into the main UI thread to

ensure QObjects behave correctly and to avoid interacting with the X server in a unsafe manner.

  • We can't block the main UI thread and hence can no longer use a simple

loop for playback and need to plug into the main Qt event loop.

  • The simple loop was initially replace by using a QTimer with a zero

timeout to trigger displaying the next frame (the zero timeout is a special case that processes the timer event once all other events have been cleared).

  • The behaviour of QTimer has changed in Qt 4.6 and it no longer

delivers playback events as fast as previously - with an obvious impact on performance.

  • The QTimer was replaced with a custom player event type.
  • To ensure playback performance is maintained, we queue up several of

these player events and hence minimise any delay between displaying one frame and the next.

  • When fast forwarding and rewinding, the main UI thread can be blocked

for significant periods of time (due to the frequent seeks and the change to the screen update period).

  • If up to 3 player events are queued during fast forward/rewind then

the delay before an action is processed can be measured in seconds.

... so when fast forwarding/rewinding, drop the number of events in the queue to one.

This is not a perfect solution as there can still be a noticeble delay and it would be much better if we actually knew what was happening in the main event loop and/or had the ability to customise it for our needs.

Closes #8843

Note: See TracTickets for help on using tickets.