download assets/core info files/controller profiles on first run

[cscd98]

Guidelines

1. Rebase before opening a pull request
2. If you are sending several unrelated fixes or features, use a branch and a separate pull request for each
3. If possible try squashing everything in a single commit. This is particularly beneficial in the case of feature merges since it allows easy bisecting when a problem arises
4. RetroArch codebase follows C89 coding rules for portability across many old platforms check using C89_BUILD=1

Description

A relatively common issue with users who are unfamiliar with RetroArch is updating core info files/assets/controller profiles.

This enables these files to be automatically downloaded the very first time they open up RetroArch on webOS as they are not bundled. This is on purpose because application installs are given separate permissions and if they were indeed bundled it would stop a user from being able to update them via RetroArch menu.

It checks to see if 200MB (72.5MB for zip, 87.7MB unzipped) of space is available before download assets due to some older devices may lack the space to download plus decompress. It also checks for 250MB (51.7MB for zip, 180.1MB unzipped!) available space before automatically downloading the database. I have left some margin for error by rounding up to nearest 50MB but these could always be reduced.

Core profiles are absolutely necessary otherwise no cores are listed for download so they are always downloaded.

Includes work already done by @warmenhoven

Related Issues

Related Pull Requests

Reviewers

[hizzlekizzle]

I don't think we have any way of querying F-Droid as a platform, but they would undoubtedly appreciate this. If we applied it to the entire Android platform, our apks would be a lot smaller...

[i30817]

if you're on a roll, another common issue is on the first download of a core with requirement files like dolphin, people just don't get those files, and pay for it with a myriad of bogus bugs.

[matheuswillder]

This could also improve the user experience if used in Flatpak builds. There, all the assets are bundled, but this also means they cannot be updated without first manually changing the assets directories to a user-writable directory, and then going to the Online Updater and updating accordingly, which can be really confusing for beginner users. Issues (partially) related: #16501 and flathub/org.libretro.RetroArch#321.

[cscd98]

@hizzlekizzle @matheuswillder I could always remove the HAVE_UPDATE_ASSETS_FIRST_RUN define and make it the default. Let me know what you think

@i30817 I actually have something thats WIP for that.

[matheuswillder]

@hizzlekizzle @matheuswillder I could always remove the HAVE_UPDATE_ASSETS_FIRST_RUN define and make it the default. Let me know what you think

I'm not part of the team, so my comments are purely from a user's point of view. But I remember there was a similar PR before, and there are comments there who preferred the installation to work out of the box offline.

The thing is, bundle all the assets works well for some platforms/builds, but not for others. It works well for Windows (.exe installer, .7z archive), Linux (AppImage), Android (regular APK), but it doesn't work for Linux Flatpak (the assets can't be updated, meaning months without new assets unless the user knows what to do), it doesn't work for the F-Droid APK (they couldn't bundle all the assets due to the checks they do on the files before building, or something like that), and, of course, it doesn't work for webOS which is the main focus of this PR.

So in my opinion, once merged, this could be used on the platforms that need/would benefit from it, and the others could remain as they are. It would be a good middle ground to improve the user experience in some builds, without altering others that don't have this issue and already work well out of the box.

Just my two cents.

Edit: the Android build extracts the assets on first launch. This is set with bundle_assets_extract_enable = "true" in retroarch.cfg. I don't think it would make much difference from the user's point of view to ship without the assets and download them all on first launch, it would reduce the APK size and solve the problem in the F-Droid build. Android is not a platform you'd expect to be permanently offline, after all.

[cscd98]

I have updated the PR. It will check to see if assets were bundled and if they were, do not download them again. So it should work for both cases.

I also turned off wifi to test for offline installs and tested a new install and it worked fine (it tried to download, failed and let the user continue to use retroarch as normal).

[matheuswillder]

@cscd98 a question came to mind: which folders (or files?) are checked to determine whether to trigger the download of assets? Perhaps it makes sense to check for something missing in glui_minimal_assets.zip in https://buildbot.libretro.com/assets/frontend just to trigger the download of the remaining assets in the F-Droid build. Currently, only barebones assets are included in it for minimal functionality, folders like /assets/ozone, /assets/xmb, /shaders, etc., are all missing, but it contains (outdated/incomplete) /assets/glui, /autoconfig, /info, and /overlays folders/files.

Either that, or simply remove the glui_minimal_assets.zip file entirely, which I think @hizzlekizzle can do, to let everything be downloaded on the first startup.

Just some loose thoughts, I don't have time to see how this PR works right now.

[cscd98]

@matheuswillder assets are downloaded if folder is empty or folder does not exist. So if no assets are bundled then they are downloaded instead. So if someone was to remove the mini bundled assets in a future PR it would work for the f-droid case.

It does not download if the user has already run retroarch. This is in case users chose to delete them should they wish.