Set or reset a RetroArch playlist's default core on Android
Prove the content works by loading the intended core and file directly, then change the playlist's core association in RetroArch's Playlists settings. Test one entry before applying the association broadly. If a mixed playlist needs different cores, leave detection enabled or split it by system instead of forcing one core.
Do this in order
- 01
Record the RetroArch build, exact core name and version, playlist name, and one lawful test file; back up the playlist before changing its association.
- 02
Use Load Core, select the intended core, then use Load Content to prove that the same file opens outside the playlist.
- 03
Open Settings → Playlists, select the affected playlist, and inspect its default core association; menu placement can vary by driver.
- 04
Choose the verified core only when every entry in that playlist belongs to the same supported system and set generation.
- 05
Return to the playlist and launch one known-good entry; confirm the displayed core name and version before testing a second entry.
- 06
If entries require different cores, restore automatic detection or divide the content into system-specific playlists rather than editing filenames or ROM bytes.
Decision and diagnostic table
| Observed result | Likely layer | Next decision |
|---|---|---|
| Direct load works; playlist uses another core | Playlist core association | Set the verified core for that playlist |
| Direct load fails with the intended core | Core, content, BIOS, or version mismatch | Capture the first log error before editing the playlist |
| Only one entry needs another core | Mixed playlist design | Use detection or a separate playlist |
| Core name matches but behavior differs | Core build or option mismatch | Compare exact version and scoped overrides |
Direct loading is the control experiment
A playlist stores launch metadata; it does not prove that the chosen core can run the content. Loading the exact core and file directly removes the playlist association from the test and gives you a clean pass or failure.
Record the core name and version shown by RetroArch. Two MAME-family cores, or two builds with similar display names, can expect different ROM definitions and support different options.
Association and scanning solve different problems
Scanning decides which entries appear. Core association decides what RetroArch tries when an existing entry runs. Rescanning a healthy playlist can change labels or metadata without correcting the wrong launch core.
Libretro's current playlist documentation keeps the core path and core name as entry data and also supports choosing a core through the Playlists settings. Preserve the JSON playlist backup so the change is reversible.
One playlist-wide core needs one compatibility boundary
A default core is safe only when the playlist is homogeneous. A custom favorites list can mix systems, while an arcade playlist can mix set generations that belong to different cores.
Do not force a convenient core across incompatible entries. Split the playlist or leave detection enabled, and keep version-specific arcade content with the core it was lawfully prepared for.
Changing a playlist does not grant rights to ROM, BIOS, CHD, artwork, or music files. Test only your own dumps or explicitly authorized content, and do not share the backed-up playlist if it exposes private storage paths.