ZTool: *critical* workaround for older repacks!

[elit]

So here is what happened today. I was to unpack some PS3 games from my archive backup that I did a time ago. Difference between then and now is that then, I had i5-4690k and now ryzen 5800x. Exact same Win7 with just switched drivers, not reinstalled and working perfect so no issue there.

What happened is that ZTool would remain hanged on processes without using any CPU, therefore unpack would fail(infinite run). I was getting desperate but then I localized this issue to ZTool. Perhaps due to SMT but did not try turning it off in bios. Also, both HW and system is guaranteed stable and have nothing to do with it.

So then thinking about it, I got an idea to disable threading for ztool during unpack, so I put

:t1

option in arc.ini unpackcmd line. Well guess what, that did it! After this Ztool became perfectly reliable again. It also look like it is probably only needed during decompression, not compression but further testing would be needed.

Bottom line is that if you have older archives that were using ztool, you may need this on new system to be able to unpack! And at least you can still unpack, because of course, if you have those installers or older repacks... good luck. I don't use installers, I archive into 'arc' file using FA GUI and that saved me.

Btw, XTool do not have this issue.

UPDATE:
Option

:cm0

as suggested by Gehrman seem to be even better way, giving back speed of multi threading without consequences. Thanks!
EDIT: Disabling SMT in bios did not help, above option remain the best solution. For repacks, you should be able to unpack setup.exe with UniExtract2 from github, but to go further on how to put things together to be able to install repack, I have not explored yet.


PS: You can still get an error during unpacking sometimes, just try again as it can be flaky for some archives, however second time you may get a strange error of access/permission deny(despite being admin account), so either unpack another archive(to "reset") and then try problematic one again, or restart whole PC first.

[Gehrman]

Also test with cm0.

ZTool.exe" d:pzlib:t100p:cm0 - - <stdin> <stdout>

[78372]

Originally Posted by elit

I had i5-4690k and now ryzen 5800x. Exact same Win7 with just switched drivers, not reinstalled and working perfect so no issue there.

Ryzen 5800x with Win7? Very interesting

[elit]

@78372 On b450m mb its perfectly possible, with all usb3/3.1 ports and everything working fine.

[elit]

I was also curious if @fitgirl repacks are affected so I made some tests. She was using ztool in period of around 1 year between August 2017 to June 2018, with one more appearing in August 2018. This is from relying on her repacks description info.

I also decided to test 2 repacks from her that use pzlib and one that use among the very first xtool version she started using, to isolate case and make sure only ztool is affected.

Specifically I tested:

pzlib: rime, mgs5:ground zero
xtool: planet coaster
ztool: hob, dark souls 3, little nightmares

And here are results:

rime, mgs5:gz => both installed successfully
planet coaster => installed successfully
hob, dark souls 3, little nightmares => all 3 installed successfully

I even installed DS3 2x. Apparently, fitgirl repacks are fine. I don't know why they work as the issue described in this thread is real and replicable. I doubt she is limiting threads to 't1' or using 'cm0' option. Maybe she have different version, or is using ztool in different context(in conjunction with different tool chaining, io vs stdin etc..). But it is good news regardless. Make no mistake, issue is real and replicable(by me), but fitgirl's repacks are not affected. Go figure...

EDIT:
- I found that with arc.exe its less affected than FA GUI version. It still happen but not always. arc.exe also close ztool process correctly upon ctrl+c, GUI keep it hanging.
- If unpacking/testing passes, then subsequent ones will be always successful and to make it bug again it need to fail on another archive(buffer memory).
- I also found that with non-GUI FA, if I keep retrying to unpack or test archive then after several failed attempts it will work.
-cm0 always work reliably and on the first go, no issues

This seem IO/threading issue to me, not sure if it happen only when using FA and ztool together, or ztool in general. Hell it could even be FA's problem. I am clueless. Never had any issue on Haswell so I could blame AMD, yet cm0 option work reliably + I know my system and memory are stable.

[FitGirl]

I always used

unpackcmd   = ztool d:pzlib:t100p:cm0 - - <stdin> <stdout>

so that's why they still unpack till the current day.

[elit]

Originally Posted by FitGirl

I always used

unpackcmd = ztool dzlib:t100p:cm0 - - <stdin> <stdout>

so that's why they still unpack till the current day.

Thanks for letting me know, but how come everybody knew about this parameter but not me? I never saw it being discussed and that there was an issue without it in the first place. I mean ztool did actually work fine on my old i5-4690k without cm0. ?

[FitGirl]

I remember vaguely that I discussed something with Razor about instability of unpacking and he told me to use that option, I don't remember the details, but it made installation stable back then.

Guess it also fixed MT issues as well.