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

[eumagga0x2a]

Thanks, we are on it at the moment, don't think that we need new samples. Currently, the problem looks like a ffmpeg bug, there is a workaround as the last resort.

The stream is field-encoded, which is very uncommon nowadays. When the keyframe (the first field) is fed to lavcodec after decoder flush, it immediately pops out a bogus gray image instead of waiting for the second field.

[EFuggerth]

While embracing the good news, I beg of Lord this bug not to escalate into buggery.

[eumagga0x2a]

Mean has independently found the solution and then identified the upstream fix for FFmpeg which solves this issue and pushed the changes necessary to integrate this patch into Avidemux. You might want to try the latest nightly (r180524 at the moment). Please be aware that you won't be able to save a similar field-encoded mpeg2 video in copy mode yet.

[EFuggerth]

This Mean-news is happy-news, rather.
(Sorry for my being late with checking your newest "nightly".)
Full visibility on tracking the frames is restored, indeed. (So, manipulations can now be followed again.)
HOWEVER: The complete (cut) film [if it comes from appending and saving the Avidemux-manipulated segments of the fixed broadcast] (on the usual "VLC" replay) exhibits a marked, extremely disturbing asynchrony between pictures and voices. [N.B.: the saving-process of the appended parts onto a single-part film is unusually slow.] On the contrary: No such asynchrony emerges if the resulting film is made by appending the original segments first and then Avidemux-manipulating the whole [and saving it (in an output format "Mpeg2 TS muxer (ff)")]. (Wherefore, incorporating a direction running this way into your next nightly could be useful.)
This I experienced after several trials.
How further then?
Your last sentence in the latest message warns as "Please be aware that you won't be able to save a similar field-encoded mpeg2 video in copy mode yet." Does it mean I should be expecting some further refining?

[eumagga0x2a]

As stated above, the copy mode for field-encoded video is broken. Fix upcoming.

Re-encoding (adding a good deinterlacer is highly recommended) should work.

[EFuggerth]

Your latest version (2.7.1) solved my pending archive-manipulations with success. (Though small bugs must still be hiding, they cause manageable inconvenience for the resolved.)
Wherefore:
A prominent Newbie having rambled leeward on forbidden pastures for an embarrassing period (with a relentless series of 66 winters survived) wishes to express his gratitude for this session and for all your hero-members' work behind.
Rewarding or not, I hereby take the boldness and attach a picture of "Siberian Honey-berry" [taken on a domesticated species in my garden], if for not other reasons than to spare the inconveniences of travelling there to see it.
Whereby to earn respect for the Newbian colors.

[eumagga0x2a]

Though small bugs must still be hiding, they cause manageable inconvenience for the resolved.

Have you tested with the latest available nightly build (r180702 so far)? If the bugs persist, it would be nice to get to know what these bugs are.

[EFuggerth]

Not yet.
Nightly 2.7.0 (180524) had already solved the main issue, then – out of a sudden – came a 2.7.1 version when making the robot of archiving. This latter worked more stable.
The hiding bugs must be somewhat tricky, for the peccadilloes are not predictable: The symptoms can be described clear, but there is no telling when the problem surfaces and when it decides not to. And so long as it remains so random in nature, I do not want to rob you of innocent nights.
Should your curiosity persist, however, I'll offer details made with the latest nightly available at the time – soon as I am over some tedious other tasks, and a newer bunch of films are crying for my nursing. But I fear, that to trap efficiently these hiding little monsters would require real-samples again, of appreciable sizes.

[eumagga0x2a]

That nightly contains fixes for regressions https://avidemux.org/smif/index.php/topic,18363.0.html (playback stuttering or stuck after going to the previous frame) and for https://avidemux.org/smif/index.php/topic,18382.0.html ("fade to black" filter broken). One pretty important fix of audio delay calculation in the Mp4 demuxer has been added after the nightly was built.

If the issues you see are different, please provide more details.

[EFuggerth]

Will reflect – soon as material to deal with gathers...

[EFuggerth]

