some fixes: avoid black banners / minimize one usb related dsi exceptions / get custom banners / install shared content

[w3irDv]

This PR contains some solutions to problems I've encountered using USBLGX.

Emunand related:

• No more black animation banners due to emunand path+name being too large.
• Emunand WAD manager now installs wad's shared content. Without this fix, if you install a wad with USBLGX and the shared content is not previously installed in the Emunand , weird behaviour will result during loading (black screen, corrupted memory errors, ...) or when exiting (errors opening the Operations Manual, freeze when exiting, ...) . A more detailed description can be found here ,

Other:

• Minimize the likelihood of a DSI exception if you move to any screen (game settings, configuration) before the free USB space is displayed on the main screen. This is probably more of a bypass than a definitive solution to the race condition between the asynchronous thread that calculates free HD space and the menu manager when it deletes the current screen to move to a new one.
• Initial USBLGX configuration file will use non-SSL URL to get custom banners. This (trivial) change is already advised in the Wii Hacks Guide. No change if the config file is already generated.

This fixes are already included in this PR at wiidev/usbloadergx repo.

[Jacoby6000]

Thanks for the contribution! I'll look over this and get it tested/merged over the next couple of days.

[Jacoby6000]

Since this is breaking up the Wad::CheckContentMap function in to two separate functions (which is probably a good thing), I think you will need to update all existing invocations of CheckContentMap to use UpdateContentMap, since those old calls expect CheckContentMap to do both pieces.

Not 💯 on this yet, but I'm pretty sure. Still learning my way around here.

[w3irDv]

Hi Jacoby6000!

No, in fact the original problem was that despite its name, checkContenMap checked and always updated the content.map file without installing the shared content. The updateContentMap process should only be called once, after the shared content has been succesfully installed. The other invocations of checkContentMap only need the check stuff. The flow is explained here with a little more of detail.

[Jacoby6000]

Ahhh I see. I didn't fully understand what was going on. This makes sense! I'll test it this week and get it merged

[Jacoby6000]

Do you have any examples of wads with shared content so that I can validate this?

[w3irDv]

I think any title will do.

If you want to see the bug in action, you can prepare the following lab.

Take a working emunand and delete all but one shared content:

cd ${NAND_ROOT}
mv shared1 _shared1
mkdir shared1
cp _shared1/00000000.app shared1
dd if=_shared1/content.map of=shared1/content.map bs=28 count=1

-rw-r--r-- 1  wii  wii      28 Aug  1 11:18 content.map

Install any title with the old build. Check the shared1 folder. You will find no new file. But notice that the content.map file has increased in size::

-rw-r--r-- 1  wii  wii     112 Aug  1  2024 content.map

USBGLX have added the hash of the shared contents included in the wad to the content.map file. The title won't load for sure. And from now on, this emunand is doomed. Any tool that checks content.map will assume that the shared content is already installed and will skip its installation.

Recreate the minimal content.map again:

dd if=_shared1/content.map of=shared1/content.map bs=28 count=1

and install the same content with the new build. content.map will have the same size (and content) than with the old build, but now shared1 folder will contain some 0000000x.app files. If you try, the installed title will (probably) load (if not, well ... we have deleted ~ 70 files or so, some unexpected behavior can happens...).

If you have access to a (physical) Wii , the real case scenario is to create a minimal emunand using modMii and then install any title with USBGLX. You will will succeed only with the new build (with the old build, installation apparently works, but the title won't load).
Or in a wii/vWii, only if you have never installed any title in the real NAND: if you export it to create and emunand, title installation will only succeed with the new build.

It's a subtle bug, which is why it has gone unnoticed for years. And I think mainly affects to new modders.

By the way, when testing this with the previous version, the DSI exception error hit me twice :D