KNULLI Scraper Finds the Wrong Game or No Match: Fix One Game Manually

by

Owner testing: NO — documentation-led workflow

Scope and meaning of “manually”

This guide fixes the scraper match for one game that is already visible in KNULLI’s EmulationStation frontend. Here, “manually” means choosing Input to change only the scraper search query, then manually selecting a preferred result for that game.

Input changes the scraper search query only. It does not rename the ROM, launch script, path, or frontend entry. This guide does not edit XML and does not use an undocumented metadata-editor GUI.

This is an identity-match procedure: use it when scraping returns no confident result, offers the wrong candidates, or has already applied the wrong result. It is not a repair for a missing game, failed launch, BIOS warning, emulator choice, broken Wi-Fi connection, or metadata that remains undisplayed after the supported refresh.

Choose the symptom before changing anything

  • The game is absent from its system list: stop and use Article #4: KNULLI games not showing up.
  • The visible game does not launch: stop and start with Article #19: visible-game launch failure. Use Article #5 only if a separate launch attempt shows an explicit BIOS warning; use Article #15 only if launch diagnosis reaches per-game emulator selection.
  • There is an actual Wi-Fi connection failure: stop and use Article #7: KNULLI Wi-Fi troubleshooting. A poor or empty result list alone does not prove a Wi-Fi problem.
  • There is no useful scraper result: follow No result below.
  • The candidates look wrong, but none has been applied: follow Wrong candidates before application.
  • A wrong result is already attached: follow Wrong result already applied.
  • The intended selection was accepted but still is not displayed after one refresh: stop and use Article #8: scraped box art or data not showing.

Do not infer why a search performed poorly. Without an explicit, non-secret error, the supported conclusion is only that no confident result appeared.

Supported device, versions, controls, and menu path

This documentation-led procedure is scoped to the Anbernic RG CubeXX / Allwinner H700 running KNULLI with its EmulationStation frontend:

  • Firefly 20241204
  • Gladiator II 20250813
  • Scarab 20260511
  • a current KNULLI build only while the official current scraping documentation continues to match this workflow

The current-build claim is date-bound to the documentation review on October 24, 2026. If the current documentation now uses different labels or a different hierarchy, stop and have the workflow revalidated; do not guess from this article. Localized interfaces may translate the English labels below.

For one visible game, the supported navigation is:

  1. Open its system category and highlight the game.
  2. Press and hold whichever configured face button launches games. Do not assume a fixed A or B button.
  3. Choose Scrape at the bottom of the game menu.
  4. Review candidates sorted by scraper source.
  5. If needed, choose Input at the bottom of the scraper screen and enter a corrected clean title or an international title.
  6. Select the preferred result only when it confidently matches the intended game.
  7. The scraper should close after the selection.
  8. If the intended information is not visible, use Start → Game settings → Update gamelists once, after the final intended selection.

The scraper closing shows that the UI accepted the selection. It does not prove that all metadata or media changed.

Eligibility and STOP conditions

Proceed only when all of these are true:

  1. The game is already visible in a KNULLI/EmulationStation system list.
  2. The build is Firefly 20241204, Gladiator II 20250813, Scarab 20260511, or a current build whose official documentation still matches this procedure.
  3. The symptom is limited to no result, wrong candidates, or a wrong result already applied.
  4. There is no known network or provider failure, and you are prepared to stop instead of looping requests.
  5. If ScreenScraper is used, you have a legitimate account and enter its credentials privately on the device.
  6. You can identify the intended game confidently from candidate details that are actually shown.
  7. Before replacing existing information, you can privately record the visible before-state and the relevant scraper settings.
  8. You accept that this process offers no guaranteed Undo or exact prior-state restoration.

