RetroArch Cores 2026: 200+ in 12 Steps, 30 Min

RetroArch does not emulate anything. This is the first thing to understand and the thing most tutorials never say out loud. RetroArch is a frontend: a shell, a very opinionated menu system with shaders bolted on and a controller-first interface designed to be driven from a couch. The actual emulation, the part that turns a file on a memory card into Super Metroid, happens inside a core. A core is someone else's emulator, recompiled as a shared library and loaded at runtime. Get the core wrong and nothing boots. Get the right core onto the wrong hardware and it runs at eleven frames per second while you quietly blame the hardware. The hardware is usually fine. You brought a cycle-accurate emulator to a fistfight.

So this is a tutorial about cores, not about RetroArch's wallpaper. By the end you will know what a core actually is, which one to install for each system, how to install two hundred of them in about twelve steps and half an hour, and how to configure them so your settings survive a reboot. The version numbers are current as of August 2026, the traps are real, and the opinions are not for sale.

What a Core Actually Is

Before you download anything, understand what you are downloading. A core is not a plugin, not a theme, and not a ROM. It is an emulator that has agreed to speak a common language so that one frontend can drive all of them.

A core is an emulator wearing a uniform

RetroArch is the reference frontend for the libretro API, an interface that lets an entire zoo of emulators expose the same handful of functions: load content, run one frame, hand back audio and video, take input. A core is any emulator, or occasionally a whole game engine, recompiled against that API and shipped as a dynamic library. That means a .dll on Windows, a .so on Linux and Android, and a .dylib on macOS. Snes9x, Mednafen, PCSX2, Dolphin, Genesis Plus GX, mGBA: none of these were born inside RetroArch. They were adopted. RetroArch itself is licensed GPLv3, lives on GitHub with north of 13,200 stars, and its entire job is to load those libraries and then get out of the way. If you remember one sentence from this section, remember that the frontend is the furniture and the core is the engine.

Cores versus standalone emulators

The obvious question: why run Mednafen through RetroArch instead of just running Mednafen? Because the frontend hands every core the same amenities for free. Shaders, netplay, save states, rewind, run-ahead latency reduction, per-game input remaps, and native RetroAchievements all work identically whether you loaded a NES core or a PlayStation core. You learn the interface once. The cost is lag, in the release-schedule sense: a libretro core can trail its standalone parent by weeks, because a human has to port each upstream change and rebuild. The Dolphin core is the tidy example. A forum update dated 15 October 2025 announced it had been dragged to current stream october 2025, which tells you two useful things at once. The core is maintained, and it is maintained by hand on a cadence that is not upstream Dolphin's. That same thread, sensibly, points people at the RetroArch Core Downloader and the libretro documentation rather than at some loose binary on a file host, because that is how cores are meant to reach you. You can read the frontend's own history and scope on the RetroArch Wikipedia article and the source on the libretro/RetroArch GitHub repo.

The 200-plus number is platform arithmetic

The official retroarch.com site advertises 200-plus cores, and its Cores page was last touched on 22 August 2026, so the catalogue is unambiguously alive. Yet plenty of 2026 setup guides say 100-plus, the Android build exposes exactly 127, and a webOS rebuild from December 2025 shipped 170-plus for 32-bit ARM. None of these numbers are wrong. The catalogue is one thing; what your specific Core Downloader shows is another, because the buildbot only serves cores compiled for your operating system and your CPU architecture. The 200-plus figure is the union of everything ever built. The number you actually see is the intersection with your device. Keep that distinction in your head and half of the confusion about missing cores evaporates before it starts.

Prerequisites and BIOS

This is a technical tutorial, so here are the concrete prerequisites: a current RetroArch build, hardware honest enough to run what you intend to emulate, and, for a good third of the catalogue, real BIOS files that RetroArch will never give you.

Software versions that matter

The current stable release is RetroArch 1.22.2, published on 20 November 2025. The 1.22 line had a rough birth: 1.22.0 shipped a shader black-screen bug that was fixed in 1.22.1 and 1.22.2, so if you are on 1.22.0 and staring at a black rectangle, that is your cue to update rather than to reinstall your GPU driver. The prior milestone worth naming is 1.21.0 from 29 April 2025, which is the anchor most 2025-era core coverage points back to. Do not run a years-old build and expect the downloader to behave, because the buildbot changed its core file layout on 24 May 2026, and installs older than that can find their cores suddenly unrecognised. Distributions package the surrounding data too: Arch Linux's libretro group has listed things like libretro-core-info at 1.20.0-1 and retroarch-assets-xmb at 1:528-1, which is a reminder that the info files and menu assets version independently of the frontend.

