"Flashing sequence of pictures" instead of smooth video resulted...

[eumagga0x2a]

Thanks, the smallest "1GB" chunk (1,073,880,064 bytes) is 240640 bytes smaller than the largest (1,074,120,704), and even the smallest is bigger than 1 GiB (what "GB" on Windows stands for) = 1,073,741,824 bytes. If chunks happen to be within 1 MiB tolerance from n GiB in size we might re-enable prompting for binary append in the demuxer without getting too many false positives.

[EFuggerth]

I have checked several other film-folders, and have found 2 chunks smaller than has already been passed: they are 1 073 831 936 and 1 073 783 808 bytes. Moreover, chunk-size is not at random: the size of 1 073 880 064 bytes appeared on 3 more occasions. Also is worth checking: dividing sizes with the smallest difference [48,128 bytes] always gives integer. The new biggest I could extract is 1 074 216 960 bytes.
I remain thus expectant – and patient as well.
Both in chunk-size recognition and on treating false time-marker jumps.

[eumagga0x2a]

Auto-append in the MpegTS demuxer, now restricted to video streams split approximately at GiB boundaries as produced by some devices like action cams, has been re-enabled and should be available for testing in future nightly builds.

[EFuggerth]

I'm jump-ready for testing.
Meanwhile, here is another admlog.zip file, where the unpredictable time-marker behaviour happened twice: at first when dropping the beginning part of the raw source-file, then on trying to mark the end (as described earlier).

[eumagga0x2a]

Do you always need an append operation to reproduce rewind on stopping playback? I don't think a log will suffice, please provide a sample + exact steps to reproduce.

What you saw was mostly a result of failed seeks due to corrupted video stream so far. The behavior at the boundary of two segments might deserve more attention, however.

[eumagga0x2a]

Got all sample files, thank you. For the starters, I'm trying to figure out why auto-append in the demuxer wrongly rejects them.

[eumagga0x2a]

Detection fixed, it was broken for 1 GiB sized fragments due to my really stupid mistake, would have worked starting with 2 GiB.

Now trying to reproduce the seek failure on stopping playback.

[eumagga0x2a]

No luck with reproducing a seek failure. More or less exact steps to reproduce like at least the approximate time in video where it happend for you would really help.

[eumagga0x2a]

Nightlies with auto-append for 1 GiB stream fragments fixed are available now.

[EFuggerth]

The misbehavior in the sent sample was at searching for the trimming point, while locating the beginning of the film (which was opened & appended full), with last positioning done by pushing the stop-button. [As a phrased previously: "The unwelcome jump of the time-marker happened right at searching for the actual beginning of the film to be trimmed."]
Though, as I mentioned already, I have found no such thing as exacts reproducibility here. To overcome the inconvenience of unhappy repeating (at slightly different time-points) I applied dragging followed by stepping (rough+fine) instead of play/stop.
Glad to know there are nightlies capable of automatic appending for me again. (Will you keep this feature incorporated from now?) As to go to the test, however, I would need more peace.
Peace indeed. Because, so to speak, I am "north by north" against Court, in a wide-ranging environmental issue, which they sedate to a personal matter striking hard my household. And this affair, closing to a kind of culmination, calls for every TBytes of my nerves capacity.
Thanks again for solving the problem that hampered for a period my archiving.

[eumagga0x2a]

With the help of the log file you provided, I finally managed to reproduce the issue, thank you. Should be fixed now, please try a future nightly.

As already suspected, admPreview::samePicture() was unsuitable once the seek to the last displayed (vs last decoded) picture failed. admPreview::nextPicture() may fail too, of course, but it is much more robust.

The issue had nothing to do with append operations or any particular editing steps.

[EFuggerth]

Downloaded your r181112win64 (Nov 12, 2018) nightly at last, and archived 21 films without any disruption.
Auto-append is great again.
I appreciate your commitment.