Summer 2026 Release Notes

I skipped August. It was vacation time and I had a lot of features coming in that I wanted to finish before writing about them. So this covers everything since the July notes: seven releases, two new kinds of device, and one large, mostly invisible rework that fixes a class of bug people have been quietly living with since the beginning.

First off, let me start with an announcement for retro gamers looking to meet me in person:

1Retro will be at the Portland Retro Gaming Expo

Save the date! 1Retro will be at the Portland Retro Gaming Expo, October 9-11 (all 3 days), booth 783. Come and say hi, have a conversation, questions and requests. AMA!

If you’re in Portland but don’t plan to go, I can meet afterhours as well!

Discs are recognized properly

If you play disc games, PlayStation, Saturn, Dreamcast, Sega CD, Neo Geo CD, PC Engine CD, any disc really, some of your saves have probably landed on games that 1Retro invented on the spot or did not recognize properly.

Here is why. To work out which game a save belongs to, 1Retro hashes the ROM sitting next to it. That is exactly right for a cartridge, where the file is the dump, but it is wrong for a disc, because the same disc hashes differently as a .cue and .bin, as a .chd, as a CloneCD image or an RVZ, or even as a ZIP. The container changes the hash, so the lookup missed every time, and the save fell back to being matched on its filename.

Filenames are finicky. They might carry tags like (Beta), they cannot hold a colon, so Castlevania: Symphony of the Night in the catalogue never once met Castlevania - Symphony of the Night.srm on your disk, or maybe you just renamed the disc to something we couldn’t 100% match exactly. The upload gave up and minted a new game named after the file. Doing it again minted another. One account ended up holding four separate rows for that one game.

Now, discs are no longer hashed. 1Retro reads the serial the disc prints in its own header (e.g. SLUS-00067), and for the systems that have none (e.g. PC Engine CD), a fingerprint taken over the disc’s user data is used instead of hashing the whole disc. Both survive a re-dump and a change of container, so your .chd and my .bin land on the same game. A disc nothing recognises still syncs, by hash, because an unreleased prototype has to have somewhere to go.

While I was in there: zipped libraries are visible again. .zip used to be skipped outright, on the reasonable grounds that treating every archive as a ROM would sweep up MAME romsets. The consequence was that if you keep your games packed, which RetroArch, ES-DE, OnionOS and NextUI all support directly, none of them reached 1Retro and none of their saves found a ROM to pair with. 1Retro now looks inside the archive and hashes the member, so a library kept zipped lands on the same catalogue entries as the same library unpacked.

A game is now a release, not a title

This is the bigger half, and the part that changes what you see.

A game row used to mean “a title on a system”, which merges products that are not the same thing and splits ones that are. Final Fantasy VII on PlayStation was three rows, one per disc, and all six of its regional releases shared them. It should be six games, each holding three discs:

Europe   SCES-00867/10867/20867      Japan   SLPS-00700/00701/00702
France   SCES-00868/10868/20868      Spain   SCES-00900/10900/20900
Germany  SCES-00869/10869/20869      USA     SCUS-94163/94164/94165

So a game is closer to a serial family than to a title. Discs vary within one, region does not. If you play the Japanese release and then the English one, you want two save histories, and two games is what gives you that.

Doing this meant ingesting Redump alongside No-Intro, building a tool that merges and splits catalogue rows until the whole thing settles, and teaching every name-matching path that a title is no longer unique within a system.

It was several weeks of work you will never see (though there were bumps you may have noticed). What you will see:

Territory tags under a game’s name, so the two Zeldas on your shelf stop looking identical.
Filtering by territory, on the API today and in the web library shortly. A release sold as “USA, Europe” is found by either, which is the whole reason territories are stored as their own thing rather than as one string: a filter comparing a single value would answer “your USA games” while silently dropping every compound release, and a filter that fails quietly is the worst kind.
Every console drawn in its own colour. Games and saves now carry a badge with their system’s controller, in a colour unique to it, which is what makes a shelf scannable: you find the Mega Drive saves by looking for the blue pads, without reading a word. Forty of forty-seven systems are covered so far.

Where your existing saves ended up, honestly

A save file records no ROM and no serial. It never has. So when a game splits into six regional releases, the backfill has to guess which one an old save belongs to, and a guess that cannot be told apart from a real derivation is permanent, because nothing later dares overwrite it.

So 1Retro now records how each save was filed: from a ROM hash, from a serial, from a filename, or guessed. Two things follow from that.

