[Issue]: CudeODE compatability issues in latest swiss versions but not in (potentially) custom build shipped with device

[Goon3r]

Describe the bug

Hello,

I recently installed a CudeODE v1.2 and prepared swiss v0.6r1788 on a FAT32 MBR 128 GB SD card.

I had no issue booting Mario Kart: Double Dash!! (USA)

When booting Mission: Impossible: Operation Surma (USA) however i got "Failed to read FST". On lower versions of Swiss this error would present itself as "Failed to read file.. too fragmented?" (or similar)

I assumed it was the SD card, so began to format the SD card that arrived with the CudeODE device (a 4GB no name card).

This card was preconfigured with a version of Swiss v0.6r1503 which was able to successfully boot Mission: Impossible: Operation Surma (USA). Interestingly, I cannot find reference to v0.6r1503 or the commit SHA 5ff17b90 (which is shown in the swiss UI) in this repository.

I've attached the swiss boot.iso for the compatible v0.6r1503 but I'm wondering if there were potential third-party changes to swiss improving CudeODE compatability that could be rolled into the mainline releases here?

To be clear, both SD cards used during tests failed to launch Mission: Impossible: Operation Surma (USA) on 0.6r1788, and both successfully launched that game on 0.6r1503. Similar results are seen for different games, another one being Mario Kart: Double Dash!! (Bonus Disc) (USA)

CudeODE compatible build:
swiss_0.6r1503.boot.iso.zip

Steps to reproduce

• Boot Mission: Impossible: Operation Surma (USA) via CudeODE on swiss 0.6r1503 - observe success
• Boot Mission: Impossible: Operation Surma (USA) via CubeODE on swiss 0.6r1788 - observe failure

Expected behavior

Booting Mission: Impossible: Operation Surma (USA) via CubeODE on swiss 0.6r1788 to be successful.

Relevant log output

Add screenshots

No response

[Extrems]

Unfortunately we cannot roll any changes from a binary build, and any such changes without offering corresponding source code is a GPL violation.

[Goon3r]

Understandable, given theres no commit in this repository with ref 5ff17b90, is this a code change without correspondence, thus like you say, a license violation?

On top of that are there any common causes/remedies for the “failed to read fst” error that I could test?

[Extrems]

I suspect their device can only support one FAT fragment, so your file mustn't be fragmented in any way.

[Goon3r]

Is that something you think was addressed in software for this version? Like I say, the same device, sd card and game(s) have different results based only on the version of the swiss boot.iso used.

[Extrems]

Is it really addressed if the game failed to boot either way?

[Goon3r]

The game doesn’t fail to boot either way is my point.

Using the same sd card, same device (cubeode), same game but a different swiss version gives different results.

• v0.6r1503 - game boots without issue
• v0.6r1788 - game doesn’t boot with error “failed to read fst”

The only difference during my tests was the contents of the sd card - the version of boot.iso used, there was no reformat etc. between tests.

I’ve replicated those results on two different sd cards which may thinks the cause is software related.

[Extrems]

Well, the CUBEODE is not a supported device, and unless you can produce the source code, we can't do anything.

[Goon3r]

I'll message the seller i bought the device from and see if they can provide any information on this particular build of Swiss.

Leave it with me, I'll update if/when I hear back from them

[Goon3r]

Interesting update after more testing.

For context, I am a (intel) Mac user running Ventura 13.7.2.

I was able to get the problematic games to boot on 0.6r1788 successfully if the SD card was formatted with Rufus on Windows (via Mac paralles). However, when interacting with that SD card on MacOS after the fact (when adding another game for example) the SD card and games whilst listed in Swiss UI are not launchable and Swiss complains about them being corrupt.

Method:

• Format device on Windows with rufus
  • Notable difference in settings being the ability to disable "Create extended label and icon files"
• Add Swiss 0.6rc1788
• Add problematic games (via windows explorer)
• Boot problematic games on gamecube without seeing any errors
• Connect SD back into Mac
• Add another non-problematic game (via Mac finder)
• Boot games observing errors
  • "Failed to read fst" on the game added via Mac finder
  • corruption error on the games added via Windows explorer

I ran through the above steps twice and got the same results.

Is this perhaps a fragility in Swiss' (or CubeODE?) handling of MacOS actioned SD cards?

[Extrems]

What format exactly? Also, are you sure your SD card doesn't have a fake capacity?

[Goon3r]

4GB SD Card FAT32 Non bootable MBR.

I used this format on MacOS disk utility and Windows rufus. Noting that MacOS disk utility does not have that extra option to disable ‘create extended label and icon files’ available in rufus. i have no idea how MacOS handles this option by default in lieu of that setting though.

EDIT: Every chance the 4GB SD card has a fake capacity, it shipped with the CubeODE ordered from ali express. That could explain why the first files added become corrupt. I do have the 128GB SD card i was also testing on, I know that has more than the space consumed by the 3 games used in the test steps so I can do some more tests on that shortly.