The promised check for remaining blemishes:
On working up today the newly gathered material (approx. 30 items) but now with your very latest nightly (2.7.1._180807), there appeared only one little fault, which is about this:
In the filled-in appended file (of several GB in size) [MPEG2 as recorded, to be saved in your MPEG TS(ff) format], while on search for a definite point in play-mode, the stop-button makes the actual-position jump back to the very beginning of the file (though the last active frame remains momentarily seen). This rather hampers A/B markers to insert. The phenomena happens rather random: at least 5 items responded so, several of them more than once.
My practice to overcome this is as follows: the stopping-position should be changed, and navigation has to be brought to the desired point by using the forward/backward jump/fine-tune buttons instead of play/stop.
An error message of "error seeking to xxx ms" used to appear earlier randomly too (though without any discernible problem in the afterwards) now didn't make a show.
Since you are strongly bent to make improvements, let me repeat another small point that would be easy to incorporate and is sure to offer comfort for the user. The practice in my processing always starts with appending quite a number of files (that are "sequential files" of the same film, broken into 1GB parts by the inherent workings of the recording device), which is a prerequisite for a proper job, but rather tedious on a large scale. A conditional branching incorporated in your program to offer an option for circumventing this and done automatically would probably not disturb anything already in place.

[eumagga0x2a]

The promised check for remaining blemishes:
On working up today the newly gathered material (approx. 30 items) but now with your very latest nightly (2.7.1._180807), there appeared only one little fault, which is about this:
In the filled-in appended file (of several GB in size) [MPEG2 as recorded, to be saved in your MPEG TS(ff) format], while on search for a definite point in play-mode, the stop-button makes the actual-position jump back to the very beginning of the file (though the last active frame remains momentarily seen). This rather hampers A/B markers to insert. The phenomena happens rather random: at least 5 items responded so, several of them more than once.

Please reproduce the issue and provide compressed admlog.txt from that Avidemux session. When stopping playback, Avidemux tries to seek to the timestamp of the last displayed frame (earlier, it displayed the last decoded frame which was equivalent to jumping 8 frames ahead). If this seek fails, it falls back to the old behaviour.

Since you are strongly bent to make improvements, let me repeat another small point that would be easy to incorporate and is sure to offer comfort for the user. The practice in my processing always starts with appending quite a number of files (that are "sequential files" of the same film, broken into 1GB parts by the inherent workings of the recording device), which is a prerequisite for a proper job, but rather tedious on a large scale. A conditional branching incorporated in your program to offer an option for circumventing this and done automatically would probably not disturb anything already in place.

Please provide the exact size in bytes of the chunks of the stream your recoding device is producing. You could also install Linux and build Avidemux from source (which is trivial at least on Ubuntu) with "#if 0" at avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsIndex.h:47 changed to "#if 1" to get the desired old behaviour.

[EFuggerth]

With a new batch of film to archive having gathered and available for processing I went to the task to locate and document failure-action, as you asked.
In this, I thought to save you space & trouble, so, on finding a non-normal action I started a fresh Avid-session with the problematic-item, but the previously observed failure did not occur on repeating. Hence, the here presented admlog.txt file is a bit longer: it is the second film in the session where the problem occurred – and must have left its trace on the txt-record. I keep both complete film source-files and the full adminlog.txt as well for a while, but you required only its .ZIP version, which I supply: https://we.tl/t-de4hekQjyY The failure itself as I observed was the same I previously have already described. Namely: On a search for the declared end of the film in a manually appended file in play mode a press on the stop button has brought the time-marker back to the very beginning – instead of remaining (practically) were it previously was.
On appending:
So far as I can fathom, an exact size down to the bit does not exist for the chunks. The recording device is said to break longer items into 1GB portions + the remaining, and stores them in a folder. Since this feature did not changed and (optional) automatic appending was a problem-free part of your older versions, I can hardly imagine anything to hamper you from reinstalling this optional feature anew. I would rather remain a happy end-user than messing in your prime job.

[eumagga0x2a]

On a search for the declared end of the film in a manually appended file in play mode a press on the stop button has brought the time-marker back to the very beginning – instead of remaining (practically) were it previously was.

This happens when the stream is corrupted (numerous occurences of "PTS going back" in the log indicate a damaged stream) at the spot where the playback stops. The following seek back to this spot fails in somewhat unexpected way, I must look into it first to be able to judge whether it is easily fixable.

The recording device is said to break longer items into 1GB portions + the remaining

I need the exact number of bytes, "1GB" is not precise enough.

(optional) automatic appending was a problem-free part of your older versions

It wasn't.

I can hardly imagine anything to hamper you from reinstalling this optional feature anew.

If you build Avidemux yourself (which is trivial on Linux), it is just a question of chaning a "0" into "1" at the location in the source I already mentioned. To safely re-enable the prompt in official builds, I need a more or less reliable indicator for a heuristic detection like the (exact) chunk size.

[EFuggerth]

Data to help find a "reliable indicator for a heuristic detection like the (exact) chunk size" is in the ttached Table/picture.
My present OS is Win7 (Ubuntu's flexibility as regards to Avidemux is thus off), and each of your freshly installed nightly would force me to repeat intrusion. Thus, I'd be better off with your solution.