Opened 9 years ago

Closed 9 years ago

#8868 closed defect (fixed)

Major Matroska seeking regression following recent ringbuffer optimization

Reported by: robertm Owned by: danielk
Priority: blocker Milestone: 0.24
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Recent RingBuffer? changes appear to have caused a major regression in Matroska seeking. The regression seems unique to this container, but a skip of any kind now takes several minutes during which time the FE is entirely unresponsive. This includes starting a Matroska container with a bookmark.

Also likely related, attempting to do any skip the *first* time in a file will restart playback. All following seeks exhibit the behavior above. This makes Matroska basically unusable as a container.

http://www.fecitfacta.com/MBE.log http://www.fecitfacta.com/FE.log

Change History (5)

comment:1 Changed 9 years ago by robertm

Status: newassigned

comment:2 Changed 9 years ago by danielk

Robert, it appears the problem is with seeking to the end of the file so I'm going to need access to the smallest full file of this sort that exhibits the problem. You can send me a link privately.

comment:3 Changed 9 years ago by robertm

Hi Daniel,

I can produce a sample, it does appear to read the entire file across a network for a skip-- so the delay is proportionate to the size of file (ie, a 10 GB file is exponentially longer in delay than a 600 MB file)... I can produce a large sample and host it somewhere, but the most expedient thing may be to simply produce a Matroska file from a large, long recording and try that (via myth:// protocol). Let me know if you want me to produce it, or if you're able to reproduce from a generated file.

comment:4 Changed 9 years ago by robertm

Following some troubleshooting with Chris Pinkham, it appears that turning the "within 300k of end of file" optimization (RingBuffer?.cpp:1889) off makes seeks near-instantaneous again.

comment:5 Changed 9 years ago by robertm

Resolution: fixed
Status: assignedclosed

Fixed in r26173. Thanks, Daniel!

Note: See TracTickets for help on using tickets.