A guess gets corrected on its own. Next time a device syncs and hashes the actual ROM, naming the release exactly, the save moves to the right release instead of a second copy appearing on it.
You can overrule it. A save’s version now has a Move this save to a different game action. Pick the release it really belongs to, and the move is recorded as your decision, so no later sync argues with you. If you are the one holding the cartridge, you know better than the inference does.

If there are any issues, they should be eventually solved, or you can solve them manually yourselves. I’ve already corrected some issues on my accounts. The good news is, this is a one time pain. Now that the bandaid is ripped, we’ll see the improvements right away.

Just as a word of warning, the database still does not contain EVERY romhacks or prototypes ever made, so some games will still create standalones. I’m working on improving that, and it may still be a pain point. We’ll update you as we go.

Deleting a save now means the same thing everywhere

Three separate fixes, one theme.

Deletion is recoverable. Deleting a save moves it to a Trash that keeps it for 30 days, with a proper restore. Trashed saves are hidden everywhere else and sync clients treat them as gone. They still count against your storage until they are purged, which I would rather be honest about than surprise you with.

A deletion travels. Deleting a save on the web used to do nothing to the devices holding it, and the next device to sync cheerfully uploaded it again. The server could only say “there is no save here”, which meant two opposite things (you threw it away, versus this device has something new), and the engine had to take the safe reading and upload. It can now tell the two apart, so a deletion on the web reaches your devices.

And in the other direction. Deleting a save file on a device used to silently stop that save syncing to that device, permanently, because the only record that the device ever had it was the thing the cleanup pass deleted. Now the cloud copy is written back where it was. A missing folder is still left alone: an unplugged drive is a far more common explanation than a deleted file, and re-creating a library into a missing mount point is the one outcome worse than doing nothing.

The duplicate loop, and the storage it was eating

If one device held two saves for the same game, a RetroArch install and a handheld’s card both holding Zelda, or a .sav and a .srm side by side, they uploaded each other forever. Each overwrote the other’s place in sync, the next sync read that as a change from the cloud, and sent it straight back. Every sync, indefinitely.

Now one of them syncs and the rest are reported as skipped, with the reason naming which file took the game. The one that wins is whichever you played most recently, so it follows you rather than whichever the device happened to find first. Play the other copy and it takes over on the next sync.

The cleanup mattered as much as the fix. Every one of those redundant uploads counted against your quota even though it was the same bytes over and over, so that release also collapses duplicate versions, gives the space back, and clears duplicates out of the trash in the same pass. Re-uploading a save you already have somewhere in a game’s history now moves the existing one to the top instead of storing it twice, and a save keeps the date it first arrived rather than jumping to the top of your library every time a device re-sends it.

Two new kinds of device

NextUI and MinUI handhelds. There is a proper Pak app now. It covers the TrimUI Brick and Smart Pro (tg5040), the Smart Pro S (tg5050), the Miyoo Flip (my355), and Anbernic’s RG35XX and 40XX family on MinUI (rg35xxplus). Unzip it into Tools, open 1Retro Sync, and the first launch shows a QR code with a short pairing code. After that it opens on a menu with Sync saves already selected, so syncing is one button press, and the screen tells you what it is doing as it goes. There is a Watch for saves toggle for background syncing, and Start watching at boot to pick that back up after a restart. It draws in your device’s own theme rather than fighting it. Setup guide is on the NextUI page.

Android, rebuilt. The Android app was rewritten on the same engine the desktop app runs, rather than being its own separate thing that drifted. Sign in with a QR code or a device ID, pick a background sync mode (off, every few hours, or as saves change), and it survives reboots and shows progress in a notification. Your saved sign-in is now protected by a key held in the Android Keystore, existing installs move over on their own, and there is an in-app log viewer and export for when something goes wrong and I need to see it. We’ll feature match the desktop app in time hopefully.

MiSTer got faster and bigger

Saves leave the device in about two seconds instead of up to thirty. The MiSTer daemon assumed it could not watch its own filesystem and polled every 30 seconds. Tested on real hardware, the assumption was simply wrong: the MiSTer kernel supports filesystem notifications, and every event that matters arrives, including the writes MiSTer itself makes when it flushes a core’s save RAM. It watches saves/ and games/ specifically rather than the card root, so asking for a screenshot no longer triggers a full sync cycle.
A library spread over SD and USB syncs as one. If your games live on a USB disk, wholly or partly, they were invisible before. Saves still land where the MiSTer’s own storage setting says they should, not next to the ROM, so a stock MiSTer finds them.
Progress bars on sync and ROM hashing, and it no longer throws away your login when it boots without a working clock.

