There are multiple things which currently have no visible progress:

1. Saving the initial replay file, this is (with the current format) dominated by compression. We can derive a progress value for this because we can estimate how many bytes need to be compressed by looking at the temporary files and the original zip entries, and then we can just count how many of those we've stuffed into the ZipFile so far. There is already a dedicated issue for this: #454
2. Saving of processed (start/stop/pause/resume) replays. For these, we don't need to be able to write to multiple entries at once, so we should be able to skip the temporary file completely and compress as the packets are being processed.
3. During processing, when a recording is unpaused, the compacted (non-redundant) packets collected while it was paused all need to be written out. We should be able to relatively quickly total up their size and can thereby estimate a progress value for that bulk write. Not entirely sure how to splice that progress into the overall progress. One seemingly decent option would be to slow down overall progress (e.g. to half the speed) while processing the paused section (cause that's effectively only read, no write), so we can use the other half when unpausing (which is only write, no read; and while write is generally slower, there'll generally be less to write because redundant packets have been pruned).
4. During processing, when a new recording begins, the compacted (non-redundant) packets collected so far all need to be written out. Very similar to 3. except that splicing this progress into the overall progress is a lot harder because there's not really a corresponding "paused section" (there may or may not be a paused section before the new recording starts, but in any case the entire compacted recording up to that point that needs to be written out). Best thing I could come up with is tracking the total bytes remaining in the input replay, so we know roughly how many bytes will still need to be written out (assuming there were no cuts), and we can estimate how many additional bytes we need to write now, so we can split the remaining percentage between these two (probably with some weight, cause we also need to read the overall remaining bytes, but we've already done that with the additional ones).

And #685

No, that issue is invalid for reason explained in that issue...