[bug] Some Jaguar CD CUE/BIN images fail to load on Android

[ShyChimchar07]

Game / ROM

Multiple Jaguar CD titles using CUE/BIN images. Confirmed examples: - Alice's Mom's Rescue! (Europe) (En,Fr,De,Es,It) (Unl) - CUE/BIN - World Tour Racing (Jaguar CD) - CUE/BIN

Steps to reproduce

1. Open RetroArch on Android.
2. Load the Virtual Jaguar libretro core.
3. Load an affected Jaguar CD game from its .cue file.
4. The game fails to boot correctly.
5. Load the same CUE/BIN image with the Virtual Jaguar libretro core on Windows.
6. The game boots on Windows.

Confirmed with:

• Alice's Mom's Rescue! (Europe) (En,Fr,De,Es,It) (Unl)
• World Tour Racing (Jaguar CD)

Alternative disc-image formats such as CDI can boot these titles on Android, while their CUE/BIN versions fail.

Expected vs actual

Expected:
Jaguar CD CUE/BIN images that boot with the Virtual Jaguar libretro core on Windows should also boot correctly on Android.

Actual:
Some Jaguar CD CUE/BIN images fail to boot on Android, while the same images boot on Windows.

Confirmed examples:

• Alice's Mom's Rescue! (Europe) (En,Fr,De,Es,It) (Unl)
• World Tour Racing (Jaguar CD)

For these titles, CDI images can boot on Android, indicating that the issue appears to be related specifically to CUE/BIN loading on Android.

This is still reproducible with Virtual Jaguar v3.4.0.

BIOS mode

Not sure

Blitter mode

Both (issue is independent of blitter)

Core version

v3.4.0 8c758ff

Frontend + platform

RetroArch 1.21.1, Android

Logs

Pre-flight

• Verified the issue is in this libretro core (not standalone Virtual Jaguar or another emulator).
• Searched existing issues for duplicates.

[JoeMatt]

Traced a plausible mechanism, but I want to narrow it before writing a fix — the issue has no logs attached, so this is code-reading, not a confirmed repro.

ParseCueSheet() resolves the sibling .bin by naive string splicing: GetDirectoryFromPath() (src/cd/cdintf.c:159-181) truncates the incoming .cue path at the last literal / or \, then snprintf("%s%s", dir, binName) (cdintf.c:738-742) appends the bare filename from the CUE's FILE "..." line. ParseCDI() never does this - it opens the single path it's given directly (cdintf.c:1423) - which would explain why CDI works and CUE/BIN doesn't, if the failure is in that splice step.

Two candidate mechanisms fit the symptoms differently:

(a) SAF content:// URI corruption - if RetroArch on Android hands the core a content://.../document/<opaque-id>.cue URI (common when the ROM isn't in directly-accessible storage), the opaque ID segment can itself contain percent-encoded %2F that isn't a real separator, but also can be one flat segment after the last real /. Splicing the bare .bin name onto the truncated directory destroys that segment's structure. This repo has hit this exact class of bug for CHD before (cdintf.c:415: "Android content URIs fail [the direct-open] path and succeed through VFS callbacks below").

(b) plain case sensitivity - Android's filesystem is case-sensitive (ext4); Windows/NTFS is not. If the CUE's FILE "..." string doesn't byte-for-byte match the shipped .bin filename's case, rfopen() on the spliced path fails on Android and silently succeeds on Windows. This also explains why CDI (no internal filename reference) is unaffected, with no URI involvement at all.

These need different fixes - (a) needs VFS-based directory enumeration to resolve the sibling safely; (b) just needs a case-insensitive fallback when the exact-case open fails. Could you help me tell them apart?

1. Where do the CUE/BIN files live on the Android device - internal storage, an SD card, or somewhere reached through Android's "Downloads"/SAF picker? (This determines whether RetroArch would even hand the core a content:// URI vs a plain filesystem path.)
2. The RetroArch frontend log around the failed load (it should show the actual path/URI the core received).
3. The exact FILE "..." line from the failing .cue, compared byte-for-byte against the real .bin filename on disk (case included).

Any one of these should be enough to pick the right fix instead of guessing.

[ShyChimchar07]

I retested this more thoroughly on the current v3.4.0 build, and I can no longer reproduce the CUE/BIN loading issue on Android.

I tested on two different Android devices and storage setups:

Moto G Stylus 5G 2024: the games are stored in internal storage, in a normally accessible location such as the Downloads folder.
Anbernic RG556: the games are stored on the SD card, alongside the other ROM folders used by the ES-DE frontend. They are also in a normally accessible location.

In both cases, the files are not stored inside Android's restricted system/app directories (such as Android/data), where file access, copying, or modification can be restricted by newer Android versions.

On both devices, the affected CUE/BIN games now load correctly, including World Tour Racing and Alice's Mom's Rescue.

I'm certain that I had problems loading some Jaguar CD .cue images on Android with earlier Virtual Jaguar builds, while alternative formats such as CDI worked. However, I can no longer reproduce that behavior with v3.4.0.

Since both internal storage and SD card CUE/BIN images are now working correctly for me, it seems possible that one of the recent Jaguar CD/CUE changes already fixed the issue before or as part of v3.4.0.

Sorry for the confusion. Since I can't reproduce the problem anymore, I think this issue can be closed unless you'd like me to perform any additional tests.