Uploading hundreds of photos from a rural tower site on intermittent cell signal is where field time disappears. A standard single-threaded upload that hits a connection drop has to start over. A system without state tracking can’t tell what already uploaded successfully. On a large dataset at a remote location, these aren’t edge cases — they’re the normal operating environment.
FlightDeck’s QC Uploader handles this with a multi-threaded upload architecture and a persistent SQLite manifest that tracks every file individually. Out of the box, you’ll experience 4x upload processing, adjustable to 10 simultaneous threads.
How the Upload System Works
Phase 3 of the QC Uploader workflow is the AWS S3 upload. Multiple concurrent worker threads run simultaneously, each pulling jobs from the upload queue. Every JPEG and every KML file in the dataset is registered in the manifest database before any upload begins. Workers pick up files from the queue, transfer them to your configured S3 bucket, and report status back as each file completes.
The manifest records four states for every file: Pending (queued, not yet started), Uploading (transfer in progress), Uploaded (confirmed complete), and Failed (transfer did not complete). Each file’s state is written to a local SQLite database — upload_manifest.db in your project root folder — as the upload runs.
Resumable Uploads
When connectivity drops mid-upload, you don’t lose your progress. When you restart the upload, the manifest is read first. Files marked as Uploaded are automatically skipped — they don’t get re-transferred. The workers pick up from the remaining queue and continue.
On a 1,200-photo dataset where 800 photos uploaded before the connection dropped, restarting the upload means 400 files to go, not 1,200. On a rural site with marginal signal, this is the difference between finishing the upload before you leave and having to come back.
S3 Configuration
The upload system connects to AWS S3 using standard credentials: bucket name, region, access key, and secret key — configured in the Settings tab of the QC Uploader. The bucket and credentials are set once and apply across all projects. If you’re delivering data to multiple clients with separate buckets, updating the settings between projects takes about 30 seconds.
Single-Dataset Mode
On a project with dozens of sub-folders, you sometimes need to re-upload a single site — a re-fly, a corrected KML, a client request for a specific tower’s data. The Dataset Selection filter limits the upload to the selected sub-folder without affecting the rest of the manifest. Files in other sub-folders keep their Uploaded status; only the selected dataset is re-queued.
This matters because re-running a full project upload to handle one sub-folder isn’t practical when you have hundreds of sites already delivered. Single-dataset mode makes targeted re-delivery a one-minute operation.
Cancel and Reset
If you need to abort an upload and start fresh — wrong bucket configured, new credentials, dataset needs to be rebuilt — the Cancel and Reset function stops all active workers and clears the manifest after confirmation. The clear is intentional: it requires a confirmation step because clearing the manifest means the next upload will re-transfer everything regardless of prior state.
Upload as the Last Step
The QC Uploader workflow runs in order: EXIF quality analysis, KML generation, then upload. By the time files are queued for transfer, they’ve been checked for aperture, ISO, and GPS coverage, and a color-coded KML has been generated. What reaches your S3 bucket is a reviewed, documented dataset — not raw field photos dumped to cloud storage.
For clients who receive data directly from S3, that means what they download is already organized and annotated. For your own archive, it means every delivery has an associated quality record.