Should use the release or build it?

[mliradelc]

Hi,

Foremost, thanks for the work you are doing, it's an amazing project.

I have seen that there are a lot of commits since the last release (2019), should it better to build it or is it ok to use the actual release?

[vgmoose]

Thanks! There are unreleased commits, however most of the ones made prior to last week were 3ds/wii related rather than switch/wiiu related. For the more recent changes, we're currently working on getting them out in a 2.3 release as soon as possible.

I'm generally pretty careful surrounding hb-appstore client updates, because if there's an issue that prevents updating, that could break some on-console continuity for the user and require them to fix the problem using an external device.

There are builds for the latest commit available under the actions tab, for each platform: https://github.com/fortheusers/hb-appstore/actions/runs/3043040002

Currently the issues holding up release are:

• on Wii U extracting after download is very slow
• on Switch the app doesn't properly exit

Regarding the current release (2.2), it is 100% ok to still use on Switch. On Wii U, with the new Aroma beta, 2.2 will crash when exiting. This is going to be addressed in 2.3 with a wuhb release, but in the mean time using the GH Actions builds, or self-building, is a good workaround.

[mliradelc]

Thanks for your nice reply

I have a Wii U. I will try the GitHub actions build and try it. Thanks for the hint.

Maybe I can find a way to fix the slow extraction on this console.

[MonfGeiger]

relating to this, i tried my hand at building it from source using the compiling instructions for pacman/devkitpro, grabbed the source with the recursive flag, cd'd to it, ran make switch, and i got fatal error: SDL2/SDL_mixer.h: No such file or directory 13 | #include <SDL2/SDL_mixer.h>. i imagine im missing something that i need to install with pacman, mind recommending me what im lacking? also i know there's instructions for docker, but unless absolutely necessary, i'd rather have just the one building system installed

[mliradelc]

I recommend you to use the docker image, you can avoid any environment issues and it's so much easier.

---

About the issue with unzip, oh boy! It is very very slow! (Like 1 hour for a little tiny package).

I tried to figured out what happens, but um very unfamiliar with Wii U's architecture.

[vgmoose]

@MonfGeiger I'll update the readme, this is the command that Docker uses to install packages and it should allow your environment to to be set up the same way:

dkp-pacman --noconfirm -S devkitA64 libnx switch-tools switch-curl switch-bzip2 switch-freetype switch-libjpeg-turbo switch-libwebp switch-sdl2 switch-sdl2_gfx switch-sdl2_image switch-sdl2_ttf switch-zlib switch-libpng switch-mesa switch-sdl2_mixer

I think sdl2_mixer is likely the part that's missing. (The switch build now supports music). I do agree however that just using docker will avoid a lot of headaches in the long run (this goes for all homebrew apps, not just this one, but is also only my opinion).

@mliradelc Are you on the latest nightly? It may have addressed most of the issues with unzipping on Wii U. These are the two main changes (in libget):

• fortheusers/libget@3b7fee4
• fortheusers/libget@4148c3d

libget (The underlying package manager hb-appstore uses) keeps a list of all files and how to extract them, for each package (this is to allow for options like not overriding user configs or certain files that should remain behind after uninstall, etc).

The old unzipping code would then loop through this list, and then call minizip to extract the file at the path. That minizip function though is also looping through all files in the zip, creating an O(n^2) runtime. The new code builds a hash map of the files first, and then uses that as a reference to find the zipped files when going through the manifest (O(n)).

I didn't realize that the minizip method was also looping through files until closer inspection. Adding to the troubles, and the reason we mostly noticed the extreme slowdown on Wii U, was that the Wii U expects certain alignments of memory, so every single n^2 file access had additional overhead and slowness, as the library was not aligned for these sizes.

TLDR, a little hardware specific as expected, but also just a general software slowness problem on top of that.

[vgmoose]

Regarding what remains for a release:

The Switch exiting issue is still present: (#93).

I really don't understand why it crashes on exit, and I'm almost at the point where I just want to remove that button completely (Let the user push home to exit). I'm cleaning up every resource, and other platforms don't crash at this point. It may be related to some of the new SSL code or maybe a libcurl specific bug.

There's another Wii U issue too that was discovered during testing, that affects the WUHB build self-updating: #92.

This issue is pretty essential– I thought about doing an RPX-only release, but WUHB is the New World and it would be awesome to fully support it.

To any future readers, depending on when the eventual release comes out, I do recommend pulling a recent build from the Actions tab.

These are usually stable, but aren't suitable for rolling out to the average user as, if an update breaks, it may ruin the user's ability to receive future updates. The worst case scenario for hb-appstore is sending out a DOA update that ultimately prevents access to other apps, requiring a second device to fix.

If you are running one of these builds, it will erroneously suggest you "update" it to the stable version, which in most cases (with the slow release cycle) would be a "downgrade". So that's the long-winded explanation about the discrepancy between the last release and nightly builds.

[vgmoose]

Fixed in 2.3.1