From the mkv documentation (https://matroska.org/technical/diagram.html):
"The Matroska EBML Schema defines eight Top Level Elements: SeekHead ((#seekhead)), Info ((#info)), Tracks ((#track-flags)), Chapters ((#chapters)), Cluster ((#block-structure)), Cues ((#cues)), Attachments ((#attachments-1)), and Tags ((#tags)). The SeekHead Element (also known as MetaSeek) contains an index of Top Level Elements locations within the Segment. Use of the SeekHead Element is RECOMMENDED. Without a SeekHead Element, a Matroska parser would have to search the entire file to find all of the other Top Level Elements. This is due to Matroska’s flexible ordering requirements; for instance, it is acceptable for the Chapters Element to be stored after the Cluster Elements." And this, too: "The Cues Element is used to seek when playing back a file by providing a temporal index for some of the Tracks. It is similar to the SeekHead Element, but used for seeking to a specific time when playing back the file. It is possible to seek without this element, but it is much more difficult because a Matroska Reader would have to ‘hunt and peck’ through the file looking for the correct timestamp. The Cues Element SHOULD contain at least one CuePoint Element. Each CuePoint Element stores the position of the Cluster that contains the BlockGroup or SimpleBlock Element. The timestamp is stored in the CueTime Element and location is stored in the CueTrackPositions Element. The Cues Element is flexible. For instance, Cues Element can be used to index every single timestamp of every Block or they can be indexed selectively." Instead, the ffmpeg documentation states. (https://ffmpeg.org/ffmpeg-formats.html#matroska): "reserve_index_space By default, this muxer writes the index for seeking (called cues in Matroska terms) at the end of the file, because it cannot know in advance how much space to leave for the index at the beginning of the file. However for some use cases – e.g. streaming where seeking is possible but slow – it is useful to put the index at the beginning of the file. If this option is set to a non-zero value, the muxer will reserve a given amount of space in the file header and then try to write the cues there when the muxing finishes. If the reserved space does not suffice, no Cues will be written, the file will be finalized and writing the trailer will return an error. A safe size for most use cases should be about 50kB per hour of video. Note that cues are only written if the output is seekable and this option will have no effect if it is not. cues_to_front If set, the muxer will write the index at the beginning of the file by shifting the main data if necessary. This can be combined with reserve_index_space in which case the data is only shifted if the initially reserved space turns out to be insufficient. This option is ignored if the output is unseekable." Perhaps one should indicate these parameters to CinGG? PS: I did some tests (it had been a long time since I had used mkv) without any problems, as also reported by IgorBeg.