06 The repair workflow

What the app actually does, in order. Every label below is taken from the frozen UI source at commit 8e637cb (app version 0.3.0).

What you see first on the phone

• The top bar reads Video Rescue, the same name as the launcher icon and the store listing. It used to read "File recovery" and print the build version; the version now lives on Settings > About, where support asks for it.

• Three tabs run along the bottom: Recover, Audio, Settings.

• On a fresh install a dialog appears before anything else: "Share anonymous usage data?" with Allow and Don't allow. One decision covers analytics and ads. Declining changes nothing about what the app can do; the recovery features are fully available either way.

  Both backends are now configured: a Firebase Analytics project and a rewarded AdMob unit. That makes the answer matter, in both directions. Allowing starts the two SDKs; declining leaves both uninitialised, so nothing is sent and no ad is requested. The Settings tab states which state the app is in, so the answer is never a matter of memory.

Step 1 - Choose the folder, then the recording

The Recover tab is the first screen, and its first action is choosing the folder to search, not the file. The list of files appears after the scan.

1. Press Choose folder to search. On the tab, above the list, the app explains itself: it reads only the folder you grant, it needs no storage permission, and leftover .pending files live beside finished recordings, so granting the parent folder is usually enough.

2. Pick the camera folder (usually DCIM/Camera) or its parent in the system picker. The grant is persisted, so the app asks once.

3. What you should see: the button becomes Change folder, a "Granted: ..." line shows the folder, a Scan again button appears, and a scan line reports " files, folders, shown, ms". The Activity log adds how many were candidates.

4. Read the label under each recording's name. The scan opens every video's header - seeking over the media rather than reading it, so this is quick even for a large file - and reports what it found:

   Label	What it means
   Index missing - this is the interrupted recording.	The index was never written. This is the file to repair.
   Index cut off mid-write. Repairable.	The index exists but the file ends inside it.
   Complete recording - usable as a reference.	Nothing to repair; this file can supply the codec configuration.
   Fragmented recording - usable as a reference.	Same, for a file written in fragments.
   Not an MP4-family file...	The video repair does not apply, but it can still be copied byte for byte.

   A file with no label was not probed - a provider that would not hand over a descriptor, or a scan that had already spent its probe budget. No label is not a clean bill of health.

5. Tap the broken recording in the list. Each row also shows its kind, size and relative path, plus the signals the scanner noticed. The selected row is marked "selected" and a detail card opens below it.

If nothing is listed: the counts and the Activity log tell you how many files were seen, and Change folder lets you try another folder. There is no separate "no candidates found" message in this build, so use the counts.

Step 2 - Mark a reference recording (recommended)

The codec configuration lives in the index that was lost, so the repair needs one playable recording from the same phone and camera settings.

This is the step people find hardest, and the scan is what makes it easy: it is the file the list labels Complete recording - usable as a reference. Before those labels existed, the only mention of a reference appeared after a repair had already failed.

1. Select the complete recording, not the broken one. The button acts on whatever row is selected, so tapping it with the broken file selected would mark the file that has no index as the source of truth. The app refuses that choice and says why, and on a broken file the button reads This recording cannot be the reference rather than inviting it.
2. Press Use as reference recording. The button becomes This is the reference recording and the detail card shows the reference's name.
3. Now select the broken recording again. Its reference is kept - the app does not forget it when you move between rows - and the card still shows which recording is supplying the configuration.

The log explains the reasoning: the reference's codec configuration is what the audio recovery uses, so it should come from the same device and the same camera settings.

There is no automatic check that the reference matches the broken file in this build. If the repair fails or the result looks wrong, mark a different recording and repair again.

Step 3 - Inspect, then repair

1. Press Inspect for a preview of what the app thinks the file is. The log shows the container state, the repair strategy and a summary.
2. Press Repair. The work banner appears with a spinner, the current stage, and a byte count such as "4194304 / 31457280 bytes". Cancel sits in the same banner and is available the whole time.
3. Keep the app in the foreground while it works. This build has no background service: the repair runs in the app's process, and leaving the app for a long time is not covered by a persistent notification yet.

What you should not expect: a percentage bar and an estimated time. The build reports bytes processed, not an ETA.

Cancelling is safe: the original file is never modified, and a cancelled export leaves no partial file behind.

Step 4 - Read the result

The Activity log prints the engine's real numbers rather than a bare "done". For a successful repair you will see the output name, then the video facts (codec, frame count, resolution, duration, and whether the parameter sets came from the reference or from the stream), the audio outcome (frames, sample rate, channels, applied offset and duration, or an explicit "audio NOT recovered: "), the output SHA-256, and any warnings.

What is not part of this screen: a full decode of the repaired file. The app does not ship an in-app whole-file verification step. That verification runs in the automated on-device test, which decodes the repaired output and asserts playable video frames and non-silent audio.

Step 5 - Export it

1. Press Export folder and choose where the repaired file should go. This is a normal folder grant; there is no gallery insert and no storage permission.
2. Press Export repaired.
3. What you should see: either the export runs, or an optional ad offer appears first. The offer reads "Watch a rewarded ad?" with Watch ad and Skip and export. Skipping always exports; nothing else in the app changes. In this build no production ad unit is configured, so the surface reports itself as unavailable and the export is never blocked.
4. The log reports the exported name, the byte count and "Byte-for-byte verified, SHA-256 ..." plus the hash, or a warning if either check failed.

Copy as-is exports the selected file's original bytes without repairing it. That is the general file path: it works for any file type, refuses to overwrite an existing destination, and verifies both hashes.

Tab map

The desktop companion, side by side

The desktop app is one window with five tabs: Repair, Phone (ADB), Audio, Export any file, Setup.

The desktop repair and the phone repair use the same engine, so the rules are identical: the source is only ever read, and a new file is written.