Skip to content

The calendar overview

The overview is the home page — every logged viewing, most recently watched first by default.

Filters and the “Refresh all metadata” action sit inside their own bordered card, set apart from the results below. Expanding Filters shows the everyday fields right away — From, To, Title, Medium, and Venue. Everything else — Director, Actor, Genre, City, Movie country, Movie language, Rated, Released year, and Released month — sits behind a nested “More filters” toggle, so the common case doesn’t mean scanning past a dozen fields you rarely use. A chip link that carries one of those advanced filters (from a details page, Venues, or elsewhere) expands “More filters” automatically, so the active value is never hidden.

From and To date fields default to your own actual first and last logged viewing, so they always show what’s actually being applied rather than looking blank while a narrower default silently filters underneath. Medium, City, Movie country, Movie language, Rated, and Released year are dropdowns listing only the values actually present in your own history (plus an “Any” option) — there’s nothing to type that could ever match otherwise. Title, Venue, Director, Actor, and Genre stay free text with autocomplete, since they’re open-ended. City is the venue’s own location, when known; movie country and movie language are the film’s own OMDb-derived fields, a different thing from where you watched it — there’s no separate Country field for the venue’s own location, since two distinct cities sharing a name in different countries is a negligible risk for a personal log. Director, actor, genre, movie country, and movie language all match one exact value, not a substring — a genre filter for “Action” won’t also catch “Live Action Adaptation”, and a movie country filter for “United States” still catches a co-production credited as “Australia, United States, China”.

You can also filter by release year or month, matched independently of each other — there’s no exact-release-day filter; that’s too granular to be worth its own field.

Clicking a director, actor, genre, movie country, or movie language chip on a viewing’s own details page takes you to a dedicated page for that exact value instead — its own results and pagination, with no filter controls — the same pattern the Venues page uses for a single venue (a “Directors”, “Actors”, “Genres”, “Movie countries”, or “Movie languages” listing page, each reachable at /directors, /actors, /genres, /movie-countries, and /movie-languages, lists every distinct value with a count). Clicking a Rated badge, or the month/year of the Released date, still takes you straight to the overview pre-filtered to that exact value/granularity — there’s no dedicated page for those. Clicking a city heading on the Venues page filters the overview to every viewing at a venue in that city, the same way. When exactly one such overview filter is active, the browser tab’s title reflects it — for example “PG-13 (rated) — Movie Planner” — so several filtered tabs stay easy to tell apart. A long cast on a details page shows only the first several actor chips, with a “+N more” toggle to reveal the rest.

Click a column header (Title, When, Venue) to sort by it; click it again to reverse direction. Results beyond the first page worth are paginated rather than all rendered at once, and changing any filter resets you back to the first page.

Each row shows a poster thumbnail, the title (linking to its details page), when it was watched, and the venue — with a small location pin next to it when that venue has known coordinates, linking straight to the viewing’s own details page and its real map. Edit, Delete, and a refresh control for OMDb metadata sit at the end of the row as their own icon buttons; Edit opens the details page with its edit form already open, Delete asks for confirmation first.

Below the results table and pagination, the overview also shows a map of whatever’s currently filtered, one pin per viewing with a known location — the same map Venues uses, just scoped to the current filter instead of your whole history. It sits after the table rather than before it, so the primary list is reachable without scrolling (or tabbing) past a secondary visualization. No filter, or nothing located yet, means no map shows at all rather than an empty one.

Most pages need your whole history, so this browser keeps a copy of your viewings (not your password) and shows it straight away when a page opens, then asks your CalDAV server for the current list in the background. If something changed on the server, such as a viewing added from the command line or another device, the page updates in place a moment later. Anything you add, edit, or delete here shows on the next page at once.

The first visit, and the first visit after you point the app at a different calendar, still wait for the server, because there’s no copy yet. If one device shows old or missing viewings and another doesn’t, Settings has a “Clear local cache” button under Data. It removes the copy and the pages this browser keeps for speed, and leaves your sign-in and your activity log alone. Clearing this site’s data in your browser removes the copy too, along with your sign-in. Export and import always read from the server itself, never from the copy, and so does the activity log’s check for changes made elsewhere.

Settings has a “Danger zone” with a “Purge calendar” button. It deletes every viewing on your CalDAV calendar, on the server, and it can’t be undone. Your venue and medium lists stay. It isn’t the same as clearing the local cache, which only removes this browser’s copy. Export your viewings first if you might want them back. The button asks you to type DELETE before it works, shows its progress, and says at the end how many viewings it deleted and how many it couldn’t, with the server’s reason for the first failure. It deletes each event at the address your server listed for it, then asks the server what is left and deletes again while that list shrinks, so an event another app stored under its own filename goes too. Anything the server still lists after that is counted as failed, not deleted. It only sees what the app lists everywhere else, from 15 years back to a year ahead, so an event dated outside that window stays. If some failed, run it again.

“Share” on a viewing’s own details page generates a link to just that one viewing, and shows it as a plain, selectable text field with a Copy button next to it. On a browser that supports it, sharing tries the native share sheet first; either way, the link itself is always shown, since clipboard and native sharing can both fail depending on browser/permission quirks a visitor has no control over. Anyone who opens the link sees that one viewing read-only, with nothing to edit and no CalDAV or OMDb credentials of yours anywhere in it — the link itself carries the display data, frozen at the moment you shared it, so it never updates and never asks the recipient to connect to anything. Sharing your whole (or a filtered) history is what Export viewings is for instead.

A viewing with a matched IMDb ID links out to its IMDb page; Rotten Tomatoes and Letterboxd links are always shown but are constructed searches rather than a guaranteed exact match, since OMDb doesn’t expose a stable ID for either. Each shows as its service’s own brand mark rather than a text label.