Hardware reality, stated plainly

Emulation cost scales with the accuracy of the core and the age of the system, not with the size of the ROM. A cycle-accurate SNES core wants roughly a 4 GHz CPU core to itself. A Nintendo 64, a PlayStation 2, or a 3DS core wants a real desktop. A cheap ARM handheld tops out, realistically, at the original PlayStation. The table below is the blunt version of that ladder.

If your handheld sits in that first row, you are living at the PlayStation ceiling for good silicon reasons, a limit explored in detail in our breakdown of why the Miyoo Mini Plus stops at PS1. It is not a firmware problem, and no core will fix a 2D GPU.

BIOS files: RetroArch ships none

A large slice of the catalogue will refuse to boot without a system BIOS, and RetroArch does not include a single one. PlayStation, PS2, Saturn, Sega CD, and the Nintendo DS all want real firmware dumps, matched by hash, dropped into your system directory. The Machine will be precise about the law, because someone has to be: dumping the BIOS from a console you own is your own affair, but distributing those files, or downloading them from a stranger, is copyright infringement, full stop. That legal contour is the same one outlets like Ars Technica have mapped through years of emulation coverage. Put the files in system/, verify them against the hashes the core lists under Information, and move on. A core with a missing BIOS produces a black screen or a hard refusal, not an error dialog that explains itself.

Installing Cores in 12 Steps

Installing cores is not hard, but the order is load-bearing. A single misordered step is responsible for the majority of empty-downloader complaints on the forums. Do it in this sequence and it takes about thirty minutes the first time, most of which is you deciding which systems you care about.

The one rule: Core Info Files first

Before the Core Downloader will show you anything useful, RetroArch needs the core info files. These are the manifest: small text files that tell the frontend each core's name, the system it emulates, the file extensions it accepts, and which BIOS it needs. Skip them and the downloader looks empty, or the cores you grab load as unrecognised and refuse to run. So the first thing you do inside Online Updater, before touching the downloader itself, is Update Core Info Files. This is the single most common mistake in the entire process, and it is a menu item you can hit in two seconds.

Main Menu
  Online Updater
    1) Update Core Info Files      [do this FIRST]
    2) Update Assets
    3) Update Databases
    4) Core Downloader            [now it is populated]
    5) Update Installed Cores     [refresh everything later]

The twelve steps in order

Each step below has a reason attached, because a sequence you understand is a sequence you can debug.

1. Update RetroArch itself. Core builds target the current API; an old frontend and a fresh core disagree. Use your package manager or the installer from the official site.
2. Open the Online Updater from the Main Menu. If it is missing, go to Settings, User Interface, Menu Item Visibility, and switch on Show Core Downloader. RetroArch hides it on some builds by default.
3. Update Core Info Files. The manifest, as above. Without this the next steps are theatre.
4. Update Assets. This pulls menu icons and system logos so the interface stops showing you placeholder boxes. Cosmetic, but it removes noise that looks like breakage.
5. Update Databases. These power playlist scanning and ROM name matching, so your library shows real titles instead of filenames.
6. Open the Core Downloader. It is now populated, because the info files exist. You are looking at the cores built for your exact platform and architecture, not the full 200-plus catalogue.
7. Pick a core by system, not by name. Browse to the system you want, for example Nintendo, Super Nintendo, then choose a core such as Snes9x. Do not download by half-remembered name; download by the system heading.
8. Download it. The core lands in your cores directory, the path RetroArch calls libretro_directory. The matching info file is already there from step three.
9. Load Core, then select the core you just downloaded. This confirms the library actually initialises on your machine before you involve a ROM.
10. Load Content and point at a game file. If it boots, that core is proven end to end. If it does not, you have isolated the problem to this one core rather than your whole setup.
11. Update Installed Cores whenever you return. One pass refreshes every core you own to the latest buildbot version, which matters because cores move on a rolling basis.
12. Set core options and save an override. Optional now, essential later; the config section below is where this becomes real.

