Autodownloader files not verified

[Teric neDhalir]

Meh. I've started having problems when autodownloading updated files from WHL. I get an error message saying "the file was downloaded successfully but cannot be verified". As I've just rebaked the area, re-staged, copied the new .lzma file to the correct place and uploaded the changed files to the host machine in the same way as I've been doing for the last three years I'm a bit stumped. This is on more than one area, BTW.
Anything peculiar going to have happened in the last hak update, for example?

Cheers,
T

[Zelknolf]

Nothing we've changed in the hak updates would change the way that the autodownloader works-- I would say to check your download folder, sort on file size, delete anything that's 0 bytes, restart the client, and try again.

If that fails, we start looking at hashes.

[Curmudgeon]

This issue is usually due to a problem in the moduledownloadresources.xml file, usually a mismatch between the hash for the actual hosted file and the xml. AL is more familiar with this issue than I am. The on-screen ADL dialog while you're downloading will tell you which file is having issues.

[Teric neDhalir]

Nothing we've changed in the hak updates would change the way that the autodownloader works-- I would say to check your download folder, sort on file size, delete anything that's 0 bytes, restart the client, and try again.

The downloaded file isn't 0 bytes, it's the .lzma file (of the correct size) but it's not been unarchived.

This issue is usually due to a problem in the moduledownloadresources.xml file, usually a mismatch between the hash for the actual hosted file and the xml.

Original module version;
-<resource urlOverride="" exclude="false" critical="false" size="10311168" dlsize="2771323" name="{dm} forestofwyrms.trx" downloadHash="F50F3D6646980BD13A59F454F3E68D869B21D54F" hash="5B0DA4304F282D7AA9A528C96EB7F1EBCB790E51" type="DirectoryEntry"> -<server-ref> <string>0</string> <string>3</string>

Staged server files version (on my machine);
-<resource urlOverride="" exclude="false" critical="false" size="10311168" dlsize="2771323" name="{dm} forestofwyrms.trx" downloadHash="F50F3D6646980BD13A59F454F3E68D869B21D54F" hash="5B0DA4304F282D7AA9A528C96EB7F1EBCB790E51" type="DirectoryEntry"> -<server-ref> <string>0</string> <string>3</string> </server-ref>

Version in host machine module directory;
-<resource urlOverride="" exclude="false" critical="false" size="10311168" dlsize="2771323" name="{dm} forestofwyrms.trx" downloadHash="F50F3D6646980BD13A59F454F3E68D869B21D54F" hash="5B0DA4304F282D7AA9A528C96EB7F1EBCB790E51" type="DirectoryEntry"> -<server-ref> <string>0</string> <string>3</string> </server-ref>

I don't know where else to look!

Thanks
Teric

[Curmudgeon]

Try deleting the offending .trx file on your client machine and logging in.

[Curmudgeon]

Tried to log on a couple of times this evening, I'm seeing the same issue with
{DM} forestofwyrms.trx.lzma that you are, i.e., it tries to get a confirmable copy 3 times and then throws an error halting further downloads.

In addition, I noticed that a number of other area files were throwing 404 errors on their first attempts to download the files (travel_x07.trx for one), indicating File Not Found on the primary area file server, but were downloading fine from the secondary server. I may have missed it due to the DL messages flying by so quickly, but I did NOT see this error showing for {DM} forestofwyrms.trx.lzma

This hints to me that there may be an older or corrupt copy of "{DM} forestofwyrms.trx.lzma" on the primary server (and missing copies of the other areas as well). Check your servers.xml (generated by "Manage Download Servers") to make sure you've got the primary and secondary area file servers entered properly, and that you've assigned the problematical area to the correct file servers (your listings from moduledownloadresources.xml indicates to me that you've assigned that area to Server 0 as primary and Server 3 as secondary locations.

[Basilica]

Right, what's probably going on is that the copy of that .trx which you have staged is not the same copy that is on the downloader server. So let's try uploading the .lzma to the download server again (and making sure that the same server being referenced for the file is the one that you're uploading the file to).

If that doesn't work, re-stage the file and upload the lzma again.

The hash mismatch message means that it downloaded the file, but it was the wrong version of the file.

[Zelknolf]

Did the mirror get updated?

[Teric neDhalir]

Is there any other file other than servers.xml and moduledownloadresources.xml that includes the web addresses of the download servers? I've deleted servers.xml and re-specified 1 address for the Haks and 1 for the walkmeshes, then deleted moduledownloadresources.xml and restaged. The new moduledownloadresources file still has pointers to 2 servers per file. If I edit the .xml files by hand I get a "server is not setup for autodownloading error".

Verily it doeth my head in.

[Zelknolf]

Is there a recent version of the mod on one of the FTPs that could be poked at?

[Teric neDhalir]

Is there a recent version of the mod on one of the FTPs that could be poked at?

Not one that's the current vintage that's not working.
I'll have another go at restaging everything, and copying all the files to the download and host servers. If that doesn't work you can have the damn thing permanently.

[Teric neDhalir]

Well, I've deleted everything (build machine/host/ftp), restaged and copied everything back and we seem to be functioning again. *feeble cheer*