Library manager installations failing with 'CRC doesn't match. File is corrupted' errors.

[tdicola]

Recently we saw some support issues in Adafruit's forums that people are getting an error when installing a library with Arduino's library manager. Trying it ourselves we also repro the same issue, it appears all library installations are failing with the error 'CRC doesn't match. File is corrupted.' This happens for Adafruit and non-Adafruit libraries and feels like it's perhaps a global issue with the server that manages the library downloads. Can someone from the Arduino side check that the library manager server is in a good state and if libraries like Adafruit_NeoPixel can be installed using the manager?

Also apologies if there's a better escalation path but I wanted to raise this issue in case someone sees it more easily.

[ffissore]

Libraries get downloaded directly from github releases. I see only two possible reasons for the CRC check to fail: either some of these libs (and their tags) were force pushed or github changed way of generating the zip files.
We fail in both cases because they are happening outside of us. I fear the only solution is to regenerate the whole list from scratch.

[follower]

Sometimes "transparent" proxies are known to do strange things with archive files--but mainly .tar.gz style.

Can you use wget or curl to download the file and verify the CRC file manually to see if something similar might be happening?

[ffissore]

We don't have a proxy and the zip file from Adafruit's AHRS lib has a different sha256 than the one posted on the lib list. I'm regenerating that one lib only to see if this works around the problem

[follower]

I was meaning a proxy between the person who is downloading the file and the server--not on the Arduino side. Home ISPs frequently put "transparent" proxies in place to reduce bandwidth use.

Totally might not be the case here but thought I'd mention it because it's annoying to track down if you've not encountered it before. :)

[ffissore]

Ok, lib list regenerated. No CRC error should occur anymore

[nestorsilk]

Got this error several times till I found out that regarding the compressed package file ( '.zip', or 'tar.bz2', ...) the link was set to the blob file and not the raw file. So take care always referencing the raw files. Otherwise the github zip-compressor will add data to you binaries. Knowing about this makes it easy to avoid the CRC mismatch error.

[BrentWilkins]

Same story with trying to use the raw links of this format: .tar.bz2?raw=true. The IDE seems to rely on the hash and the name. (Forget the details exactly)

[tdicola]

Interesting, thanks for kicking off a regeneration of the library list and hashes. Looks like all the library installs are working again for me. Hopefully it was just a one-off that github changed the contents of the zips.

[ffissore]

@nestorsilk AFAIK when downloading a release (tag) there are no raw files: github generates the zip.
@tdicola should this happen again, we'll have to tackle the problem regularly. One first workaround will be to regenerate the list daily or something.

[thinkyhead]

Looks like the library list might need to be regenerated again…

I'm seeing this in Travis-CI when we try to use the Arduino built-in install method.
The command is failing, citing a bad CRC.

Verifying archive integrity...
java.lang.Exception: CRC doesn't match. File is corrupted.
    at cc.arduino.contributions.DownloadableContributionsDownloader.download(DownloadableContributionsDownloader.java:77)
    at cc.arduino.contributions.libraries.LibraryInstaller.install(LibraryInstaller.java:97)
    at processing.app.Base.<init>(Base.java:415)
    at processing.app.Base.guardedMain(Base.java:223)
    at processing.app.Base.main(Base.java:136)
The command "arduino --install-library "U8glib"" failed and exited with 255 during .