No announcement yet.

TrueUpdate files not accesible on new server

  • Filter
  • Time
  • Show
Clear All
new posts

  • TrueUpdate files not accesible on new server

    We've been using TrueUpdate for a while and it's been successfully working through a series of updates for several of our programs. Throughout this period it's been accessing the *.tu* files from the same download server, using HTTP.

    Recently we've had to switch to a new download server and for reasons I can't fathom TrueUpdate doesn't seem to be able to see any of its files on the new server (we've moved the old domain name over to the new server, so the URLs it needs to resolve should be identical to what they were before).

    The new server's been set up so that .ts1 and .ts2 files have MIME type application/zip, .ts3 have application/octet-stream

    All of the .ts files can be detected and downloaded via regular web browsers if you enter their URL.

    Could anyone advise on possible causes for this problem? Or which diagnostics to add to pin down the cause?

  • #2
    Perhaps the old server was running Windows and the new one is on Linux or BSD, and you have a problem with the filename of something you are attempting to download? While on Windows "FileName.ext" and "filename.ext" could be downloaded, on the Unix family you wouldn't be able to download the file if the exact file name (or path) isn't being used in the TrueUpdate client download request.

    You may want to inspect the update log file, and check what it tells you. If it doesn't show enough, then log more info in the next session - what URL you are actually using, and copy and paste that info into the browser to replicate the download attempt. You could attach the update log file here, showing the exact error message and code your received.

    Finally, if you are using authentication data, make sure they are still current, and that the username/password hasn't changed.



    • #3
      Thanks for getting back to me so quickly, Ulrich

      Well worth checking, but I don't think this is a file case problem - both old and new servers are Windows-based, and just to be sure I've attempted to download a file via a browser with some characters' case deliberately changed and that worked fine.

      No authentication data are/were being used with either version of the servers.

      After checking and doing some extension of the logging scripts, the highlighted text below looks it's the error message you were after; the line generating this was added to the end of the Download Server Script dialog's "On Start" section:

      [10/30/2014 13:54:00] Success Update started: L:\Patches\Output\XXXUpdateClient.exe
      [10/30/2014 13:54:00] Notice Update engine version:
      [10/30/2014 13:54:00] Notice Product: YYYY
      [10/30/2014 13:54:00] Success Language set: Primary = 9, Secondary = 1
      [10/30/2014 13:54:00] Success Include script: _TU20_Global_Functions.lua
      [10/30/2014 13:54:00] Success Display screen: Welcome
      [10/30/2014 13:54:01] Success Display screen: Download Server Script
      [10/30/2014 13:54:01] Attempting download from ZZZ Download Server 1
      [10/30/2014 13:54:01] Error Script: Download Server Script > On Start, [116]: return true; (3603)
      [10/30/2014 13:54:01] An error occurred when trying to read the server file. (Mismatched encryption key?)
      [10/30/2014 13:54:01] Success Display screen: Download Server Script Failed
      [10/30/2014 13:54:02] Success Run client data event: Client Script
      [10/30/2014 13:54:02] Notice Exit update process (Return code: 5)
      ...unfortunately I haven't been able to work out the script statement needed to get the full URL that's being requested here - I'd be happy to put that in if you could point me in the right direction.

      The error message does suggest a file corruption problem, but I've run binary comparisons of the new server's copies of the files (after downloading with a web browser) and they appear to be identical to the originals.


      • #4
        Hi Ian,

        as you got an encryption error, the URL used in the client is probably correct, or you would get a "file not found" error. This is an interesting problem, and I can't see how you could get this error message when you state that a binary comparison didn't show differences.

        If you have product maintenance, please open a support ticket in the Customer Portal and attach the project file, the latest *.exe and *.dat file (you can zip everything into a single file and send it when submitting the ticket). If you don't have maintenance, you can contact me privately if you want - please see my signature.



        • #5
          Thanks Ulrich - private message sent!