Opened 13 years ago

Closed 13 years ago

#1226 closed defect (wontfix)

Playback / seeking broken on OS X frontend

Reported by: foobum@… Owned by: Nigel
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords: mac seeking playback OSX
Cc: Ticket locked: no

Description

Running 8873 on a linux combined fe/be and on an OS X frontend. On OS X (mac mini) playback of recorded video frequently pauses with "Waiting for prebuffer.." and sometimes stops entirely - lots of waiting for prebuffer followed by RingBuffer::safe_read() failing. CPU utilisation while all this is taking place is ~40%. See stops.log.

In addition, jumping forwards in the stream takes an eternity. The main (linux) box skips forward in the same file without problem. See seek.log (contains 2 seeks, both took ages).

As an aside, it seems that if you set overscan / offset options for playback that cause the overscanned dimensions to exceed that of your display resolution, cpu utilisation shoots up to ~95%. I assume this is a bug?

Attachments (2)

stops.log (21.2 KB) - added by foobum@… 13 years ago.
log of pauses and eventual unexpected stop with -v playback
seek.log (28.5 KB) - added by foobum@… 13 years ago.
log of slow seeks on OS X frontend

Download all attachments as: .zip

Change History (7)

comment:1 Changed 13 years ago by anonymous

Keywords: mac added; ac removed

typo in keywords

Changed 13 years ago by foobum@…

Attachment: stops.log added

log of pauses and eventual unexpected stop with -v playback

Changed 13 years ago by foobum@…

Attachment: seek.log added

log of slow seeks on OS X frontend

comment:2 Changed 13 years ago by danielk

Milestone: unknown
Owner: changed from Isaac Richards to Nigel
Reporter: changed from foobum@… to foobum@…

comment:3 Changed 13 years ago by foobum@…

Resolution: invalid
Status: newclosed

The playback problem turned out to be caused by the NIC driver on the backend - disabling the apic seems to have fixed it. A bit of debugging revealed that the seeking issue was because the timezone was set incorrectly on the Mac - the SQL query to populate the PosMap? was requesting a starttime 8 hours earlier than it should have. Seems a bit strange that recstartts is adjusted for timezone rather than just copied from the filename, which would always be correct but hey..

comment:4 Changed 13 years ago by anonymous

Resolution: invalid
Status: closedreopened

Sorry to reopen a closed ticket, but I also see this for speeds > 3x on my mac frontend and my timezone is correct.

comment:5 Changed 13 years ago by Nigel

Resolution: wontfix
Status: reopenedclosed

Waiting for prebuffer basically means that either the network or the Mac can't get the data fast enough. On my Mac (1.3GHz G4), pressing U once (i.e. going from 1x to 2x) means my CPU goes from 90% to over 100%, and the console starts filling up with prebuffer messages. Unless you have a much faster Mac than me, or you are watching postage-stamp sized video, this is to be expected.

Note: See TracTickets for help on using tickets.