STOP without repeated retries if any of these applies:

  • The game is absent: use Article #4.
  • The game is visible but does not launch: use Article #19; use Article #5 or #15 only if that separate diagnosis indicates BIOS or emulator selection respectively.
  • Wi-Fi connectivity itself is broken: use Article #7.
  • A provider reports authentication, quota, maintenance, blacklist, forbidden, service, timeout, or network failure: record only the provider name and exact non-secret error, then stop.
  • ScreenScraper would be used without a legitimate account or without keeping credentials private.
  • A corrected clean title and, if relevant, international title produce no confident result.
  • You cannot confidently distinguish the intended candidate.
  • The proposed fix requires a ROM or script rename, XML work, file access, deletion, a path/folder/extension change, an undocumented metadata-editor GUI, invented query syntax, or bulk scraping.
  • Existing visible information cannot be recorded, or overwrite uncertainty is unacceptable.
  • The scraper stays open after selection or shows an error: do not claim acceptance or success.
  • The intended selected data remains undisplayed after one Update gamelists: hand off to Article #8.

Record the visible before-state and decide overwrite behavior

Before correcting an entry that already contains information, make a private note of:

  • installed KNULLI release;
  • system category and the single game entry;
  • current visible title;
  • visible region/release, description, date, rating, artwork, or media that matters;
  • relevant scraper source and media preferences;
  • current Preferred region value;
  • current Overwrite descriptions state;
  • current Overwrite medias state;
  • intended title/system and expected region/release;
  • optional tightly cropped screenshots with account, network, path, library, and unrelated-game details removed.

These notes and screenshots document visible prior state only. They are not a backup, do not capture hidden state, and cannot restore data.

Use the controls deliberately:

  • Set Overwrite descriptions using its on-screen explanation so an existing description is preserved, or so replacement is intentionally allowed.
  • Set Overwrite medias using its on-screen explanation so existing media is preserved, or so replacement is intentionally allowed.
  • Do not prescribe a switch direction: its presentation may vary. Record the prior state before changing it.
  • These controls cover descriptions and media only. They do not establish protection for titles, dates, ratings, regions, hidden fields, or every metadata category, and they do not provide Undo.
  • Treat Preferred region as broader scraper context. Record it, but do not make it a required one-game step or change it merely to force one candidate. If you intentionally change it, accept the broader effect and later restore only the setting—not the old entry data.

Before intentionally overwriting valuable curated information or media, Article #14 is an optional broader precaution. It is not an exact one-entry rollback and does not make restoration guaranteed.

Short Answer

Highlight the already-visible game, hold whichever configured face button launches games, and choose Scrape. If the correct candidate is not already present, choose Input, type a clean corrected title, and try the international title if a regional or localized title fails. Compare only candidate details actually shown and select a confidently identified preferred result. If its information does not appear, run Start → Game settings → Update gamelists once. If it still does not appear, stop and use Article #8.

Never select a merely plausible result, loop provider requests, rename the ROM, or edit XML.

Branch A: no result

  1. Confirm that every eligibility condition passes and no STOP condition applies.
  2. Record the visible before-state and the current Preferred region, Overwrite descriptions, and Overwrite medias states. If the entry contains no useful metadata or media, record that fact; a broader backup is not mandatory merely because it is empty.
  3. Highlight the game in its system category.
  4. Hold whichever configured face button launches games.
  5. Choose Scrape.
  6. When no useful result appears, choose Input at the bottom of the scraper screen.
  7. Enter a clean, corrected game title. Remember: this changes only the scraper query, not the ROM, script, path, or entry name.
  8. If a regional or localized title fails, try the international title.
  9. Review the results sorted by source. Compare only what is actually shown, such as title, system/platform, region/release, source grouping, and available metadata or media.
  10. Select only a preferred result that confidently matches the intended game.
  11. Confirm that the scraper closes. If it stays open or reports an error, record the non-secret UI state and stop.
  12. Inspect the same entry. If intended information is not visible, run Start → Game settings → Update gamelists once.
  13. Inspect the entry once more. If the information still is not displayed, stop and use Article #8.

If the corrected or international query never returns a confident candidate, stop. Do not invent IDs, hashes, CRCs, serials, region operators, wildcards, quotation rules, or provider-specific syntax. Do not make another general retry.

