Test/Try altogether:
Not using a browser’s conventional %USERPROFILE%\Downloads folder.
Use: C:\DownloadsFldr
AND, not involving/using Brave Sync
AND, Brave not being default browser
RESTART computer after making changes; then test.
I suspect any of:
a) byte count is wrong
b) byte accounting error
c) compressed/encoded responses
d) server issue near/at end zone
e) final naming failure detected
f) browser distracted / loses focus
ChatGPT:
Chromium is unusually capable of instrumenting this at exactly the level we’re interested in. In fact, Chromium’s own download diagnostics were designed to answer questions very much like ours.
Chromium’s download object explicitly tracks total_bytes, received_bytes, download state, interruption reason, paths, and other metadata. Its debug representation can dump those values together.
More importantly, Chromium has a download-specific tracing category.
We can watch the train
Chromium’s documentation says to use its tracing facility and enable the download category. The resulting trace contains events such as:
And those events can be associated with the individual download ID.
In particular, Chromium logs the byte count
The source shows DownloadItemUpdatedbeing emitted with:
bytes_so_far = GetReceivedBytes()
and the interruption event records both the interrupt reason and the bytes so far.
So instead of looking at the progress bar and guessing, we can potentially obtain:
Content-Length / expected:
X bytes
Chromium received:
Y bytes
DownloadFile wrote:
Z bytes
DownloadItem state:
...
Interrupt reason:
...
Final filesystem size:
...
Rename:
SUCCESS / FAILURE
Completion:
YES / NO
That would let us answer your earlier question - “were the last bytes actually received?” - with evidence.
There’s an especially juicy piece
Chromium has an explicit OnAllDataSaved()path. When it believes all data has been saved, it sets all_data_saved, updates the total byte count, and calls UpdateProgress(total_bytes, 0). It also has explicit instrumentation around content-length mismatches.
That means Chromium is not blindly counting bytes. It has logic specifically concerned with whether the data saved corresponds to the expected content length.
And the persistent download database has separate fields for:
-
received_bytes
-
total_bytes
-
state
-
interrupt_reason
-
hash
-
end_time
so this information is retained as download state, not merely displayed temporarily.
I think we can do a very decisive experiment
For one of your problematic large downloads:
-
Start Chromium/Brave tracing with the download category.
-
Start the large download.
-
Let it fail in the characteristic way.
-
Stop the trace.
-
Examine the final sequence.
We’re looking for something like:
DownloadItemUpdated
bytes_so_far = 23,999,999,744
DownloadStreamDrained
DownloadFileRename
.crdownload → final
DownloadItemCompleting
bytes_so_far = 23,999,999,744
DownloadItemInterrupted
interrupt_reason = ???
bytes_so_far = 23,999,999,744
versus:
DownloadItemUpdated
bytes_so_far = 24,000,000,000
DownloadFileRename
SUCCESS
DownloadItemCompleting
bytes_so_far = 24,000,000,000
DownloadItemFinished
Those two traces would tell very different stories.
And there’s an even better comparison
Do the same download twice:
Then compare the last few hundred milliseconds of the traces.
That gives us a known-good train and a derailment, with Chromium itself telling us what happened to each.
Chromium has the instrumentation necessary to determine whether the failure is in receiving bytes, writing bytes, recognizing end-of-stream, content-length reconciliation, finalization, or some later state transition.
For this particular investigation, I would use Chromium’s older but very useful chrome://tracing facility, because Chromium’s own download documentation specifically identifies the download tracing category and the download-specific events we care about.
Start tracing
In Chrome or another Chromium browser:
-
Open a new tab.
-
Enter:
chrome://tracing
-
Click Record.
-
Choose Manually select settings.
-
In Record Categories, select download.
-
Ideally, uncheck the other categories so we don’t drown the useful download events in unrelated data.
-
Click Record.
Those are essentially Chromium’s own documented instructions for capturing download traces.
Then switch to the download tab and perform the problematic download.
For our experiment, I’d actually let the download run all the way through the failure. We don’t care about the usual “10 seconds or less” recommendation here - that recommendation is aimed at performance investigations; our event is the download itself. Chromium’s download documentation specifically describes tracing download events.
Stop tracing
Once the failure has occurred:
-
Return to the chrome://tracing tab.
-
Click Stop.
-
Chromium will load the captured trace.
-
Click Save.
-
Save the resulting trace file, normally as JSON.
Chromium documents the Stop → Save process explicitly.
What we’re looking for
This is the important part.
Chromium’s download tracing includes events such as:
So the trace can show the actual sequence of events, rather than us inferring it from the progress bar.
For your particular failure, I would want to find the sequence around:
DownloadItemUpdated
↓
DownloadStreamDrained
↓
DownloadFileRename
↓
DownloadItemRenamed
↓
DownloadItemCompleting
↓
????
And especially whether we see:
DownloadItemInterrupted
after the rename.
The numbers matter even more
Chromium’s download instrumentation records the number of bytes received in its download-update events, and interruption events containthe bytes-so-far information.
So we’re trying to establish something like:
Expected: 24,123,456,789
Received: 24,123,456,789
File on disk: 24,123,456,789
versus:
Expected: 24,123,456,789
Received: 24,123,456,000
File on disk: 24,123,456,000
Those mean very different things.
And there is an additional event that I’m particularly interested in:
DownloadStreamDrained
Chromium specifically identifies that as one ofthe events associated with download-file processing.
That gets us much closer to answering your original:
Were the last bytes actually received?
rather than merely:
Did the progress indicator reach 100%?
One important caution
Don’t upload the trace anywhere yet.
Chromium warns that traces can contain information such as URLs and titles of open tabs, subresource URLs, extension IDs, and hardware-identifying information.
For our purposes, just save the trace locally.