jtcps2 required files not loading when disable alternate files is unchecked

[DJBabyBuster]

Running on latest Pocket Sync for Mac, V3.10.1

When "Skip Alternate Assets" is unchecked in settings the jtcps2 core does not load "required files." This has been the case on the last three versions of Pocket Sync since I noticed. Next to required files you only get "Please wait, checking files..." indefinitely (see screenshot). I've left this screen open for hours and it never loads the files. If I check Skip Alternate Assets in settings, jtcps2 will load the current 40 files (see screenshot), then when unchecking Skip Alternate Assets on this screen I get a spinning loading that never goes away (see screenshot) until clicking another section within Pocket Sync. I also tried turning on Enable Fast Doanloads in the latest update, and that did not resolve the issue.

[neil-morrison44]

Do you have the alternative files installed? Are you ejecting the SD card or using the Pocket’s USB?

If the files are there and you’re using USB then hours probably isn’t outside of the realm of how long it’d take (it’s creating a hash of each of the ~40MB files to compare it against what it can download).
If not then something’s probably up.

I’ve been thinking about potentially switching to use the file’s modified time which would speed this up considerably but there’s a couple of pieces that need to be in place before that’s viable

[DJBabyBuster]

Accessing my sd card directly, using a sandisc extreme 512gb, I never connect the pocket via usb b/c I am aware how slow access is.

I have alternate files for every other core installed, including Jotego betas, but it's just jtcps2 that won't load alternate files.

[Arithmeticae]

I also encounter [a similar] this issue on MacOS 13.6.1. I am reading the SD card directly, not through a usb connection to the Pocket.

The CPS2 core has always been a bit of an outlier for me. Often it would never finish "checking files", but as the original reporter noted, it appears that now the blank screen always appears about a second after navigating to that core in Pocket Sync.

I did use the feature in pocket sync to cleanup the folders and while that helped a lot with other cores, it made no difference to the behavior of this one.

EDIT: Sorry, I have to update my comment a bit, I'm seeing similar behavior but not identical. After encountering issues with the CPS2 core, I used a windows machine to grab all the required files including the alternates. When I open the CPS2 core in Pocket Sync on the mac, it shows the core page for a second before giving me a completely blank page requiring the application to be close and restarted.

[neil-morrison44]

How many JSON files do you have in the core’s assets folder? If you installed the first beta of CPS2 then a later beta you could have a lot of duplicate instance json files.

I’ll have a go at replicating this next week (it works fine for me locally currently…) and see if I can get a fix in, or just speed it up as much as I can to try and get out of it by processing more files at once.

---

@Arithmeticae
That issue being Mac only is strange… would think that anything causing the core page to fail like that would be something wrong with the data for the core itself

[mardem1976]

Can echo the issues that Arithmeticae is seeing. Using Pocket Sync 4.0 on Mac with latest OS, SD card mounted directly on the Mac and fresh install with the final release of the core.

I actually got it to open the required window once with skip alternated unchecked, and clicked to download all. It was going painfully slow, so I decided to just leave it overnight. In the morning, it seemed to have locked up at 47%.

At that point I manually downloaded the remaining alt roms from archive.org and all is working fine on the Pocket.

[neil-morrison44]

This might be improved by what I’m working on for 4.1 where the app is much smarter about filesystem stuff. Which’ll probably come early on in the new year since it’s a big change and I want to be fairly sure there’s not a whole load of new bugs.

For me it takes a not-unreasonable time (less than 5 minutes) to process all the alternative files & then works fine (downloading them in about an hour or so), but it is computing the hashes of multi-megabyte files for each one so that’s fairly intense.

I could change it to look at the modified time of the file instead, but that would be more error prone and it would mean we lose the app checking if the file has been downloaded ok.