Play DishCam runs as video in the app

[wasimxyz]

Summary

DishCam photographs a dish over and over and saves the whole run as one big multi-photo file, alongside a small text file holding the run's settings. Today Data Hub just stores both, so you have to download the big file and open it in something else to see what happened.

This turns that photo stack into a video that plays on the run page.

What you'll see

• DishCam is now a selectable instrument type, with its own icon in notifications.
• Opening a DishCam run shows a video player at the top of the report, with play, pause, and dragging through the timeline.
• A still frame is shown before you press play.
• The run's settings from the small text file (number of photos, speed, quality) are saved onto the run.

How the conversion works

The camera's two files arrive separately and either can land first. Instead of retrying and burning time, the converter checks whether its partner file has arrived yet. If not, it stops quietly and lets the second arrival do the work, so nothing half-finished shows up in the app.

Once both are present it reads the photos one at a time and feeds them straight into ffmpeg, a standard video tool now included in the processing image. A single run can be hundreds of 12-megapixel photos, so loading them all at once would run the job out of memory.

Three choices worth flagging:

• Playback speed has a floor. The camera can shoot as slowly as one photo a minute. At the true rate that is unwatchable, so the video never runs slower than 10 photos a second. The real capture speed is still recorded on the run.
• The video is shrunk to 1920 across at most. Full-size frames are too large for browsers to play.
• Every frame is stored as a complete picture. That makes the file bigger, but dragging the timeline responds instantly.

Reliability

• If both files land at the same moment, two conversions can start at once. They no longer trip over each other, and the one that finishes second backs off rather than marking a good run as failed.
• ffmpeg prints progress constantly. If nobody reads that output it fills a buffer and the job freezes until it times out. Its chatter is switched off and real errors are captured separately.
• If something fails partway through, the ffmpeg process is shut down instead of left running.
• Video now plays and seeks correctly against the local development file server, which previously always returned whole files and broke dragging the timeline.

Setup notes

• One database migration adds dishcam to the list of instrument types.
• ffmpeg is needed to run the full test suite locally (brew install ffmpeg). Tests that need it skip themselves when it is missing, so nothing breaks without it. It is installed in CI and included in the processing image.
• The processing image pulls ffmpeg from a version-tagged public image rather than a build-time download link that gets deleted after a few weeks.

Test plan

• make py-test passes (342 unit tests pass locally)
• Upload a DishCam run, confirm the video plays and the timeline can be dragged
• Confirm the still frame appears before pressing play
• Confirm the saved run settings match the run's text file
• Upload the two files minutes apart, in both orders, and confirm the run still converts
• Confirm other instrument types are unaffected

Made with Cursor

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
data-hub	Ready	Preview	Aug 20, 2026 9:16pm