[mythtv-users] Odd response to forward

[Michael T. Dean]

On 03/23/2014 08:05 PM, Dick Steffens wrote:
> Last night we watched something I had recorded with my old ReplayTV 
> before I had Myth running. I used the ReplayTV download function to 
> transfer the .mp4 (and several other .mp4 files) to my desktop 
> machine. The, when Myth was running, I copied those files to the Myth 
> machine, and moved them to /var/lib/mythtv/videos. Then I used the 
> function (don't remember the name, or where it is) to have Myth 
> discover those videos.
>
> The movie included some commercial breaks. When we got to them I used 
> the jump ahead function (right arrow on the remote) a few times to get 
> to the next part of the movie. The odd thing was that the first time I 
> hit the right arrow, instead of jumping forward, it jumped back. 
> Further applications of the right arrow did jump forward. That 
> sequence was repeated for each commercial break. Otherwise, the movie 
> played correctly.
>
> Any idea what was going on there? I haven't had that problem with any 
> videos recorded by Myth, nor with the other imported videos that were 
> recorded on my ReplayTV.

You've just discovered why MythTV has seek tables.  In video, when you 
seek, you have to either play all the video from now until the desired 
time or "guess".  Since playing all the video between now and--even a 
small--30sec seek could take a long time (up to 30s on some 
barely-capable systems), we don't generally do this.  To guess, you 
generally take the bitrate (bits per second) and compute how many bits 
from a given point you'll need to skip to hit a given number of 
seconds.  In a video with variable bitrate (read, nearly all videos 
today), this approach can yield unexpected results--even to the point of 
skipping backwards for a forwards seek.

So, the best approach to solve the issue is to create a seek table--a 
table recording the time within a video at a given point.  Given such a 
table, you have much more information to use to make a guess.  However, 
since we tend to have a very complete record of time positions (one for 
each keyframe within the video--often spaced about half a second apart), 
we generally can jump directly to the right place.

In Video Library, however, no seek table is created automatically.  You 
can either transcode/remux the video into a better container (that has 
its own seek/navigation support, such as Matroska), create a Video 
Library seek table manually (especially if you have a particularly 
troublesome video) using mythcommflag --rebuild --file, or you can just 
ignore/work around the issue (seek a few more times or a greater length 
of time when it gets it wrong).  If it's a "watch and delete" video, 
though, generally it's not worth the effort of transcoding/remuxing or 
manually creating a seek table--so you're likely to just work around 
it/ignore it.

FWIW, I see this all the time with even MythTV-recorded videos (in which 
I can seek perfectly in MythTV) when I stick them on my laptop to watch 
in airports/hotels or on airplanes with xine or mplayer or whatever.  
However, since these are my "better than the garbage they give me" 
distractions, it's not a big deal/not worth worrying about.  So, when I 
get an incorrect seek, I just seek again.  In some cases, I'll get 
"trapped" in a seek loop (where it skips back 1s or something, and no 
matter how many times I seek from around this point, it goes to the same 
place), at which point I just seek farther (so, if my 7s seek doesn't 
work, I use the 15s or the 30s or the 60s seek).

> Possibly unrelated: When we finished watching that movie I tried to 
> delete it. Myth said it could not. This afternoon I was noodling 
> around and noticed that I was the owner of that file.

That isn't related to the skip/seek issue.

> Once I changed the ownership of that file and the associated .png file 
> to mythtv, Myth was able to delete the video. I went back and looked 
> in /var/lib/mythtv/videos and, sure enough, the video file was gone, 
> however the png file was still there.
>
> Also possibly unrelated, somehow the .mp4 file had an extra dot in 
> front of the .mp4, so movie..mp4. I know that's no problem for Linux 
> to deal with, but is that why Myth didn't delete the .png file, which 
> has only one dot?

Quite likely--the way we strip the file extension to create the preview 
picture name isn't super robust and is really only tested with a single 
dot before the extension.

Mike