LEARNED IT · 09/26
The capture app's output path is the app's state, not yours — I lost nine runs by looking in the wrong folder
Set the output path from a script, changed it later in the GUI, and forgot. Nine SER runs went to ~/Pictures under the prefix "testing" while I searched an empty AstroDMx_DATA and concluded nothing had saved.
I ran a setup script that wrote path=~/AstroDMx_DATA/Saturn into
astrodmx_settings.conf. Later, in the GUI, the path got changed to ~/Pictures with
the object name testing. Nine 10-second SER runs — 28 GB — landed there.
I looked in AstroDMx_DATA, found one stale snapshot, and concluded the captures had
silently failed. I even had a plausible mechanism ready: the camera had been replugged
during a tube swap and come back on a different /dev/video node, so I blamed a stale
device handle. That was wrong. The app was working perfectly the whole time.
Two things to take from it:
AstroDMx rewrites astrodmx_settings.conf on exit from its own GUI state. Anything a
script wrote there is a suggestion, overwritten the moment the app closes. It is a record
of the GUI, not an input you can rely on. Same family as the Auto White Balance trap: the
app's own controls are the ones that count.
Search by modification time, not by expected location. find ~ -newermt '-2 hours'
would have found those files in one second. Looking in the folder I believed was the
output directory confirmed a story instead of testing it.
And the meta-lesson, which is the expensive one: "nothing was saved" is an extraordinary claim about software that has been working. The prior should be that it wrote somewhere I'm not looking, not that it silently did nothing. I had the evidence to check and reasoned from an assumption instead.
Related: measure, don't derive.