The libretro project documents this same flow in its own words in the Downloading cores guide, which is worth a read if a step ever behaves differently on your platform.

Expected output: proving it worked

After loading a core, open Information, Core Information. A healthy install looks like the block below, with a real system name and, where relevant, the firmware listed as present. If the firmware line says missing, revisit your BIOS directory.

Information > Core Information
  Core name:            Beetle PSX HW
  System name:          Sony - PlayStation
  System manufacturer:  Sony
  Supported extensions: cue|toc|m3u|ccd|exe|pbp|chd
  Firmware:             scph5500.bin (present)
                        scph5501.bin (present)
                        scph5502.bin (present)

Picking the Right Core

The downloader offers you options for a reason: most systems have more than one core, and they are not ranked by quality, they are ranked by tradeoff. Choosing well is the difference between a library that runs and a library that stutters.

Accuracy versus speed is the whole game

There is essentially one axis that matters, and every core sits somewhere on it. At one end are the cycle-accurate cores that reproduce the original hardware's timing bug for bug: bsnes Accuracy for SNES, Beetle PSX for PlayStation, Mesen for NES. They are correct, and they are heavy. At the other end are the performance cores that cut corners you will mostly never see: Snes9x, PCSX ReARMed, PicoDrive. They run on a toaster. The right choice is not the most accurate core available, it is the most accurate core your hardware can hold at full speed. A cycle-accurate SNES core that runs at 40 fps is worse than a fast core that runs at 60, every single time. Match the core to the silicon, not to your pride.

The per-system cheat sheet

Here is the short version for the systems people actually emulate, with an accurate default and a lighter fallback for weaker hardware.

Running more than one core per system

You are allowed, and often wise, to keep two cores for one system. Run the accurate core for the handful of finicky titles that need it and the fast core for everything else. RetroArch remembers a per-game core association through playlists, so once you set Super Mario RPG to launch under a specific SNES core it stays that way without a global setting. The Sega family is the classic case: keep Genesis Plus GX as your default because it is 100% accurate for Mega Drive, Sega CD, Master System, Game Gear and SG-1000, then add PicoDrive purely for the 32X games Genesis Plus GX cannot touch. The core-specific behaviour of Genesis Plus GX is documented in the libretro Genesis Plus GX library page, which is the sort of per-core reference worth bookmarking.

The Hard Systems

Most systems are solved. A few are not, and they are where beginners lose an afternoon. Three deserve their own section in 2026: Nintendo 64, PlayStation 2, and the 3DS.

N64 is a minefield with a pinned exit

The mainline N64 core is Mupen64Plus-Next, which bundles the GLideN64 high-level renderer, the angrylion software renderer, and the ParaLLEl RDP and RSP plugins for low-level accuracy. It is the documented default on the libretro Mupen64Plus library page. It also regressed in early 2025: certain titles, Stunt Racer 64 and World Driver Championship among them, stopped loading entirely. The community response was to pin an older build, and a forum post from 2 January 2026 captured the mood exactly, describing users as stuck with the last good version which is from January. If a game refuses to load under the current Mupen build, that is why. The accuracy-first fallback is ParaLLEl N64, a Vulkan low-level core that is more faithful but narrower in compatibility. N64 accuracy is hard enough that some people give up on software entirely and buy dedicated silicon; if that is you, our look at the Analogue 3D firmware and its N64 upscaler covers the hardware route and its own accuracy caveats.

PS2 arrived, but only for x86

PlayStation 2 emulation landed in the downloader with the 1.22 line in November 2025, in the shape of LRPS2, a hard fork of PCSX2. Read this part carefully, because it saves you an hour of hunting: LRPS2 is x86_64 only. Windows, Linux, and macOS through Rosetta. There is no Android build, no iOS build, and no ARM-Linux build, so if you are looking for it on a handheld you will not find it, and nothing is broken. It carries a new renderer called ParaLLEl-GS by Themaister, it needs a real PS2 BIOS in your system directory, and its game-compatibility database is now embedded in the core rather than a separate file you have to manage. The libretro LRPS2 library page is the reference. If your device is ARM, treat PS2 as a desktop-only system and plan accordingly.

3DS: Citra is dead, and Dolphin is fine

