<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<br><br>I'm having trouble with seeking in encodings of videos that have been created using Handbrake 0.9.5 and the "High Profile" preset. I don't have problems with recordings (HD-PVR and HDHR), ISOs, or other video files. This seems to have been discussed before on the list, but it doesn't look like it was completely resolved. The previous discussion is here: <a href="http://www.gossamer-threads.com/lists/mythtv/users/483209">http://www.gossamer-threads.com/lists/mythtv/users/483209</a><br><br>On my system, seeking forward always seems to work fine, but seeking back will go back differing amounts. The amount it goes back seems to be somehow dependent on how long it's been since a seek back event occurred. That is, it's fairly accurate when I've seeked back recently (i.e. I seek back once, it takes me a long distance back in the recording, the next seek takes me back about the 5 seconds I expect). If no seek back has happened recently, when I seek back it can go 10 - 15 minutes back. <br><br>The old thread seems indicate that some people saw relief upgrading to 0.24, but since I'm already on that, I'm not sure where to look next. I don't recall this being a problem until relatively recently, but I don't know exactly when it started. Probably in the November/December timeframe. I've tried rebuilding the seek tables using mythcommflag, but that doesn't seem to have helped either.<br><br>I'm running 0.24.2/fixes on MythBuntu and keep up to date on updates. The frontend reports the following version:<br><br>Please attach all output as a file in bug reports.<br>MythTV Version : v0.24.2-3-ge4660d6<br>MythTV Branch : fixes/0.24<br>Network Protocol : 63<br>Library API : 0.24.20110505-1<br>QT Version : 4.6.2<br>Options compiled in:<br>linux profile using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_crystalhd using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg<br><br><br>Attached is the log output (playback.log.gz) from mythfrontend -v playback for a file demonstrating this problem. I started up the video, and after about 19 minutes, I hit the back button to go back 5 seconds. At the time that I did that, the current time on the OSD display said 15:00 minutes. After skipping back, the time said 14:57. (Not quite 5 seconds, but close.) The content, however, did skip back about 4 minutes of time to where the content should have been at 14:57 (verified with VLC). So, things got out of sync and even the OSD wasn't displaying the right time. <br><br>In the log file, I see many instances of messages like this:<br>2012-01-25 12:23:46.556 Player(0): Video is 3.14317 frames ahead of audio,<br><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span>doubling video frame interval to slow down.<br><br>There's a slew of them when I do the skip back itself, in fact.<br><br>I also noticed that these messages popped up at the start of playback:<br><br>2012-01-25 12:23:35.579 VSYNC: DRMVideoSync: Could not open device /dev/dri/card0, No such file or directory<br>2012-01-25 12:23:35.579 VSYNC: RTCVideoSync: Could not open /dev/rtc, Permission denied.<br>2012-01-25 12:23:35.581 Player(0): Video timing method: USleep with busy wait<br>2012-01-25 12:23:35.581 Player(0): Display Refresh Rate: 60.002 Video Frame Rate: 29.971<br><br>Could this be a configuration problem? I know that I haven't messed with /dev/dri/card0 or /dev/rtc myself, but it's possible that something might have changed over time due to system updates. (Note, that chmod'ing /dev/rtc0 to 666 didn't seem to help it use that for timing.) <br><br>I also wasn't able to clearly see which audio stream that myth picked for playback. The video file has both an AC3 and an AAC stream.<br><br>The details for the video file are attached as videoinfo.txt.gz<br><br></body></html>