8 model entries record sha256/size that nothing at their URLs serves (3 sharing one hash, 2 sharing one URL)

[nuri-yoo]

While building sha256-verified mirrors of the GitHub-hosted models for a browser demo (rupscale), I bulk-verified every entry whose resource URL is a GitHub link (148 of them) against the sha256/size recorded in data/models/*.json. After accounting for the two indirections the database uses — zip bundles, where the recorded hash is the model file inside the zip (confirmed: all 11 AnimeJaNai variants match their zip members exactly), and release-tag page URLs, which I resolved to their assets via the GitHub API — 8 entries remain whose recorded hash cannot be reproduced from what their URL serves today (checked 2026-07-27). They fall into three distinct patterns.

1. Three entries share one sha256 and size (1x-SuperScale family)

1x-SuperScale, 1x-SuperScale-RPLKSR-S, and 1x-SuperScale-Alt-RPLKSR-S all record the same sha256 (f5844dd7…) and the same size (1,195,070), while pointing at three different files (SPAN and two RealPLKSR-S variants). Three distinct files can't share a hash, so at most one record could ever be right — and the recorded size matches none of the served files (~8.9 MB / ~9.4 MB), so probably none is.

entry	served file	served sha256	served size
1x-SuperScale	1x-SuperScale_SPAN.safetensors	703e4973…	8,888,072
1x-SuperScale-RPLKSR-S	1x-SuperScale_RPLKSR_S.safetensors	8620aa99…	9,395,932
1x-SuperScale-Alt-RPLKSR-S	1x-SuperScale_Alt_RPLKSR_S.safetensors	7fd6ba24…	9,395,932

2. Two entries share one URL but record different hashes (1xSPANGELION)

1x-SPANGELION-SHARP and 1x-SPANGELION-INTERPOLATED both point at the same file, terrainer/AI-Upscaling-Models/raw/main/1xSPANGELION/1xSPANGELION.pth, but record different hashes and sizes (1fe9b52d… / 8,938,861 vs 0c5650f0… / 8,944,458). One URL serves one file, so at most one record can match — and the file currently served (c11d354c…, 8,938,652) matches neither, since raw/main links drift whenever the repo's copy is updated. If the author's repo has distinct SHARP/INTERPOLATED files, the two entries probably want distinct URLs (ideally commit-pinned) plus re-recorded hashes.

3. The served asset no longer matches the record (likely replaced after recording)

entry	recorded sha256 / size	served today sha256 / size
1x-UnResizeOnly-RCAN	b88289e7… / 30,757,598	c3f3041a… / 31,259,352
4x-PBRify-UpscalerV4	a00fa501… / 139,793,020	82db39e3… / 140,345,646

Both are release assets that appear to have been replaced in place since the hashes were recorded.

2x-Fallin-Strong is a variation of this: its URL is a release tag page (renarchi/Re-SISR/releases/tag/Fallin), and none of that release's current assets — nor any member of its zip assets — hashes to the recorded b05afbd8… / 5,657,145. Possibly related to #496, since that model series' hosting has been reshuffled before.

Reproduction

curl -sL <resource url> | shasum -a 256

Full evidence (recorded vs served, complete hashes)

{
 "1x-SuperScale":            {"recorded": "f5844dd72922a6579cf73c44de5cf35f0d700bd407982ae8d03bcdf720924425 (1195070)", "served": "703e497308ec1ba0efdb720a04d055f4c91422bbd406a91553f77de8f16df489 (8888072)"},
 "1x-SuperScale-RPLKSR-S":   {"recorded": "f5844dd72922a6579cf73c44de5cf35f0d700bd407982ae8d03bcdf720924425 (1195070)", "served": "8620aa99ef5421d5d0614c103cffa7c605f77050745247f894eb24d41b5fb0ed (9395932)"},
 "1x-SuperScale-Alt-RPLKSR-S": {"recorded": "f5844dd72922a6579cf73c44de5cf35f0d700bd407982ae8d03bcdf720924425 (1195070)", "served": "7fd6ba2488c2f7af731356cd280ae94096ac0390a22ca903eb4b7bfdaa3d24da (9395932)"},
 "1x-SPANGELION-SHARP":      {"recorded": "1fe9b52df243cb18a202264bed9bf5cfe3890525fa1480402318154cb3a4a13f (8938861)", "served": "c11d354c76899e6ef49151d479ec49abba39cbf93d2d88cbabdd54464489313c (8938652)"},
 "1x-SPANGELION-INTERPOLATED": {"recorded": "0c5650f0c5b38aa0e071ecc6929e23a38ef00f45c973d848f679a620fd26a196 (8944458)", "served": "c11d354c76899e6ef49151d479ec49abba39cbf93d2d88cbabdd54464489313c (8938652)"},
 "1x-UnResizeOnly-RCAN":     {"recorded": "b88289e770207e634181b595845e0d240cc397714aefe659bcf9b70478b64373 (30757598)", "served": "c3f3041a51347f64b0951e2a9e161aac27c3fd2a7287520821d871dcc075b8e5 (31259352)"},
 "4x-PBRify-UpscalerV4":     {"recorded": "a00fa50116895a9b766aeb012edad0a14d66f3afda65539efc0f6fc28c991ba2 (139793020)", "served": "82db39e31e01da6816a9814c0553a8dcdb7bd2d655353e67075c9295068cb789 (140345646)"},
 "2x-Fallin-Strong":         {"recorded": "b05afbd8e67b93a35959aad5b2fd11af067799ef44be083bc205cff926433f78 (5657145)", "served": "no asset of the Fallin release (or zip member) matches"}
}

For group 3, I'm happy to send a PR that updates the recorded hashes to the currently-served files if that's the desired fix (it assumes the in-place replacements were the authors' intent). Groups 1 and 2 need someone who knows which files were intended, so I've left them as a report.