Citra, the long-running 3DS emulator, was taken down, and its libretro core went with it. The successor is Azahar, a merge of the most active Citra forks including PabloMK7's build and Lime3DS. Azahar's first official libretro core shipped as 2125.0 Alpha 4 across six operating systems, and the line has since advanced to the 2126.0 release-candidate range. If you have an old Citra core sitting in your cores folder, delete it and download Azahar; the old one is not coming back. GameCube and Wii, by contrast, are in good shape: the Dolphin core is actively maintained and was synced to upstream in October 2025, so a modern desktop handles both without drama.

Cores on ARM and Android

Everything above assumes a desktop. The moment you move to a handheld or a phone, two new constraints appear that will silently sabotage a naive install: CPU architecture, and platform store policy.

The armv7 versus aarch64 split

ARM is not one target. Older and cheaper devices are 32-bit armv7; newer ones are 64-bit aarch64. A core built for one will not load on the other, and the failure looks like a generic failed to load core with no hint about why. The webOS rebuild from December 2025 shipping 170-plus armv7 cores plus an experimental aarch64 set is a snapshot of how fragmented this is. Third-party build repositories such as christianhaitian's retroarch-cores exist precisely to serve prebuilt arm64 and armhf binaries for handheld distributions. The practical rule: know whether your device is 32-bit or 64-bit before you download a single core, and if a core will not load, suspect the architecture before you suspect anything else. Budget ARM handhelds also run into the PlayStation ceiling discussed earlier, which is the same silicon limit that defines the entire class of device no matter how many cores you throw at it.

Android's 127-core walled garden

Android is its own country. The Play Store build is updated twice a week and ships with 50 hand-curated libretro cores delivered through Google's own servers. Beyond that, the platform advertises access to 127 cores in total. The catch, and it is a real one, is that the in-app Core Downloader no longer connects directly to the Libretro build infrastructure on Android, because Google Play policy forbids an app from pulling executable code from a third-party server at runtime. So the smooth 50 come from Google, the wider set arrives through a different path, and some cores you would grab in one tap on a PC require a sideload or an alternative store build on Android. If you are choosing an Android handheld with cores in mind, our comparison of the 2026 Retroid Pocket lineup is the practical starting point, and the platform's wider reach has been tracked for years by outlets like Engadget.

Distro-bundled cores

The happiest path on a handheld is often not to touch the downloader at all. Purpose-built distributions ship curated core sets already matched to the hardware. Lakka, RetroArch's own distro, reached 6.1 on 23 February 2026 carrying RetroArch 1.22.2, with every existing libretro core refreshed to its latest upstream version and several new cores added on top, so 2026 was a year of catalogue growth and not just maintenance. Batocera, muOS, ROCKNIX and OnionOS do the same job with their own curation, which is why our Batocera install walkthrough barely mentions the downloader: the cores are already there and already correct. And if you have concluded that software accuracy is a treadmill, the FPGA world reframes the whole problem by making accuracy a hardware property rather than a core setting, a scene we cover through the MiSTer FPGA community.

Overrides and Core Options

A core that runs is only half the job. The other half is making your settings stick, per game, without rewriting your global configuration every time. RetroArch's override system is powerful and almost entirely undocumented in plain language, so here it is in plain language.

The override hierarchy

RetroArch applies configuration in layers, most specific wins. The order, from weakest to strongest, is: the global retroarch.cfg, then a per-core override, then a per-content-directory override, then a per-game override. A game override beats a core override beats the global. You save these from the Quick Menu under Overrides, choosing Save Core Overrides, Save Content Directory Overrides, or Save Game Overrides, and RetroArch writes them to predictable paths inside your config folder. The official Overrides guide is the canonical reference, but the shape is easy to hold in your head once you see the file paths.

# retroarch.cfg -- the settings that govern override behaviour
config_save_on_exit = "false"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
game_specific_options = "true"

# override files land here, most-specific wins:
#   config/<core>/<core>.cfg          (per core)
#   config/<core>/<directory>.cfg     (per content folder)
#   config/<core>/<game>.cfg          (per game)

Core options are a separate file

