It's pretty common, when I hit the 'E' key while watching a recording, for the indicator to end up at zero. Likewise it's common for me to end up back at the beginning of all video when I use the skip forward/reverse keys.
It seems the culprit is lurking in the PrepareFrame member function of most of the classes derived from VideoOutput. For example, here's the one from VideoOutputQuartz: void VideoOutputQuartz::PrepareFrame(VideoFrame *buffer, FrameScanType t) { (void)t; if (!buffer) buffer = vbuffers.GetScratchFrame(); framesPlayed = buffer->frameNumber + 1; } When paused, the buffer argument to PrepareFrame is 0 (NULL) and the result of calling VideoBuffers::GetScratchFrame is always a buffer whose frameNumber is zero. I believe there's some kind of race condition when pausing, so sometimes this doesn't cause a problem. However, when I change this to void VideoOutputQuartz::PrepareFrame(VideoFrame *buffer, FrameScanType t) { (void)t; if (buffer) framesPlayed = buffer->frameNumber + 1; } everything works perfectly. As I said, this bug is apparently repeated through most of the subclasses of VideoOutput, the exceptions being VideoOutputIvtv and VideoOutputXv. I suppose most people are using Xv and that's why it hasn't been more widely reported. Regardless, the repetition of this code pattern strongly suggests that some refactoring is in order. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev