Spitfire Audio app download problems

[blaggins]

I have created a support ticket already but wondering if anyone else is having major issues with the Spitfire Audio app and downloading their libs. I had to reset a few libraries b/c one of my SSDs died on me, so I'm attempting to re-download a few things. Nothing seems to be working though.

The app is showing a consistent 200+ Mbps download speeds, but there's not an equivalent amount of disk write traffic to suggest anything near this rate and nothing is actually getting written to the content folders.

In the app logs I see lots of things like:
2024-02-29 15:37:43.174085 [33980] [I] part 72249: downloading E:\Spitfire Audio 3\Spitfire Uist library\72249.part
2024-02-29 15:37:43.174088 [33980] [I] part 72249: configured to use CloudFront endpoints
2024-02-29 15:37:43.174089 [33980] [I] part 72249: using cookie auth for CloudFront URL
2024-02-29 15:37:43.174093 [33980] [I] part 72249: downloading from CloudFront
2024-02-29 15:37:43.174119 [3556] [I] part 7241: expect filesize 0
2024-02-29 15:37:43.174120 [3556] [I] part 7241: actual filesize 0
2024-02-29 15:37:43.174170 [33980] [I] part 72249: Local file does not exist
2024-02-29 15:37:43.174177 [33980] [I] part 72249: there is more to download
2024-02-29 15:37:43.174222 [3556] [I] part 7241: expect checksum
2024-02-29 15:37:43.174223 [3556] [I] part 7241: actual checksum d41d8cd98f00b204e9800998ecf8427e
2024-02-29 15:37:43.174227 [3556] [I] part 7241: verifying failed, removing and starting again
2024-02-29 15:37:43.174285 [33980] [I] part 72249: downloading
2024-02-29 15:37:43.174386 [3556] [I] part 72352: verifying
2024-02-29 15:37:43.174403 [3556] [I] part 72352: expect filesize 0
2024-02-29 15:37:43.174405 [3556] [I] part 72352: actual filesize 0
2024-02-29 15:37:43.174432 [3556] [I] part 72352: expect checksum
2024-02-29 15:37:43.174434 [3556] [I] part 72352: actual checksum d41d8cd98f00b204e9800998ecf8427e
2024-02-29 15:37:43.174435 [3556] [I] part 72352: verifying failed, removing and starting again

Anyone come across anything like this before? I'm not getting any kind of authorization issues that I can tell, I even tried logging out and back in again

@SpitfireSupport ?

Click to read more...

 

[aldous]

That checksum is the md5 hash you get from an empty file. Do those *.part files actually exist in the library folder? Have any previous .parts succeeded? If not, could be a permissions issue on the new disk, see here. If they do exist, then you could try pausing the download, deleting the .part files it's stuck on, and re-start.

Of course, if the problem isn't local - e.g. if Spitfire's server is giving you bad data - then you'd need to wait for support to get back to you.

 

[blaggins]

