More robust manifest handling in TPD4

DHawthorne

I'm going crazy with a long-distance remote system that has a flaky Internet connection. I was doing well with updates for most of the day yesterday, but all of a sudden, it started dropping me every two minutes or so - unfortunately, right in the middle of a TPD4 transfer to 4 panels. All of the panels on site are now corrupted, and I cannot get a full upload to any of them. What is really frustrating is that I can often get 80-90% of the transfer done before it fails, but once it does, TPD4 insists on attempting the whole thing because the manifest wasn't updated. So a subsequent pass might leave me in worse shape than before.

The manifest files are not huge - how about (maybe as an option) sending an updated manifest after each successful individual file transfer? That would essentially give us a resume upload capacity, and would help a huge deal when there are connection issues outside our control.

DHawthorne

Oh, and another thing - why does TPD4 insist on resending fonts when all I have changed is button channels? It doesn't seem to happen all the time, but it happens often enough, and they are often the largest files in the panel.

kphlight

I don't see why the TP doesn't generate the manifest itself after xmit and send it to the uploader. Wouldn't this allow for a 'checksum' of all files to be generated and thus verified? Then, should a fault be found, the client would know to resend file 'x' if its checksum didn't compute.

kphlight

Oh, and another thing for me as well - generating the manifest on the server side (TP) would solve Dave's problem as well; a dropped connection would still generate an, albeit wrong, manifest. Next upload would only send the diffs.