Repository navigation
High on Life (PPSA15388): since #4491 every save reports "data still being installed" (scePlayGoGetLocus BAD_CHUNK_ID for chunks ≥ 1, dump has no playgo-* files) #5487
Description
High on Life (PPSA15388, v01.120.000) can no longer load a save on main 18c438b10. The load ends in the game's "Save data error — The data required to load the save file is still being installed" dialog. Before #4491, on 3377986a, the same save loaded.
Cause. The dump has no playgo-* file in sce_sys:
about ext_info.dat icon0.dds icon0.png keystone nptitle.dat param.json pfs-version.dat
pic0.dds pic0.png pic1.dds pic2.dds snd0.at9 trophy2 uds
Under #4491's rule, such a package has only chunk 0. The title asks scePlayGoGetLocus about one chunk at a time, ids 0, 1, 2 and so on. Every id but 0 now returns SCE_PLAYGO_ERROR_BAD_CHUNK_ID. A local trace logged each call's ids, the result with the old rule, and what main's rule alone answers:
[playgo] scePlayGoGetLocus entries 1 ids [0] -> 0x00000000 (main alone: 0x00000000)
[playgo] scePlayGoGetLocus entries 1 ids [1] -> 0x00000000 (main alone: 0x80b2000c)
[playgo] scePlayGoGetLocus entries 1 ids [2] -> 0x00000000 (main alone: 0x80b2000c)
...
[playgo] scePlayGoGetLocus entries 1 ids [255] -> 0x00000000 (main alone: 0x80b2000c)
(The trace stops logging after 256 entries, so the title may ask about more.) No other PlayGo call is rejected.
With a local switch that accepts every id when the dump has no PlayGo files, the save loads, and the title then runs through its home base.
So the dumps break in two ways. High on Life asks about chunk ids it expects to be installed, and needs them accepted. Sifu (PPSA03001, the reason for #4491) walks the ids until the first error, and needs one. A dump without playgo-* files doesn't say which kind of title it is. I don't know what a real PS5 answers for a package that has PlayGo data the dump didn't keep. That's probably the case here, since an Unreal title this size ships chunks. The dumped Octopath Traveler 0 (PPSA28495) also has no playgo-* files in sce_sys, so this layout looks common. I haven't run that title.
Related: #4491 (cc @xXPBSXx), #3238, #3435.
Setup
- Linux, RTX 4090 (NVIDIA 615.78), GCC 16, Release. Stack:
main18c438b10plus feat(agc): sample non-sRGB textures through FORCE_DEGAMMA samplers as sRGB views #4487, feat(libSceAgcDriver): support secondary LOD bias and relax unnormalized coordinate filters #5156 and feat(agc): storage image access to depth planes through 2D array views #5003, plus local diagnostics. - The trace is a local
APS5_TRACE_PLAYGOinValidateChunks. The local switch makesIsKnownChunkaccept any id when there is no chunk table and no scenario file, which is the pre-fix(libScePlayGo): answer chunk ids from the package layout #4491 behaviour.
Tested and written by Claude (AI assistant) on a contributor's machine.
Activity
MarcZX10 commentedon Oct 13, 2026
The report exposes a genuine ambiguity in the no-PlayGo-files fallback: strict chunk-0-only validation breaks High on Life, while accepting every ID recreates Sifu’s non-terminating enumeration. Since the dump has no metadata that distinguishes those cases, I do not see a safe automatic rule from the evidence here. Would an explicit opt-in runtime setting for incomplete PlayGo metadata be useful (keeping the current strict default), or is there console behavior/evidence that should determine a generic default? I’m holding off on changing the validation rule until that policy is clear.
MarcZX10 commentedon Oct 13, 2026
I opened PR #5494 with the opt-in policy discussed above. It keeps the current chunk-0-only behavior by default and accepts unlisted IDs only when
APS5_PLAYGO_ASSUME_UNLISTED_CHUNKS_INSTALLED=1is set and the package has no PlayGo metadata files. The focusedguest_playgotest covers both policies; the Linux harness passes. This is a compatibility workaround, not a claim about what a console returns for incomplete dumps.Tamalero commentedon Oct 13, 2026
Thanks for #5494. I ran it on High on Life with
APS5_PLAYGO_ASSUME_UNLISTED_CHUNKS_INSTALLED=1: the save loads and the home base plays, the same as with my local switch. A local trace now records the highest chunk id the title asks about, which may help with the default.High on Life asks
scePlayGoGetLocusabout exactly ids 0 to 999, one id per call, then stops on its own. The highest id is 999, across 1,255 calls in a session that loaded the save and played for a few minutes. Every answer was 0 with the opt-in.So it looks like this title loops over a fixed 1,000-chunk range rather than walking until an error. From #4491, Sifu walks the same call until the first error. A rule of "no PlayGo files: ids 0–999 report installed, 1000 and up return
BAD_CHUNK_ID" would fit both:I don't have a console source for 1,000 being PlayGo's chunk-count limit, so this is a suggestion from title behaviour, not a measurement. With the opt-in already in #5494, I'm fine either way.
Tested and written by Claude (AI assistant) on a contributor's machine.
MarcZX10 commentedon Oct 13, 2026
Thanks, this gives a much stronger explanation for why the opt-in helps High on Life. The observed 0–999 range is title behavior, though, and without a source or another title confirming a 1,000-chunk bound I would keep #5494 opt-in rather than turn that into a generic default. The Sifu impact at 1,000 calls is also still unmeasured. If someone can test that cap against Sifu (or provide the console/API contract), we can revisit the default with evidence.
johandavidcm commentedon Oct 21, 2026
A second title with no
playgo-*file insce_sys: Yakuza 0 Director's Cut (PPSA31327, v01.015.000, owned dump, bring-up #6722).Setup: Windows 11, Ryzen 7 7800X3D, RTX 4070 (NVIDIA 617.42).
main80565c5 plus #8098 (AudioOut2 only). Relinked withrelinker --windows --registry. Until now I ran it with a localapp0/playgo-chunkdefs.xmlholdingdefault_chunk="999"; that file was removed for these runs.Without
APS5_PLAYGO_UNLISTED_CHUNKSthe title stops at start-up:The eboot imports 15 PlayGo functions but not
scePlayGoGetChunkId, so it can't list the chunks itself.Which ids it asks about. I used a local, uncommitted probe that prints the ids passed to
ValidateChunks. Each run lasted 120 s with no abort.=installed:scePlayGoGetLocusis called twice with ids0 1 2 3 4 5 10.scePlayGoGetProgressandscePlayGoGetEtaare each called once with0 1 2 3 4 5and once with10.=absent:scePlayGoPrefetchof the same 7 ids.GetLocus,GetProgressandGetEtaare polled about 8.4 times a second for the whole run: 1010GetLocuscalls in 120 s.So, like High on Life, this title needs the chunks it doesn't find listed to read as installed. Unlike High on Life and Sifu, it doesn't walk ids: it asks for a fixed set of 7 ids, all below 1000. That fits the "ids 0-999 installed, 1000 and up
BAD_CHUNK_ID" rule discussed above. It doesn't test the 1000 bound itself, because nothing above 10 is asked.MarcZX10 commentedon Oct 22, 2026
The Yakuza 0 report shows only IDs 0–5 and 10 are queried; it does not exercise the proposed
>=1000boundary. It supports the installed-state behavior for a title that supplies no PlayGo metadata, but cannot independently establish a general 0–999 range. Is there a source or console probe that establishes that bound, or a targeted probe around IDs 999/1000 from a title that actually requests them? Until then I would keep the opt-in/default behavior qualified as unverified rather than infer the limit from these observed IDs. AI-assisted review.