Resolve saves from the platform mapping, not only the play action

[gantoine]

Fixes #138.

What was happening

Save sync resolved the emulator only from the game's Playnite play action:

if (action != null && action.EmulatorId != Guid.Empty)
    return ...Emulators?.FirstOrDefault(e => e.Id == action.EmulatorId);
return null;   // -> "Save sync does not know where this game's emulator keeps its saves."

That action is a snapshot written once at import and never refreshed — ProcessData skips games that already exist, touching only favourite and completion status. So a mapping later repointed at another emulator leaves every game it had imported still pointed at the old one.

The reporter's screenshots show exactly that: their action is named Play in Dolphin (only the importer produces that string), while their mapping today is RetroArch / Dolphin - GC/Wii / Nintendo GameCube. No handler covers Dolphin, so sync gave up. Note the action also means the game launches with the old emulator — save sync only made it visible.

What this changes

The mapping fills gaps; it never overrides the launched emulator. The play action's emulator is what launches, so it is the save target. Syncing a different emulator's saves instead would download to a place the launched emulator never reads. The platform mapping is used only when the action names no emulator, or to supply a profile for that same emulator. It comes from the ROM sidecar ({sha1}.json), which every import rewrites, and is skipped when two importable mappings cover the platform, because then the sidecar only records whichever import ran last. When a stale action names an unsupported emulator, the message names the mapping's emulator so the user knows where to point the action. The real fix is the refresh below. The lookup that install and uninstall already did by hand is now IRomM.MappingFor(game).

The profile comes along. An action can name an emulator without naming a profile, and for RetroArch the profile identifies the core — a folder in the save path under sort_savefiles_enable. Resolving without it means reads limp along via FindExistingSave but a download writes where RetroArch never reads. The profile is now borrowed from another candidate for the same emulator id (never across emulators).

Stale actions are repaired, not only worked around. An import repoints an existing game's action at its mapping's current emulator, but only while the action is still the plugin's:

• RomMRomLocal now records AppliedEmulatorID / AppliedEmulatorProfileID. Action still carries them → ours to repoint; differs → the user's, left alone.
• An action that already matches the mapping is recorded as ours only if we owned it before, so a user's matching choice stays theirs.
• Sidecars predating that field fall back to the name signature: an action still called Play in <the emulator it points at> is one the importer wrote. The reporter's game gets repointed on their next library update, launching included.
• If two enabled mappings target the same platform, no refresh happens at all — otherwise each pass would repoint what the other just wrote.

Three messages instead of one catch-all: no emulator set (and where to set one), Save sync does not support Dolphin yet. Supported: retroarch., and "could not work out where X keeps this game's saves". A missing ROM path gets its own, and falling through to the mapping is logged.

Shared sidecar helper. Games/RomMGameData.cs centralises the path, read and write, replacing four hand-rolled copies in RomM.cs (install, uninstall, version menu, delete).

Tests

SaveEmulatorResolverTests (action is authoritative, mapping only when no emulator is set, unsupported vs. none set, profile borrowing) and RomMPlayActionTests (ownership rules, unset-profile equivalence, the legacy name marker). Both new sources are linked into RomM.Tests.csproj.

Not verified locally

Draft because I could not compile or run the tests: no .NET SDK, msbuild or mono on this machine, and per DEVELOPMENT.md the project only builds on Windows. The PR build is the first real check. The end-to-end path — a stale action being repointed on import, and a save syncing through the mapping fallback before that — still wants a run against a real Playnite library.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 1/5

The PR does not appear safe to merge until save sync stays aligned with the launched emulator and action ownership is preserved across imports.

Summary

The PR adds mapping-based save-emulator fallback, records importer-applied play actions in ROM sidecars, and refreshes existing actions when mappings change. It also centralizes sidecar access and adds resolver and ownership tests.

• Save fallback can target an emulator different from the one the game launches.
• Action ownership and rival-mapping handling can misidentify which emulator or profile should remain in use.

_{Reviews (1) · Last reviewed commit: "Simplify the save-sync resolution and it..."}