Sorry for not testing it with the latest build (would probably seem common sense). Generating timecode by enabling "Proxy / Timecode" and setting "Timecode" to "Record Run" and then running "Rebuild Proxy and Timecode Indices" has actually fixed this problem, even though I'm still a bit puzzled because I never had this problem before, despite always having source material encoded with the same codec. I have even used the same source material (which is pretty harmless lossless, keyframes only) and rendered several different sections, without any problem.

So in order to facilitate my understanding, could you please confirm if the following pseudo-code for the Blender rendering process is correct (at least morally)?

for $frame from $startframe to $endframe
{
   $timestamp = time_to_timestamp( ($frame-$startframe)/$framerate);
   read_seek($timestamp);
   $image = avcodec_decode_video2(...);
   output_image($image);
}

Is it correct that timecode is needed in the routine time_to_timestamp (which I'm aware may not actually exist as a single routine, but you get the idea), and that missing timecodes can lead to faulty timestamps?

Also, generating proxies/timecode took three hours for my 45 minute video. Is this normal? Or is there a way to only generate timecode indices, but not proxies (which seems what's taking so long)?

Thanks for your efforts!

I have no idea of hands of how exactly timecode is used, but yes, with many modern codecs, it's the only way to ensure correctness of frame seeking.

And you do can generate only the timecode, just disable all 'proxy' sizes options in the panel.