Thanks @aldous , I did have that thought actually. The permissions allow anyone to create/modify/delete anything (I'm on Windows too) and I can verify that files *are* getting created. But they are also getting deleted pretty much immediately. I suspected Windows Defender as well but the entire drive is in my exclusions list already.

For example, there are moments when I can see part files like this but then they get deleted and new ones show up (only to also get deleted).



I'm wondering is some sort of auth is screwed up between the Spitfire Audio app and Cloudfront CDN (seemingly their first preference). I can sometimes see messages failing over to S3 but there are different errors when that happens.

 

[aldous]

and I can verify that files *are* getting created. But they are also getting deleted pretty much immediately. I suspected Windows Defender as well but the entire drive is in my exclusions list already.

Did you pause the download and delete failing parts? Did it keep doing the same thing?

Otherwise, you really want to be sure who's doing what: I would expect successfully-downloaded part files to get deleted as they're merged, and for 0kb parts to get deleted by the app when checksum fails. To be sure, though, you need to check lm.log. You can also check the Windows Defender log to be sure it's not interfering.

I'm wondering is some sort of auth is screwed up between the Spitfire Audio app and Cloudfront CDN (seemingly their first preference). I can sometimes see messages failing over to S3 but there are different errors when that happens.

What are the different errors? (I'm not sure it's failing over to S3 necessarily: CloudFront and S3 are often part of the same stack at the AWS end.)

Any VPNs, bonded DSL lines, firewalls, load balancers, internet proxies, or other network funny business going on that might be changing your IP or messing with http traffic? The auth looks to succeed, and after that it's pretty mundane... switching IPs mid-transaction is the only thing I've seen break it.

 

[Ivan Duch]

I always get issues with their downloader. Normally it gets stuck but it still says it's still downloading. On my end, it gets fixed by pausing and resuming the download.

 

[blaggins]

Well for what it's worth I've tried restarting, using different library locations on different drives, and even re-installing the Spitfire Audio app. Unfortunately the results are the same. I get the app telling me that it's downloading at a very healthy clip, but all of the part files only show up for a sec, and then disappear, and data isn't actually accumulating anywhere.

At some point in the download, it will just get "stuck" around a certain downloaded size, like so:

Note how the "downloaded" size doesn't at all match what is actually in the directory. I've downloaded so many spitfire libs over the years and nothing like this has ever happened.

What are the different errors? (I'm not sure it's failing over to S3 necessarily: CloudFront and S3 are often part of the same stack at the AWS end.)

Here's an example of the S3 failover error I was referring to:

2024-02-29 19:21:34.619860 [7344] [I] part 839938: downloading F:\Spitfire Audio\Spitfire Symphonic Woodwinds library\839938.part
2024-02-29 19:21:34.619861 [7344] [I] part 839938: configured to use CloudFront endpoints
2024-02-29 19:21:34.619864 [7344] [I] part 839938: using cookie auth for CloudFront URL
2024-02-29 19:21:34.619868 [7344] [I] part 839938: downloading from CloudFront
2024-02-29 19:21:34.620013 [9104] [I] falling back to older request system
2024-02-29 19:21:34.620383 [7344] [I] part 839938: Local file does not exist
2024-02-29 19:21:34.620391 [7344] [I] part 839938: there is more to download
2024-02-29 19:21:34.620494 [7344] [I] part 839938: downloading
2024-02-29 19:21:34.621542 [21368] [I] part 839937: verifying
2024-02-29 19:21:34.621563 [21368] [I] part 839937: expect filesize 262144000
2024-02-29 19:21:34.621565 [21368] [I] part 839937: actual filesize 262144000
2024-02-29 19:21:34.705791 [12896] [I] Response from
2024-02-29 19:21:34.705796 [12896] [I] Via:
2024-02-29 19:21:34.705798 [12896] [I] X-Amz-Cf-Id: {redacted}
2024-02-29 19:21:34.705798 [12896] [I] X-Cache: Error from cloudfront
2024-02-29 19:21:34.705967 [9104] [I] part 41: download completed with http status 403
2024-02-29 19:21:34.705977 [9104] [I] part 41: finished downloading
2024-02-29 19:21:34.706028 [9104] [I] part 41: 403 detected, falling back to S3
2024-02-29 19:21:34.706030 [9104] [I] part 41: requesting S3 URL
2024-02-29 19:21:35.088046 [21368] [I] part 839937: expect checksum 7862ffb78b31fec47030119caf16c389
2024-02-29 19:21:35.088051 [21368] [I] part 839937: actual checksum 7862ffb78b31fec47030119caf16c389
2024-02-29 19:21:35.088075 [21368] [I] part 839937: verifying complete
2024-02-29 19:21:35.116442 [7344] [I] part 839938: download progressing (10.0 MB)
2024-02-29 19:21:35.401519 [9104] [I] part 41: failed to get part URL, You don't have permission to download that library.

The "you don't have permission to download" is very suspicious as the Spitfire App is showing everything as normal. I was wondering if the "falling back to S3" thing is maybe an untested download path and something is just not authenticating to Cloudfront correctly...

 

[blaggins]

Just for fun I tried downloading Uist from another computer which has never had any virtual instruments or any Spitfire software installed on it, so it's totally unburdened by any funky config could be messing things up on my Windows machine. Also it's a Mac, and of course has a different network interface so we can eliminate any networking hardware problems. So we're talking like a totally new set of criteria to work with.

Sadly, it's the *same exact behavior*. I'm starting to suspect this isn't a local issue but a Spitfire issue with entitlements or account permissions or something of that nature. :(

 

[tosza]

Same issue here (with HZ Percussion Pro), also created a support ticket.

 

[Paj]

I downloaded SSO 2024 yesterday (319GB) without any issues.

Paj
8^|

 

[aldous]

Also it's a Mac, and of course has a different network interface so we can eliminate any networking hardware problems. So we're talking like a totally new set of criteria to work with.

Not totally new - it's still the same network and internet connection, which is where I suspect the problem would be if it's on your side at all. Without knowing what you did/didn't confirm in the logs re: file moves and deletions, it's difficult to say more: if your install and download paths were different, then I'd expect successful parts to disappear as they're merged. If some are succeeding, whilst a few failing, then that might point more towards bad data or a bad endpoint on Spitfire's side.

 

[Henrik B. Jensen]

I downloaded SSO 2024 on launch day which went fine.

Now I'm trying to download the "old" SSS Professional and it's not working.
It gets to 7.80 GB downloaded, then it returns back down to 7.65 GB downloaded. And it stays looping like that.

 

[blaggins]

I downloaded SSO 2024 on launch day which went fine.

Now I'm trying to download the "old" SSS Professional and it's not working.
It gets to 7.80 GB downloaded, then it returns back down to 7.65 GB downloaded. And it stays looping like that.

Yup that is exactly what I see as well, in the app. Are you getting the correct amount of data in part files actually placed into your local directory?

 

[Henrik B. Jensen]

Yup that is exactly what I see as well, in the app. Are you getting the correct amount of data in part files actually placed into your local directory?

I'm not sure but I just closed the computer for a few hours doing other stuff and now when I boot it again and start the Spitfire app, the download doesn't continue, it starts from scratch as if nothing had been downloaded earlier. Very weird!

 

[RogiervG]

@SpitfireSupport @Spitfire Team Any idea?

 

[jbuhler]

I'm not sure but I just closed the computer for a few hours doing other stuff and now when I boot it again and start the Spitfire app, the download doesn't continue, it starts from scratch as if nothing had been downloaded earlier. Very weird!

Did you point the download at the same location as the first time? It won’t default to the previous location (unless you always install at the default location).

 

[Henrik B. Jensen]

Did you point the download at the same location as the first time? It won’t default to the previous location (unless you always install at the default location).

It defaults to the previous location - I go in and set it every time before starting a new download, because I usually download to different drives all the time.

 

[jbuhler]

It defaults to the previous location - I go in and set it every time before starting a new download, because I usually download to different drives all the time.

It doesn’t default to the previous location. It’s a significant shortcoming of the app that it doesn’t. You have to direct it where it needs to go and sometimes you need to direct it at the folder and sometimes the folder above the folder. That’s also a significant problem with the design of the app. In any case if you did have it set up right that doesn’t explain why it restarted the download from scratch.

 

[Henrik B. Jensen]

It doesn’t default to the previous location. It’s a significant shortcoming of the app that it doesn’t. You have to direct it where it needs to go and sometimes you need to direct it at the folder and sometimes the folder above the folder. That’s also a significant problem with the design of the app. In any case if you did have it set up right that doesn’t explain why it restarted the download from scratch.

But when I click on Settings and look at Default Content Path, it's the same I set before quitting and restarting the Spitfire app??

I'm confused

 

[jbuhler]

But when I click on Settings and look at Default Content Path, it's the same I set before quitting and restarting the Spitfire app??

I'm confused

You can set the default path, but that's different from either the previous location or (in most cases) where you want it installed, because as you note most have their libraries scattered around. When installing a new library, the default location will work to put the library there, but it doesn't work, say, to install updates. And most (but not all) updates require selecting the folder above the install folder. So it is relatively easy to make a hash of a library's organization, though fortunately they still usually work if that happens.

But to come back to your situation: if you don't direct the app to install the library in the same location you started downloading, it will in fact restart the download from scratch. That is expected behavior. So my thought was that perhaps when you restarted the download the app started to download in a new location, most likely the default location, whereas for your previous download you'd started that in a different location.

 

[Henrik B. Jensen]

You can set the default path, but that's different from either the previous location or (in most cases) where you want it installed, because as you note most have their libraries scattered around. When installing a new library, the default location will work to put the library there, but it doesn't work, say, to install updates. And most (but not all) updates require selecting the folder above the install folder. So it is relatively easy to make a hash of a library's organization, though fortunately they still usually work if that happens.

But to come back to your situation: if you don't direct the app to install the library in the same location you started downloading, it will in fact restart the download from scratch. That is expected behavior. So my thought was that perhaps when you restarted the download the app started to download in a new location, most likely the default location, whereas for your previous download you'd started that in a different location.

Ok! I just saw the download go from 7.80 GB downloaded back down to 7.57 GB though. It's crazy! It's got to be the Spitfire app that is bugged, or what?