Branch B: wrong candidates before application

  1. Do not select a result simply because it looks plausible.
  2. Compare source-sorted candidates using only fields actually shown. A missing field is not proof of a mismatch.
  3. If a confidently correct preferred result is already present, select it.
  4. If it is absent, choose Input and enter a clean corrected title.
  5. If needed, try the international title.
  6. Review the returned candidates and select only a confident match.
  7. If no confident candidate appears, stop. Do not diagnose catalog coverage, account state, quota, query behavior, or network health from a poor list alone.
  8. Confirm that the scraper closes. This proves UI acceptance only.
  9. Inspect the same entry. If necessary, use the one allowed Start → Game settings → Update gamelists after the intended selection.
  10. If the selected information remains undisplayed, stop and use Article #8.

Branch C: wrong result already applied

  1. Record the wrong visible title, metadata, and media, plus the current Preferred region, Overwrite descriptions, and Overwrite medias states.
  2. Decide category by category what must be preserved and what may be replaced. Using each control’s on-screen explanation, set it so existing descriptions or media are preserved, or allow replacement only when that named category is intentionally being corrected. Do not use blanket overwrite by default.
  3. If valuable information will be intentionally overwritten, consider Article #14 as an optional broader precaution, with the no-exact-rollback limit understood.
  4. Highlight the same visible game and hold whichever configured face button launches games.
  5. Choose Scrape for this one game.
  6. If a confidently correct result is offered, select it. Otherwise choose Input and enter a corrected clean title or, if needed, the international title.
  7. Select only the intended preferred result.
  8. Confirm that the scraper closes; do not treat closure as proof of field or media changes.
  9. Inspect the same entry. If necessary, run the one allowed Start → Game settings → Update gamelists after this final intended selection.
  10. If corrected information still is not displayed, stop and use Article #8.
  11. If the applied identity is still wrong, do not cycle. A further one-game scrape is appropriate only if a clearly different, confidently identified candidate is already available and provider limits allow the request. This is a bounded correction after a wrong application, not a general retry policy.
  12. Restore any scraper setting changed solely for this correction. Restoring a setting does not restore the entry’s previous data.

Provider, account, network, and quota limits

One-game scraping uses all available sources and sorts candidates by source. “Available” matters: it does not mean that every documented source responds, contains the title, agrees with another source, returns the same fields, or follows a guaranteed fallback order.

KNULLI documents ScreenScraper, TheGamesDB, and ArcadeDB, but this article does not claim that every documented source answers any particular request. If ScreenScraper is used, use a legitimate account and enter credentials privately on the device. Never place a username, password, email address, token, account screen, or quota identifier in an article, screenshot, log, comment, URL, or fixture.

Some sources impose daily data or media limits. Avoid unnecessary requests. There is no promised fallback sequence, retry interval, service availability, or equivalent behavior among providers. If the screen shows an authentication, quota, maintenance, blacklist, forbidden, service, timeout, or network error, note the provider and exact non-secret error text, then stop. Do not create extra accounts, bypass limits, or assume another provider will behave identically.

A no-match is not proof of failed Wi-Fi. Use Article #7 only for an actual connectivity symptom.

Verify the same entry after one accepted selection

Use this deterministic pass after the final intended candidate is selected:

  1. Confirm that the scraper screen closes. That shows UI acceptance only.
  2. Return to the same entry and inspect it immediately.
  3. If the intended information is not visible, run Start → Game settings → Update gamelists once—no more than once.
  4. Inspect the same entry again.

Compare only evidence that is returned and actually visible:

  • visible title;
  • system/platform context;
  • region/release, where shown;
  • art or media, where returned and shown;
  • description, date, and rating, where returned and shown.

Not every source or candidate provides every field. A pass does not require every field; it requires the available inspected evidence to be internally consistent with the intended game. If the selection was accepted but the intended data remains undisplayed after the one refresh, Article #8 owns that display problem.

What this check proves—and what it does not

It proves only

  • the one-game scraper UI accepted the selected provider result;
  • the same frontend entry displays the inspected identity evidence immediately or after one supported refresh;
  • the query correction was sufficient for this provider-dependent result at this time.

