Yes, but the problems are coming with file splitting for FAT SDCard.
You need at least 2 files to reproduce the first problem, and 3 to imagine what is coming with long time recording.

How do we know that the first problem is with Kdenlive and not with the screen capture program? Maybe it is the screen capture glitching when the recording clicks over the 2Gig boundary.

Have you tried to transcode these files to another format ? Because presumably - at the end of the day - you are not going to have a bit rate of 2gig per 10 mins of video in your final edit. So if can get the bit rate down maybe they will edit properly.

It's not a screen capture, but a cam recorder in front of my screen.
I didn't transcode to other format (the problem is still present with proxy clips, witch are transcoded from original MTS files).
What transcoding command line would you suggest me?

Ok. So ....
How do we know that the first problem is with Kdenlive and not with the camera? Maybe it is the camera glitching when the recording clicks over the 2Gig boundary.

With the proxies in play - do you see the issue on preview in the project?
Do you see it in the rendered video?
Do you see it if you render and turn on "render using proxy clips" ?

You can right click a clip in the project tree and do a transcode from there. There various transcode options.

Can you check that the source footage is sane using VLC and single stepping the last and first few frames?

MLT devs just commited a fix for errors reading H.264 streams beginning with B-frames...
Maybe worth trying to build it?
Cheers!

Problem still here with Kdenlive 16.12.3 and melt 6.4.1.
https://bugs.kde.org/show_bug.cgi?id=379033