emulators.xenia.Xenia

Provider key, xenia.

On; with the ROM cache enabled, launch boots a local copy of the ROM.

Human-readable name.

The storage root the save subtrees hang off.

content, the save and profile tree.

Bootable formats, best first.

The emulator log file.

On; activate empties every title's saved-game tree.

Unix time launch started Xenia at; infinity until it does.

Infinity rather than zero so an instance that never launched matches no file at all. Zero is newer than nothing, so every title in the container would read as written this session and save_and_exit would restamp and ship all of them.

Initialise the process handle and the session baseline.

Saved-game trees left in the content tree by an earlier session.

Scoped the way _session_title_dirs scopes the dump: only <XUID>/<TITLE_ID> pairs count as save data, and the profile package is skipped. Every XUID and every title id is swept, not just the incoming one, because a directory named for another account or another game holds the last player's saves just the same, and the exit restamp ships a touched title whole.

Drop the previous session's saved games before the archive restore.

The restore only writes the members this player's archive names, so a save the last player left behind would otherwise sit in the content tree readable by this one, and leave again in this player's own dump: the exit restamp ships a title whole once anything under it is written.

Only the saved-game content type and its header sidecars go. Installed DLC and title updates share the title directory, the profile package the save paths are keyed by has to survive for the next launch to sign in at all, and config, cache and shader dumps sit beside the content tree; none of that is a player's data.

Whether rel is a profile member, restored over whatever is on disk.

The clear leaves the profile package in place, so at restore time it is still the last player's, carrying the mtime the exit restamp gave it (the profile rides along with any title that saved, so it is routinely the freshest thing in the tree). The incoming archive's profile is older by construction, since it was taken in this player's previous session, and the newer-file guard would pass it over: the session would run, and then dump, under the last player's identity, propagating it to every player after them.

The guard does not describe this file. It exists so a restore cannot roll back progress made since the archive was taken, and a profile package holds no progress: nothing between the last dump and this restore wrote it, since the clear and the restore both run before the emulator boots.

Declare what Xenia takes: saved games in the directory form, with their headers.

Xenia has no states and no cards, so the save kind is the only one.

Read the signed-in profile's XUID, once per preflight.

This is the one file a placement hook reads. It sits outside the save subtrees and is only read, and preflight runs before anything is cleared or restored.

Place one declared save file under the signed-in profile.

Read the title id off a container path, or take RomM's.

Resolve a library entry to the file Xenia should boot.

A file is returned as given. A directory is resolved in order: an extracted dump's default.xex, then the best disc image or bare executable candidate, then an XBLA/Games on Demand content package.

Stop any running instance and launch Xenia against a ROM.

Xenia has no save states, so resume_slot is accepted for interface parity with other emulators but only logged, never acted on; the game always resumes from its own save data.

Content title dirs to ship whole, given what this session wrote.

A 360 save is a directory tree under content/<XUID>/<TITLE_ID>/<CONTENT_TYPE>/<name> whose STFS header lives in a sibling Headers tree the guest only writes when the save is created. Scoping the dump to individually touched files would leave that header behind and restore a save the guest cannot name, so the title directory is the smallest unit that stays consistent.

The profile under <XUID>/FFFE07D1 joins any XUID that wrote something, touched or not: save paths embed the XUID, so saves restored without their profile land under an account the target container has never signed in.

A listing or walk that fails is logged and skipped rather than raised: the storage root can vanish under the walk, and the exit path calling this still has a report to hand back.

Stop Xenia and mark this session's content for the dump.