On This Day: Twenty-Six Years of Photos Back in My Notes

I’ve been taking photos and putting them on Flickr for a very long time, and like most people I almost never look back at them. Thousands of pictures from holidays, days out and events, all sitting in albums that I last opened the day I uploaded them.

Meanwhile my Obsidian vault has a note for every trip and a lot of the events I’ve been to, and a Daily note that I open every morning. The two never met. So last weekend I asked Claude Code to connect them, and the result is a small project called FlickrVault. It does two things: it puts an “On This Day” section with old photos into every Daily note, and it links my Flickr albums to the matching Trips and Events notes. (For the wider picture of what runs on my Raspberry Pi, see What I Have Built With Claude Code (So Far).)

On This Day

Every night, shortly after the n8n workflow that creates my Daily note has run, a script adds a section headed “On This Day”. For each earlier year in which I took photos on today’s date, it shows:

• The year and how long ago it was, linked to that day’s photos on Flickr.
• How many photos I took that day.
• Up to three thumbnails, spread through the day rather than the first three, so a day that started at breakfast and ended at a show gets a picture from each part. Each thumbnail links to the photo on Flickr.
• Any Trip or Event note that covers that day, so I can jump straight from “26 years ago” to my notes about where I was.

It does one Flickr search per year, starting from 1995, which comes to about 30 calls and takes around 45 seconds. Yesterday’s section went all the way back to 2000, 26 years ago. Private photos appear too, which is fine because the vault is private: the thumbnails load without signing in, and the links to Flickr need me to be signed in.

A few details make it reliable rather than just working on a good day:

• It never creates the Daily note itself. If n8n hasn’t made it yet, the script logs that it’s waiting and a second run at 06:15 tries again.
• Re-runs are harmless. If the section is already there, nothing happens. The note is re-read just before writing and replaced in one go, so it can’t trample on something I’ve typed in the meantime.
• It doesn’t use AI. This is plain Python with no model in the loop. Picking photos by date doesn’t need judgement, so there’s nothing to go wrong and nothing to pay for.

Flickr’s API isn’t always cooperative. The run log has a fair number of “the Flickr API service is not currently available” errors, but the scheduled runs have filled in every Daily note since it went live on 24 October.

Linking albums to trips

The second job runs every Sunday morning and works out which Flickr albums belong to which Trips and Events notes. Each of those notes already has start and end dates, so the rule is simple: an album matches a note when at least 80% of its photos were taken within the note’s dates. What happens next depends on the album’s name:

• The name fits as well. If the album name shares a word with the note’s name or location, the album’s link goes straight into a flickr_album: list in the note’s properties. The word match is fuzzy, so a misspelt album name like “Maderia” still matches “Madeira”.
• Only the dates fit. A birthday album taken during a trip, for example, matches on dates but probably isn’t part of the trip. These go into a review note as tasks instead.
• The name and year fit, but only some of the photos do. If 30–80% of the photos are inside the dates, that also goes to review.

In the review note I tick a task to link the album, or mark it as cancelled to reject it, and the next Sunday run applies my choice. Rejected pairs are never suggested again, and links that are already in a note are never removed or reordered.

The first run took a while, because it had to fetch the photo dates for every album (around 800 Flickr calls). Those dates are cached, and only albums that are new or have changed are fetched again, so the weekly run is quick.

What the dry run caught

Before letting it change any notes, Claude ran the matching as a dry run first. Three problems showed up, all down to the way I’ve named albums over the years:

• Squashed-together names. Albums named like MNDBall-2015 or Holiday2024-Orkney weren’t being split into words, so they never matched anything by name. The matcher now splits on changes of case and on digits, so those become “mnd ball” and “orkney”. Words like “holiday” and “trip” are ignored, because they’d match everything.
• parkrun the day before. I have plenty of parkrun albums. Because a match on dates alone allowed a day either side, a Saturday parkrun album was being suggested for a one-day event on the Sunday. Now a match on dates alone has to be strictly inside the note’s dates; the extra day either side is kept only when the name fits too, to allow for photos from the journey and cameras with the wrong clock.
• Catch-all albums. Favourites, auto-upload and year-only albums were turning up as suggestions. They’re never about one trip or event, so they’re now ignored completely.

After those fixes, the first real run linked 50 albums to 40 notes (34 trips and 6 events) and put 39 less certain matches in the review note. Some of those are clearly right (an album of a space centre visit during a Florida holiday has a name that shares no words with the trip). I’ll admit that I haven’t worked through them yet: all 39 are still waiting for me.

Keeping track of which photos are used

Once photos started appearing in my notes (and, as it happens, in posts on this blog), I wanted to be able to see on Flickr which ones were being used. So every photo that something on the Pi uses gets two tags, claudelinked and one saying what it was used for, and is added to a matching “Linked” album. The On This Day job marks the thumbnails it shows, and the Sunday job finishes by scanning the whole vault for links to my photos, albums and days and marking all of them.

That scan taught a small lesson about what counts as a failure. On its first big run a handful of Flickr calls failed with gateway timeouts, the run retried them and sent them all, and the run still logged itself as failed, which set off my regression tests. It now counts as failed only if photos are still waiting to be sent when it finishes.

How it fits with everything else

• One shared Flickr client. FlickrVault doesn’t talk to Flickr directly. It uses the same small client as everything else on the Pi, which can only read. The one exception is marking used photos, which goes through a separate tool.
• EventCapture adds photos as it goes. My weekly EventCapture run, which records the shows, meals and days out it finds in my email and calendar, now also checks Flickr for photos from each event and adds an album, or the day’s photos once it has looked at a few to check they’re from the event. The Sunday album job catches anything I upload later.
• The usual rules. Its own git repo and README, a changelog note in the vault, and a regression test that checks the timers are running, today’s section is there, and the last album run didn’t fail.

Was it worth it?

It’s only been running for a week, but yes. Three small photos from a day 16 or 18 years ago, at the top of the note I open every morning, are a far better way back into my photos than albums I never open. The trip links matter more in the long run: my notes about a holiday and the photos from it are finally one click apart.

Now I just need to work through those 39 suggestions.

A note on how this post was written: it was drafted by Claude Code from the FlickrVault repo, its code history and my vault notes, and Claude chose the photos from my Flickr account. It wrote the draft directly into WordPress through the WordPress API, and I then reviewed and edited it before publishing.