I’ve been running the fixed on Smash and I accidentally let the battery die during the process. It was around 30-40% done and had probably 4000 unfixable chunks but now every time I rerun the fixed it freezes during the verify extfs step after a few hundred thousand refresh counts. Any ideas why?
What you're describing is most likely the fixer's retry loop, not an actual freeze, but we need your help to confirm which case it is.
When a chunk can't be read correctly, the fixer retries it in very small blocks and sends a cartridge refresh command on each read. On a damaged ExeFS region this can add up to hundreds of thousands of refreshes, so it looks stuck even though it's still working.
To narrow it down, could you please run these tests and report back:
1. Let it run longer — leave it at the "Verifying EXEFS" screen for at least 15–20 minutes without touching anything. Does the refresh counter keep going up the whole time, or does it stop completely?
2. Try the manual skip — when the refresh counter gets very high, hold Y (the screen should show "500 retries exceeded. Hold Y to skip."). Does it skip the chunk and continue?
3. Try autoskip — start the fixer while holding X (turns on autoskip), so it skips bad chunks automatically. Does it get past the EXEFS step now?
4. Check the counters — while it's running, what do "Unfixable chunks" and "Fixed chunks" show? And if it finishes, what does the final summary say?
Also useful to know:
- Which build/version are you on (the version is shown on the splash screen, e.g. "Cartridge Fixer Fork v1.xx")?
- Does it always stop at the same point, or does the refresh counter keep climbing?
- Is this the same cartridge/dump you used before the battery died, and did the earlier run ever get past EXEFS?
If holding Y or using autoskip gets it moving, that confirms the retry logic is the culprit and we'll adjust it so it can't sit there for so long. If it truly stops with no counter movement at all, that's a different problem and we'll dig further.