Unable to seek to start of video

[drewt]

I am unable to seek to 0:00 in the OP/ED of the G_P Votoms release (http://bakabt.me/torrent/147778/soukou-kihei-votoms-armored-trooper-votoms-remastered-h264-g-p). The release has the OP/ED in separate files. When I play the files individually, they start at 0:00 but I am unable to seek back to that point. When I play an episode, the OP/ED begin playing in the middle of the file (at 0:14 and 0:20, respectively, which are the earliest positions I can seek to when playing the files individually).

I noticed this after upgrading to 0.9.1 and I can confirm that the problem exists in git master as well. I was not getting this behaviour prior to 0.9.1 (unfortunately I can't remember which version I was using before; presumably whatever version Gentoo ~amd64 was on prior to 0.9.1).

[ghost]

I'm not sure what exactly is the cause. Maybe it's the seek clamping (which effectively restricts relative seeks to the known valid range of the file), but it shouldn't cause this.

Can you upload the files somewhere? (No torrents please.)

[drewt]

Sure.
http://a.pomf.se/frhvpl.mkv
http://a.pomf.se/retnue.mkv

[ghost]

The retnue.mkv sample has a somewhat broken index entry. The first entry points a few seconds into the file, so you can't seek to before that.

I couldn't get any better behavior with 0.9.0 and 0.8.3.

I'd declare this a broken file. And the muxer looks indeed a bit strange:

| + Muxing application: Haali DirectShow Matroska Muxer 1.8.122.18 at 156
| + Writing application: gdsmux at 201

I've never seen this before.

Remuxing the file with mkvmerge or adding --index=recreate to the mpv commandline seems to fix seeking.

[ghost]

Can you paste the output of mkvinfo -v -v run on the original file?

[drewt]

On further inspection, the seeking behaviour is the same in 0.8.3, but I get different behaviour when the files are loaded as part of an episode. In 0.8.3 they start playing at 0:00 whereas in 0.9.1 they start in the middle. So I guess the files are broken as you say, but previous versions of mpv were able to handle them a bit more gracefully somehow. Anyways, I will try remuxing. That seems like the best solution in this case.

mkvinfo -v -v: http://pastebin.com/aty6AxAH

[ghost]

mkvinfo -v -v: http://pastebin.com/aty6AxAH

It's also missing the first index entry.

I really don't know why it would have changed behavior between these versions. If you're in for an adventure, you could try to bisect git.

[drewt]

I've bisected and it seems the change was introduced in commit 457e2f7.

[ghost]

I tried with this commit reverted, but seeking in the sample you provided didn't get better.

[ghost]

Although... seeking to the start for the first time works; but I suspect it just fails to seek internally in this case, which happens to give the expected result.

[drewt]

I tried with this commit reverted, but seeking in the sample you provided didn't get better.

Right, seeking still doesn't work. The difference is that when the broken file is loaded on behalf of some other file it starts playing from the middle, whereas with the old code it would play from the beginning. So when the ED starts it jumps 20 seconds forward, for example.