OnionOS

Whole systems never synced, and now do. OnionOS names save folders after the emulator core, and one core covers several systems, so everything but the first was mislabelled and skipped entirely. Saves from alternative cores like Snes9x 2005 and gpSP were not being looked at at all.
A real SD-card package with an accurate setup guide, replacing the rough instructions that were there before.
The device stops reporting “Sync Complete” when it actually skipped or failed something.

Cartridges

SNES cartridges, via the SN Operator. Plug in a cart and back up or restore its save the same way Game Boy and GBA carts already worked.
Both readers at once. If you have a GB Operator and an SN Operator plugged in together, each gets its own card in the app with its own state, instead of the two fighting over one.
GBA cartridges, faster save-size detection, and MBC3 real-time-clock carts.
Ambiguous cartridges ask you. Some carts are indistinguishable between regional printings from their contents alone. Rather than picking one, the app shows you the candidates and remembers your answer.
The cartridge clock is visible. If a cart carries a real-time clock, the save now shows the date and time the cartridge itself thought it was. This was being recorded already and had no way to be seen.

Save contents

Two new save parsers, both checked against real saves rather than documentation alone:

Super Mario World reports exits taken, levels cleared, completion against the 96 goals, and which switch palaces you have pressed. (Lives, coins and powerups are not written to the cartridge, so there is nothing to report for them.)
Super Metroid reports the completion percentage the ending screen draws, play time, area, energy and ammo with their capacities, items and beams, bosses and golden statues, and which slot you played last.

I am actively working on upgrading the spec for 1Forge (the save parser and editor), and will publish something when the time is right.

`.1saves`

The Universal Saves Format spec I have been working toward is published, and 1Retro now speaks it: you can upload a save as a .1saves bundle and download one back, byte for byte identical. Nothing is stored as a bundle; it is taken apart into the same rows and blobs a normal upload produces, and rebuilt on the way out, which is what stops the two paths ever disagreeing about what a save is. This is early and deliberately narrow (one artifact per bundle for now), but it is the piece that lets a save move between 1Retro and anything else that adopts the format.

Desktop app

A Saves view. Your whole cloud library, as box art, with the saves this particular computer holds no copy of drawn faded. You can see at a glance what is here and what is only up there.
RetroArch sources ask for your ROM folders too. RetroArch keeps saves in one place and games wherever you put them, and the only things that say where are retroarch.cfg and the playlists, neither of which exists until you have run “Scan Directory”. When both were silent, the source found all your saves and synced none of them. The setup form now asks for both, and takes a list of ROM folders because libraries routinely span drives.
Sync failures show their reason under the summary instead of just a filename.

Security

Boring and necessary, so briefly: device pairing codes are single-use and stored hashed. Deleting a device now logs it out immediately. App-password tokens are barred from privileged surfaces. The WebDAV prototype is rate-limited, quota-enforced, and now requires an explicitly granted role, because its directory layouts are still changing and the people mounting it should be people I handed it to on purpose.

Website

Three comparison pages, for Syncthing, RetroArch’s own cloud sync, and Dropbox and Google Drive. I tried to be fair in all three, including about the things they do better.
A /device page for typing a linking code by hand when you cannot scan the QR Code.
A rebuilt Downloads page that suggests the right build for whatever you are reading it on.
The blog moved from blog.1retro.com to 1retro.com/blog. Old links redirect.

Smaller things

A Discord link in the app sidebar, which takes itself away for good once you either click it or dismiss it. An invite that keeps asking people who already joined is just noise.
Storage limits are inclusive, so a limit of N actually allows N. That was a real off-by-one.
Accounts without itch.io no longer see RetroArch syncs reported as failed when the saves synced fine.

A code, since you read this far

notes-267 is good for 100MB of extra storage. Drop it into Settings, under Redeem a Code.

What’s next

The catalogue rework opened doors I want to walk through. A memory card carries the same serial a disc prints, which means a card can eventually resolve to real games with no ROM present at all, and that is the thread I want to pull next. Beyond that: wider .1saves adoption, getting the NextUI pak into the Pak Store proper, more parsers, and open sourcing the sync engine.

As always, if your setup does something strange, tell me on Discord or the forums.