Do not confuse overrides with core options. Overrides are RetroArch settings such as aspect ratio or shader. Core options are the emulator's own knobs, such as a PlayStation core's internal resolution. Global core options live in retroarch-core-options.cfg, and per-game core options live in a .opt file beside the game override. Beetle PSX HW is the canonical example, and its real option keys are worth knowing because they are the ones you will actually change. The block below quadruples the internal resolution and enables PGXP, which straightens the wobbly polygons the PlayStation was famous for.

# config/mednafen_psx_hw/Gran Turismo 2 (USA).opt
beetle_psx_hw_renderer = "hardware_vk"
beetle_psx_hw_internal_resolution = "4x"
beetle_psx_hw_pgxp_mode = "memory only"
beetle_psx_hw_dither_mode = "internal resolution"
beetle_psx_hw_widescreen_hack = "disabled"

Input remaps live somewhere else again

Controller remaps are a third file type, stored as .rmp files under config/remaps/, keyed by core and optionally by game, and enabled through auto_remaps_enable. This is how you make the A and B buttons sit where your muscle memory expects on a per-system basis without disturbing your global controls. Save one from the Quick Menu under Controls, Manage Remap Files, Save Game Remap File.

# config/remaps/Snes9x/Super Metroid (USA).rmp
input_player1_btn_a = "8"
input_player1_btn_b = "0"
input_player1_analog_dpad_mode = "0"

Five Ways People Break It

Almost every core problem is one of a small number of self-inflicted wounds. Here are the ones that fill the forums, with the fix attached to each rather than left as an exercise.

Wrong core for the hardware

Pitfall 1: running a cycle-accurate core on weak silicon. You download bsnes Accuracy onto a Raspberry Pi, or LRPS2 onto a handheld, and blame the device when it crawls or never appears. Fix: pick the performance core in the cheat sheet above, Snes9x instead of bsnes, PCSX ReARMed instead of Beetle PSX HW, and reserve accuracy for hardware that can afford it. Pitfall 2: the wrong CPU architecture. An armv7 core on an aarch64 device, or an x86 core anywhere near ARM, fails to load with no useful message. Fix: confirm your architecture first and only download the matching build; on Android, remember that PS2's LRPS2 does not exist for ARM at all, so do not go looking.

Updater and versioning mistakes

Pitfall 3: skipping Update Core Info Files. The downloader looks empty, or downloaded cores load as unrecognised and refuse to run. Fix: run Update Core Info Files first, every time, then reopen the downloader. Pitfall 4: a stale frontend against fresh cores. After the buildbot changed its core file layout on 24 May 2026, installs older than that date can find cores that previously worked now failing to load. Fix: update RetroArch to the current stable, then run Update Installed Cores to pull rebuilt versions. And the N64 special case: if a specific game will not load under Mupen64Plus-Next, that is the early-2025 regression, so pin the January build or switch to ParaLLEl N64 rather than assuming your ROM is bad.

Files and persistence

Pitfall 5: missing BIOS and vanishing settings. A core that needs firmware shows a black screen when the BIOS is absent, not a helpful dialog. Fix: place the correct-hash BIOS in your system directory and verify it under Core Information. The sibling problem is settings that never save, or worse, settings that get clobbered on exit. That is config_save_on_exit quietly overwriting your global config every time you quit. Fix: set config_save_on_exit to false and make deliberate changes through the Overrides menu, so your per-game tweaks land in per-game files and your global config stays exactly as you left it.

Troubleshooting

When a core misbehaves, resist the urge to reinstall everything. Emulation failures are specific, and a specific symptom points at a specific cause. Diagnose before you demolish.

Turn on logging first

Before anything else, give RetroArch permission to tell you what is wrong. Under Settings, Logging, raise the Frontend Logging Level and Core Logging Level to a verbose setting, then reproduce the failure. A core that fails to load will usually name the exact missing symbol or wrong-architecture error in the log, which converts a guessing game into a lookup. On a command-line launch you will see the same output in the terminal in real time.

The symptom-to-fix table

The table below covers the failures that account for most core support threads. Work down the Likely cause column before you touch anything drastic.

The nuclear option

If the config itself is corrupt, and after a bad manual edit it can be, the fastest cure is to let RetroArch regenerate it. Back up your entire config directory first, because it holds your overrides, remaps and playlists, then delete or rename retroarch.cfg and restart. RetroArch writes a fresh default. Reapply your directory paths and behaviour flags from the working config at the end of this article and you are back in minutes, not hours.