It does not prove

  • ROM or content identity, integrity, completeness, legality, safety, hash, CRC, or serial;
  • game launch, gameplay, BIOS correctness, emulator/core correctness, controls, performance, or stability;
  • universal correctness of the provider record or agreement among providers;
  • future provider availability;
  • that every artwork asset matches the same regional revision unless it was explicitly shown and checked;
  • that hidden fields were unchanged;
  • that a bulk scrape would choose the same result;
  • that Retro Fix Lab reproduced this workflow on owner hardware.

Recovery has no documented Undo

Re-scraping is a correction, not rollback. If the chosen result is wrong, return to the same visible game, use one-game Scrape, choose Input if needed, enter a corrected or international title, and select another confidently identified result—or the previous result if it is currently offered and desired. Use at most one Update gamelists after the intended selection if it is not visible.

There is no documented Undo in this workflow. The previous candidate may no longer be offered, notes and screenshots cannot restore data, and the former field/media state may not be reconstructable. Re-scraping works only if a suitable result is currently available and the overwrite settings permit the intended category replacement. Exact prior-state restoration remains unconfirmed without a complete compatible backup and a separately validated restore process.

Do not use raw XML editing, delete media, replace a gamelist, factory-reset, reflash, rename the ROM, or apply a bulk overwrite as recovery for this one-game match problem.

Symptom handoffs

This procedure does not need an Article #13 file-access step and does not use a core-selection link.

FAQ

Does Input rename my ROM or game entry?

No. Input changes only the scraper search query. It does not rename the ROM, launch script, path, or frontend entry.

Should I use a regional name or an international title?

Start with a clean corrected title. If a regional or localized title does not produce a confident result, try the international title. Neither query guarantees a match.

Should I change Preferred region?

Not as a mandatory one-game step. Record it as broader scraper context. Change it only when you understand and accept its broader effect; restoring the setting later does not restore previous entry data.

Which overwrite setting should be on or off?

Do not assume a universal switch direction. Read the on-screen explanation and set Overwrite descriptions or Overwrite medias so the existing category is preserved, or so replacement is intentionally allowed. Those controls do not cover every field and do not provide Undo.

Can I keep scraping until a result appears?

No. Stop when a corrected/international query yields no confident candidate or when a provider reports an auth, quota, service, timeout, or network error. The only bounded further scrape described here follows a wrong application and requires a clearly different, confident candidate already to be available, with provider limits permitting it.

Does a closed scraper screen prove the metadata changed?

No. It shows that the UI accepted the selection. Inspect the same entry—immediately or after the one allowed gamelist refresh—to prove that the available visible fields show the intended identity.

Can I restore the exact previous result?

Not reliably. You may select the previous candidate only if it is currently offered and desired. There is no documented Undo, and before-state notes or screenshots are not a restoration mechanism.

What should an example screenshot show?

Use an illustrative fictional title such as Star Harbor, generic or appropriately licensed artwork, and tight crops of Scrape, Input, or Start → Game settings → Update gamelists. Redact ScreenScraper/account details, SSID, IP/MAC, hostname, RetroAchievements identity, drive labels, personal paths, ROM filenames, full libraries, and unrelated games. Alt text must not reveal redacted information or imply owner testing.

Sources and evidence labels

This article is documentation-led; Owner testing: NO.

  • FACT: Official RG CubeXX/H700 release assets exist for Firefly 20241204, Gladiator II 20250813, and Scarab 20260511.
  • SOURCE-CONFIRMED: Official KNULLI documentation supports the RG CubeXX/H700 EmulationStation context, the neutral configured-launch-button wording, one-game Scrape, query-only Input, results sorted by available source, international-title searching, deliberate overwrite controls, scraper closure after selection, and Start → Game settings → Update gamelists.
  • COMMUNITY REPORT: None used as procedural proof.
  • UNCONFIRMED: A supported GUI route called “Edit This Game’s Metadata,” an exhaustive set of fields changed by candidate selection, protection of every metadata field, provider fallback order, guaranteed availability, and exact prior-state restoration. None is used as an instruction here.

Official KNULLI documentation

Official release assets