Reading from/Writing to, Memory Full, Black Screen Errors when running WADs with USBLoaderGX on a new emuNand due to shared content missing

[qWii]

I would just like to share a problem I recently encountered with building emunands and installing wads, and a bypass to fix it. If I'm not wromg, the solution will require some coding in USBLGX, I'm not sure it is worth it. I'm just a Newbie, so the root cause may be well known, but I haven't been able to find any reference to it (or I may not have googled enough).

Warning: this is a long post just to describe a very infrequent (but annoying) problem

Spoiler Alert: use ShowMiiWads whenever you can

* Scenario: You build a new emunand from ModMii as minimal as possible, probably from a different region than your Wii, N for all options, no default channels, no additional wads (by the way, the error can occur even with an exported NAND if you've never installed a VC or a WiiWare in your Wii... highly improbable scenario in most cases, but not an impossible one). After building the emunand, you install different wads in it using USBLGX.

* Errors: Titles that worked on your previous emunand now throw different errors during loading or while executing from your new emunand:

"the file is corrupted"
"an error occured during the process of reading from or writting to the wii system memory"
"there is not enough available space in the wii system memory"
Black screen forever before health message on WiiWare.
Wad works fine but freezes when you press the Home button to exit (before the Start menu appears)

* Cause: Neither USBLGX (nor WiiFlow) install the WAD shared content on the emunand ! If the shared content is not already present in the /shared1 emunand folder (as can happen in the scenarios described above), the wads will not work, no matter what you try.

* Bypass: rebuild the emunand (it's easier to start over) and install the WADs directly from ModMii or using ShowMiiWads. They (actually ShowMiiWads) will install the shared content and the wads will work fine in neek mode (for ModMii emunands) or full/ciSO and neek (for exported ones).

* Fix: Strictly speaking it's not a bug... the function to deploy shared content is (nearly) empty in the USBLGX v3.0-r1281 source code, it is just a comment that says that this part should de coded. >> SEE EDIT1 >> Unfortunately, some related code is implemented (the part that adds the content's hash to the content.map file), so other tools will mistakenly think the shared content is there and won't fix anything. It is worth to complete the code in USBLoaderGX? The problem is very rare, most people have lived happily with it for a looong time, only happens in very concrete scenarios, and we have a short-term bypass (ShowMiiWads) and a long-term one ( once you have installed a few different type of wads, you can switch to USBLoaderGX to install other wads without encountering this problem ever). I believe that it's worth adding the code in USBLGX to deploy shared content, but it's just my opinion and in the end, it's not my time. Surely there are higher impact bugs waiting to be solved.

* Summary: If you consistently found some of the previous errors, try using ShowMiiWads in a new emunand to install the wads again (or better, use ShowMiiWads from the very beginning). If the problem is not solved, continue by trying the rest of the usual tricks. Good luck!

EDIT1:
After taking a closer look, the code to install shared content is there, but there is a bug that always prevents it from being installed. The solution is really easy and I already have a working binary. I will contact blackb0x and/or make a pull request to get it fixed in the main version.

 

[Exidous]

Interesting, thanks for the report.

@XFlak , can you confirm that the emunand builder in ModMii is also safe for this use case - that it installs the shared content for a given wad? I suspect it does, since it's the source of a substantial share of the emunands in the wild and I haven't been hearing of this problem.

 

[XFlak]

Modmii uses showmiiwads to extract wads for emunands

I've never personally used a wad manager or usbloader to install content to emunands, I always felt it wasn't very stable.

 

[qWii]

Thanks people!

Well, last week I would have said that I'd prefer USBLGX just because it is very convenient to install WAD without ejecting the SD card and without using a laptop + program, but after encountering this problem my opinion has completely changed, and I will use ShowMiiWads from now on.

Regarding this problem, the frontier between success and failure with an emunand seems to be only two shared files. But a working ModMii Emunand has 81 shared files, the emunand exported from my Wii has 108. Potentially more problems could arise if not using ShowMiiWads, but again, very few complains from the community, so probably I'm being paranoic.

Today I have take a look again at Wiiflow. And I'm 100% on the side of XFlak's. Taking a quick look at the source code, it appears that no difference is made between shared and dedicated content. To test this point, I installed "the" wad with Wiiflow, and all the content is installed in the /title/..../titleid/ folder, nothing in shared1 folder. Shocking. And consistently, the wad crashes with "problem reading from...". May be there is some flag to change wad load behaviour i Wiiflow, I don't know, but to solve it... just install another title using our heroic ShowMiiWads (at least Wiiflow doesn't break emunand's shared1 folder structure) and the wad runs without problems.

I know, it seems like a pointless exercise because there's a good chance that people will start this journey with a Wii with some VC/WiiWare installed, so they'll never run into this problem, but if that's not the case, and you move just between USBLGX and WF, I don't see any way to solve the problem.

I'll let the developers know (maybe this issue is already in their backog). But it's clear that the safe path is always use ShowMiiWads to manage the Emunand.

Regards!