Advanced Core Tips

Once the basics are solid, a few techniques separate a working setup from a good one. None are necessary; all are worth knowing.

Nightly cores from the buildbot

The stable Core Downloader is deliberately conservative. When a core has a fix that has not yet reached a stable build, or when you are chasing that pinned N64 version, you go to the libretro nightly buildbot directly. Manual installation is three steps: download the correct architecture's core archive, unzip it into your cores directory, and drop the matching info file alongside so RetroArch recognises it. The risk is obvious, nightlies are untested, so keep the stable core you are replacing in case you need to revert.

# Manual nightly install (Linux example, Beetle PSX HW)
# 1. download the .so.zip for your architecture from the buildbot
# 2. unzip into your cores directory
unzip mednafen_psx_hw_libretro.so.zip -d ~/.config/retroarch/cores/
# 3. copy the matching mednafen_psx_hw_libretro.info alongside it
# 4. in RetroArch, Load Core, and the nightly now appears

Run-ahead and latency

RetroArch can make emulated games feel lower-latency than the original hardware through run-ahead, which internally runs the core one or more frames into the future and rolls back, hiding the input lag baked into the original game. It is not free: it needs a deterministic core and real CPU headroom, ideally with a second instance so the rollback does not stutter. Enable it per core, start with a single frame, and back off if you hear audio crackle. On weak hardware, leave it off; it is a luxury for machines with cycles to spare.

RetroAchievements and per-core config at scale

Cheevos are native to RetroArch, supported directly by the core, with no browser extension. Hardcore mode raises the stakes by disabling save states, cheats, rewind and run-ahead, which is the point, since those are the tools that would trivialise the achievements. If you run many systems, your config directory becomes a small filesystem of per-core folders, each with its own overrides and options. Treat it like code: back it up, and when you find a setting that works, save it at the narrowest scope that makes sense so it does not leak into unrelated games. The libretro documentation hub covers each core's options in depth when you need the exact key names.

A Complete Working Config

Here is a full, sane starting configuration you can adapt. It sets your directories, makes overrides behave, and leaves the latency and achievement features as opt-in. Paste the relevant keys into your retroarch.cfg, adjust the paths to your platform, and build from there.

The retroarch.cfg essentials

# ~/.config/retroarch/retroarch.cfg  (essentials only)

# --- Directories ---
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"
system_directory = "~/.config/retroarch/system"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"
core_options_path = "~/.config/retroarch/retroarch-core-options.cfg"

# --- Core / override behaviour ---
config_save_on_exit = "false"
auto_overrides_enable = "true"
auto_remaps_enable = "true"
game_specific_options = "true"
core_set_supports_no_game_enable = "true"

# --- Latency (opt-in, needs CPU headroom) ---
run_ahead_enabled = "false"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

# --- RetroAchievements ---
cheevos_enable = "true"
cheevos_hardcore_mode_enable = "false"

A per-core override example

This file applies to every game loaded under Beetle PSX HW, sitting above global config but below any per-game override. It is where you put the settings you want for all your PlayStation games at once.

# config/mednafen_psx_hw/mednafen_psx_hw.cfg
# Applies to EVERY game loaded with Beetle PSX HW
video_shader_enable = "true"
video_smooth = "false"
aspect_ratio_index = "22"
video_scale_integer = "true"

Keeping cores current

Cores move, so the last piece of any working setup is a habit, not a file. Update the frontend with your platform's package manager, then run Update Installed Cores inside RetroArch to rebuild every core against the latest buildbot. The three commands below cover the common desktops; after any of them, open RetroArch and do the in-app core refresh.

# Windows (winget)
winget upgrade Libretro.RetroArch

# Linux / Steam Deck (Flatpak)
flatpak update org.libretro.RetroArch

# macOS (Homebrew cask)
brew upgrade --cask retroarch

That is the whole discipline. Install the info files before the cores, match the core to the hardware instead of to the marketing number, keep your accurate and fast cores side by side, and let overrides carry your per-game settings so your global config stays clean. The libretro forums keep a busy Core and Feature Requests board, active as recently as 22 June 2026, which is the clearest sign that this catalogue is still moving under you. Set it up the way this guide describes and the movement becomes an update you run on purpose, not a surprise that breaks your library on a Tuesday.