How we tell a live camera from a placard

Ask fl511.com for camera 4425 and you get Capital Circle NW at Hartsfield Road in Tallahassee, a 43,590-byte photograph of an intersection on a 30-second refresh. Seventy-five seconds later the same URL handed me 43,460 bytes and a different md5, because a traffic camera in daylight is never twice the same picture. Now ask the same site for camera 99999999, an id belonging to nobody. You still get HTTP 200, a content-type of image/png and an image: 15,136 bytes of grey card, an exclamation mark in a circle, the words "No live camera feed at this time". Both of those were fetched at 13:24 UTC on 2026-09-28.

That card is why a fetch cannot grade itself. Four questions are all a single request can settle. Did it complete, did the status come back 200, does the content-type start with image/, do the bytes decode as an image. A vendor's picture of the word no passes all four as cleanly as a photograph of I-75, and about 115,000 of the cameras we carry are plain image feeds graded exactly that way, counted from our fleet at 13:14 UTC today alongside the 143,648 live rows the same count returned.

What separates the photograph from the card is not in either response. It is in how many other cameras sent you the identical file.

One hash across many different URLs

Every camera's last fetched image carries an md5, written by the fingerprint pass that runs as part of the rolling health check. Group those hashes and count the distinct feed URLs under each one, and that single number does nearly all the work. A working camera shows a scene nobody else is showing. So byte-identical images arriving from hundreds of different URLs can only be one shared static card.

Counting rows instead of URLs gets you the wrong answer, because same-URL matches are duplicate camera records, a different bug with a different fix.

The clearest demonstration of it took four minutes this morning. I asked five state 511 sites for that same nonexistent id 99999999, and 511wi.gov, 511pa.com, 511.idaho.gov, 511ga.org and fl511.com each returned 15,136 bytes with the md5 9c2d059e65a23b43a5b481c16918fed4. Five states, five separate DOTs, one file, byte for byte. They share a vendor, and the vendor ships one card.

What the June sweep took down

In the sweep we ran on 2026-06-07, 136 hashes appeared at five or more distinct URLs and those 136 covered 99% of every affected camera, whilst the 1,216 hashes sitting at exactly two URLs were noise: twin installs, and coincidental identical black frames at night. Those figures came off our cameras table on 2026-06-07 with the group-by above and live in an internal write-up, so the nearest checkable thing is the card itself, which 511ga.org was still serving for a real Atlanta camera id at 13:20 UTC today.

Reviewing all 136 by eye confirmed 106 as placeholders and threw 7 out as real scenes. Curating those 106 grew the placeholder table from 7 hashes to 113. Then a live re-test of the 10,567 active cameras matching a confirmed hash deactivated 9,881, found 682 that had recovered since their last fingerprint, and failed to fetch 4. State 511 sites accounted for 3,024 of the deactivations and Istanbul for 1,442. Behind those came idokep's test pattern at 671, then the Windy providers at 631. Same table, same date, same method; how we source is the public description of the pass those numbers come from.

Curating a hash is safe in a way worth spelling out. It never removes a camera by itself. The deactivation happens on that camera's next live fetch and only if the bytes coming back right then are still the card, so a feed that recovered in the meantime stays up, and one that recovers later comes back on its own.

When every camera gets its own card

A source that serves a different placard per camera defeats the whole trick. malaysia-fgies is the worked example, measured on 2026-07-27: 706 cameras, every feed answering 200 with image/jpeg at sizes between 12 and 22 KB, every one a different hash. The group-by finds nothing, because there is no group.

What settles it is the thing the Tallahassee camera did in the first paragraph. Refetch the same URL 75 seconds later and compare the bytes. A live camera changes; a card does not. None of the three we tested had moved a byte, and the URL path said /offCam/ outright. Our digest for 2026-09-27, computed at 11:28 UTC on 2026-09-28, counts 0 of those 706 live, and the same digest is summarised on how we source.

When a source answers 200 to everything and still looks dead, the differ goes first and the conclusion second.

One card, a different encoding every request

The mirror-image case is one placard encoded differently on each request, and ALGO Traffic in Alabama does this. Camera 9999 does not exist. The first fetch at 13:16 UTC today returned 200, image/jpeg, 133,818 bytes, md5 670b0d62; the next five returned 63,070 bytes and md5 adab54ef. Same picture, two encoders, and you can run it yourself against camera 9999.

Three defences miss that independently. A curated hash matches whichever encoding happened to be curated. The fingerprint streak never accumulates, because consecutive bytes genuinely differ, so the camera reads as one that is changing. And the grace path that trusts a fresh Last-Modified is trusting an origin that stamps the current time on every response.

For that class the remaining signal is absence from the upstream catalogue, which is why the fix went into the camera lifecycle rather than into placeholder detection. A camera missing from its own source's list for a run of ingests gets retired by source and stops being our problem to fingerprint. 50,161 rows in the table carry that stamp, counted at 13:14 UTC today.

The band where I still open the picture

Above five distinct URLs a shared hash is a card. At two it is a coincidence. Between five and fifteen it is either a vendor placard or one genuine frame filed under several camera ids, and in the 2026-06-07 run every false positive lived there: six live state 511 highway cameras and a swisswebcams Eiger camera, all sitting at six to eight URLs. Opening the image and looking at it is the only method I trust in that band.

So the group-by runs nightly now and its biggest groups go into the digest rather than waiting for someone to think of running it. Last night's listed 14 groups of 20 or more live cameras sharing a single frame, covering 2,928 cameras between them, most of them hashes we curated months ago and one, c716d1e5 at 58 twipcam URLs, still unreviewed. That one is what I open next, and the figures are from the same 2026-09-27 digest described on how we source.

The question I have not answered is how to tell a placard from a real frame filed under six ids without a person looking at it. That was fine at 136 candidates in one sweep and it will not stay fine. If you run a camera directory and you have a signal that does it, I would like to hear it.