Home / Error loading Chrome browser downloads

Hello. Is there a fix for Sumatra usually/often displaying the “Error loading C:…xxx.pdf”

It seems to be a race between the filename getting handed off to Sumatra from Chrome and the file becoming actually readable on the C: drive. My quick fix is to Ctrl+Shift+Right and then Ctrl+Shift+Left to navigate to another PDF in the directory and back again, but could this be fixed?

image1920×1160 55.9 KB

Thank you!

Best regards and aloha, George
Sumatra PDF Latest (3.1.2 64 bit), Dell XPS13 2019 laptop.

Currently most browsers either stream PDF content to display themselves or for products like Adobe Reader you can often add an extension to open stream with … (that route in the past was done by a now depreciated SumartraPDF Netscape plugin)

The current alternative is to download the PDF and use double click to open in system default PDF viewer or right click for a context start-up (I use multiple SendTo)

Within my ungoggled Chrome if I change settings to not display it internally, then it downloads to a link on bottom bar that I can use to Open OR set to Always open with default. So I have to ask is that the way yours is set ?

There have not been masses of users complaining of problems with Chrome downloads so have to presume something is different within your usage.

From your description, it sounds like SumatraPDF is triggered too quickly in a system with some interfering delay. (Anti-Virus?) after a download, but if there is some chrome extension also at play that may need to also be considered.

Personally I either view in or fully download via ChromEdgium, thus wait for intrusive “the file never had a virus anyway” but is going to exclusively block access, till it tells nanny at MS towers what I am reading, Then open the now second hand duplicated stored file.
With old browser plug-in that was much simpler and less secure, (still could have problems) as it opened the remote unvetted file often before it was fully mirrored locally.
However the only browsers that still allows such legacy SumatraPDF plugin behaviour are Waterfox Classic and Pale Moon, and those eventually will retire such fast usage.

Back to the problem:
I doubt, should it be there is a delayed access, that a newer version would make any difference, but SumatraPDF fixes can only be made against latest DailyBuilds
If I am right the solution may be to add a “retry delay variable” before passing the filename into SumatraPDF rendering such as to avoid your workaround method.

Thanks @GitHubRulesOK. I think you may be right about an Anti-Virus download scanner yanking my PDF while SumatraPDF is already trying to open it. Just knowing that much might lead me to a workaround or even a fix if it’s caused by the browser/extension or system.

My Chrome browser is currently set to automatically open PDF downloads, but if I change that to “click the download link on the bottom bar”, that might another workaround. (Probably too much mouse movement for me, though ;( )

I like SumatraPDF’s navigation for PDFs better than most browsers’ PDF renderers, but I do use both.

It would be great if SumatraPDF would solve this problem for me with a fix, but it sounds like that would be most generous if the problem is caused by other software misbehaving.

Thanks for your helpful thoughts/fixes/and workarounds.

Regards and aloha, George.

One way to try a DIY fix would be to hook the start of SumatraPDF.exe and replace with a few seconds delay to test that is the reason.

Personally would try to write a one liner command that is shimmed into the default pdf application slot e.g. run with a delay.cmd file containing something like
Timeout /t 5 & "c:\... path to...\SumatraPDF.exe" %1

However with the way that Win10 reassigns un-hashed or dubious pdf associations back to edge I had never tried that.
I just now set that as my default handler for ALWAYS open pdf with and now there is a delay of 5 seconds when I double click a pdf.

Putting it back to Edge took a while longer as I again needed to search it as if another app to reset as default, but earlier today had done that itself !!

If you can get/prove that to work with your downloads, then it is good reason to request some similar delay be added internally when starting the exe itself.

Nice one-liner @GitHubRulesOK !

I may try exactly that. The other problem is that this timing mismatch is inconsistent, e.g. sometimes repeatedly downloading the same PDF test file just starts working without error So now I try to get it to not work!

Thanks for the ideas and helpful details. I’ll update this thread when I get something to consistently work or not.

Best regards and aloha, George.

I have seen other reports that suggest there could be other background factors affecting downloads such as file format since not all PDFs have the same structure and thus size is not usually a common feature. There was a tweak to aid firefox downloads compared to Iexplorer but that would not help within chrome based browsers.

You know, the easiest solution would be just to have a “Reload” function on the File or View menu, with a handy keyboard shortcut.

I see F5 is already taken by Presentation Mode (a la PowerPoint perhaps)? But Ctrl+R seems to be available, typical Reload shortcut keys.

Any further thoughts? Thanks again.

Best regards and aloha, George.

The unshifted R key is used for reload refresh so I would be trying that first, but that presumes the tab filename is still valid

@George_Webb
On rechecking your visual I see you are using what looks like a stable 3.1.2 (xp compatible) but don’t know if that’s 3rd party portable (could be a factor) or official install (now considered old, but still serviceable, i.e. no enforced update)

Changes can only be made against current pre-release (ideally the daily build)
Thus if you have still not updated, I would backup your older installation (in case you decide to revert) and try
64bit DailyBuilds which should have any better file recognition/handling amendments as the developer often will favour chromium testing.

@GitHubRulesOK huge thanks!

I didn’t realize I was on an old version because my SumatraPDF “Check for Updates” reports that I have the latest version. Apparently not.

So I will try those 3.2 and Daily Builds version and see if they naturally don’t have this file-opening race problem.

OTOH, I might just enjoy the simple unshifted R key to reload the failed document and carry on. That does work, and I’m sorry for missing that that exists; it does not seem to be advertised on a menu. Thanks for suggesting that quick fix!

Best regards and aloha, George.

3.1.2 still is not triggered to be updated and you are right that Refresh was not heavily “promoted” in the past, its mainly used when switching user Interface or by LaTeX editing users. But can help in “cloud” cases when there is a drop in connectivity.