Safely delete old test timelapses in indi-allsky and clean up the video viewer

After initially installing indi-allsky, I had experimented with various cameras, settings, and test recordings. Some of the time-lapse videos I’d created back then were long gone. However, the old entries still appeared in the video viewer, sometimes as black tiles without a preview.

I wanted to clean that up. But not by simply deleting everything before a certain date—rather, in a way that would leave productive footage untouched. In my case, I wanted the video archive to start only on or after December 23, 2025.

And here’s how I went about it…

indi-allsky Backup on FRITZ!NAS Version 2.0: How to Back Up the Database, Configuration, and System Today

By the end of 2025, I had set up a two-step backup process for my indi-allsky installation on the Raspberry Pi: First, I backed up the database, configuration, and migrations; then, the image files and time-lapses. This worked in principle, but over time it became significantly more time-consuming than necessary.

Now, the timelapses are also posted to my YouTube channel. I no longer want to transfer the large image collections to the FRITZ!Box over the local network every day. What’s much more important to me is that, in the event of an NVMe SSD failure, I can restore the running indi-allsky installation with as little effort as possible.

That’s why I set up the backup system anew in October 2026. The previous articles explicitly describe the old method: Phase 1: Database, Configuration, and Migrations, and Phase 2: Files and Quality-Based Backup. I’ve since disabled both cron jobs.

indi-allsky: Resetting the YouTube Upload Button After Deleting a Video

Bildschirmfoto 2026 10 20 um 22.34.40I recently deleted a few videos that had been uploaded to YouTube via the indi-allsky backend, but the indi-allsky video viewer still displayed “YouTube Uploaded” instead of the upload button.

Unfortunately, there’s no reset option in the backend for cases like this—but with a little coding and database know-how, the problem can be fixed.

Northern lights over Hesse / Germany – Allsky timelapse from January 19, 2026

On the night of January 19, 2026, a rare celestial phenomenon could be observed in Central Europe: The aurora borealis reached as far as Hesse and was also visible over the Rodgau area.

With my permanently installed Allsky camera, this event could be recorded continuously for several hours. The video embedded below shows a time-lapse documenting the development, intensity and spatial extent of the aurora borealis.

Auroral time-lapse video

The time-lapse makes the greenish (in white) and occasionally reddish structures visible, which are caused by the interaction of charged particles from the solar wind with oxygen and nitrogen atoms in the upper atmosphere. Such sightings are only possible in Germany during strong geomagnetic activity and are correspondingly rare.

Automatic indi-allsky backup on external drive (Fritzbox NAS) – Phase 2: Files

After the database, configuration and migration of indi-allsky have already been automatically backed up to an external drive, the next step was to work on the actual files: the night images from which Timelapse, Keogramm and Startrails will later be created.

*** Update – please have a look at my new backup-strategy here! ***

The basis for this is phase 1 of the backup, which I have described here:

Automatic indi-allsky backup on external drive (Fritzbox NAS) – Phase 1

Phase 2 is much more demanding. While database backups are comparatively small and deterministic, with image data we are quickly talking about several gigabytes per night – and about data that is not all equally valuable.

Why not simply “back up everything”?

An all-sky system produces images every night – regardless of whether the sky is clear, partially cloudy or completely unusable. If you backed up all the files blindly, even a large external hard disk would fill up very quickly.

That’s why it was clear from the start: the backup must be quality-based.
Not every night is equally valuable – and with indi-allsky this can be derived very well from the database.

And this is how I proceeded…