Slow navigation problem with an mkv file

[HisDudeness]

Hi everyone! I have an mkv file which I didn't rip personally (I'm a complete ignorant in terms of Blu-Ray ripping), so I don't know any of the parameters used during ripping. This file (and only this, I played a thousands mkvs ripped from my BDs and never had such a problem) is extremely slow in terms of skipping/loading. That means if I want to go at a certain point of it, it takes an eternity to accomplish that. Also, the waiting time seems to be proportional by the entity of the skipping I want to do, like if it has a low but precise skip speed, almost like if in order to go from point A to point B it has to play everything that's between those two points.

Can you tell me some diagnosis I can make to tell you more details and help you identify the problem? Or some usual cause of this issue?

Thanks everyone!

[poisondeathray]

What player are you using ? VLC is know to have issues with more recent build mkvmerge muxes . What happens if you try another player e.g. smplayer, mpchc , potplayer ?

mediainfo (view=>text) will show the encoding parameters used if the encoder was x264 .

[HisDudeness]

Oh, you're right. I've used mediainfo about a million times and still I didn't think about that. Here are some lines that could matter in my opinion.

Writing application: mkvmerge v3.4.0 ('Rapunzel') built on May 15 2010 09:38:20
Mkv Writing library: libebml v0.8.0 + libmatroska v0.9.0
Video Writing library: x264 core 105 r1724 b02df7b

And here are all the encoding settings:

cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=9563 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=17500 / vbv_bufsize=14000 / ip_ratio=1.40 / aq=1:1.00 / nal_hrd=none

I can tell you with Banshee it does the same. I know it's more a music player, but it's the only other player I have. I'll try on another system, maybe on a Windows with MPCHC and I'll let you know.
Oh, I also tried remuxing it with the latest mkvmerge and it left things the same way...

[hello_hello]

Try remuxing it without the audio to see what happens. You never know.....
If seeking is fine without the audio you might need to re-encode the audio stream and remux the re-encoded version with the video as a new MKV.