I am having that exact problem in an application I am developing.
Display a progress bar for downloading, and then another one for processing. You can caption them, too.
A progress bar will usually present the "expected" duration of several operations, [almost] none of which have a deterministic duration, or a deterministic ratio from one to the other. The best we can do is put heuristics in place to estimate how long the operations will take. We have some choices, such as estimating the total time or estimating each sub-operation separately. We can even use AI for the estimation, if we want to get fancy. But the problem is not tractable, and we'd rather given estimates where we can that just use spinners everywhere.
This would be pretty uncomfortable.
What train riders (and users) are interested in is how long a thing should take in principle as well as clues about whether they are on track. When reality differs from that it is ok, as long as the ETA is somewhat in the ballpark area of the actual time of arrival.
In the now gone days of usability, it was considered good practice to annotate the progress bar of a complex task by displaying textual information regarding the sub-task and the progress made. This could be considered here as well. (E.g., "Loading data, estimate: 3.4 secs.")
wget has a progress bar, and it works perfectly fine.
EDIT: Though, if the server does not have a Content-Length header, you will get an indeterminate progress bar (a kind of spinner, I suppose) in web browsers, if that's the kind of thing you mean?
The normal case is that bandwidth throughput can be estimated well enough to make humans happy. But a broken network throws that out the window and will do its best to find ways to make your progress bar behave weirdly.
I can't remember what it was, but there was a Mac app a very long time ago (System 7 era, in the 90s) - maybe a news reader? - that would eventually hide the progress bar and show a message about bad networking when that happened.
You have one progress bar showing progress for this floppy, and another showing progress for the entire operation.
I was merely constructing a case for using fancy progress bar calculations. And conflating two non related operations into one might be one of those.
It's probably easier to visualize than describe, but I have longer descriptions on the thinking behind it on my blog/GitHub repo. Unfortunately, my demo site succumbed to JS CDN bit rot and I keep forgetting to update the demo to something more recent.
(ETA: Forgot the link: https://github.com/WorldMaker/compradprog Also thought I could point out that the idea mostly jives with the findings in the paper here.)