mirror of
https://github.com/SabreTools/MPF.git
synced 2026-07-02 17:24:48 +00:00
[Request] Support re-parsing when no longer have .bin/.cue/.iso #872
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @JohnVeness on GitHub (Oct 18, 2025).
Originally assigned to: @mnadareski on GitHub.
Is your feature request related to a problem? Please describe.
My workflow, when doing verifications for redump, is to dump the disc with redumper and then immediately delete the large .iso or .bin files to save disc space. I later run MPF.Check, pointing it at the .log file (the usage says to do
MPF.Check <system> [options] </path/to/output.cue/iso> ...but the .log file works too).Sometimes I have to do multiple passes of MPF.Check to refine things (e.g. add ringcodes using a seed file and so on). The new feature introduced in #896 is great for this, as it will unzip previous logs, if they were zipped previously.
However, because I no longer have a .bin/.iso file, and the .log is zipped up, I have nothing to point MPF.Check to. (It's possible it would work if I kept the small .cue file, but given than I'm mostly dumping DVDs and BDs, I don't have those).
Describe the solution you'd like
It would be great if MPF.Check would take a folder name as a parameter (assuming the folder only has one dumped disc in it), or take the .zip file as a parameter. At the moment, neither seem to work for me.
Describe alternatives you've considered
Obviously I could avoid zipping up the logs until I know that I'm done, and that is indeed what I currently do. I'm just thinking that it would be nice to take advantage of the work in #896 when I no longer have a .bin/.cue/.iso, given that, generally speaking, MPF.Check doesn't actually need those to do its thing. Thanks!
@mnadareski commented on GitHub (Oct 19, 2025):
Out of all of those, the cuesheet is the hardest to avoid needing for CDs. That being said, whatever file you point at will be used as the "base path" for anything that's being checked. Normally it's the BIN/CUE/ISO, but if the logs were named identically to the image and you point at that, it will also work. It's hard to get that across in the help text.
@JohnVeness commented on GitHub (Oct 19, 2025):
Yep, but I'm talking about the case where the logs are zipped up, and there's no .bin, .cue or .iso. As far as I can tell, MPF.Check can't check things in that case - i.e. it doesn't know that it can unzip the old logs and re-analyse those.
@mnadareski commented on GitHub (Oct 19, 2025):
You have to kind of "fake it" at that level. The name the CUE or ISO should be can be passed in, but that's the best you can get. I think the request will boil down to behaving differently if a valid log zip path is provided in lieu of the normal set of non-zipped files.
@mnadareski commented on GitHub (Oct 19, 2025):
The majority of this is handled with
c6258b5520, where providing a standard log zip path (likeC:\ISO\track_logs.zip) it will internally replace the log suffix so that most of the operations will still work.What this does not handle is the case of missing cuesheets for CD outputs. That's still going to be required until anything remotely reasonable can be figured out. Including it in the zip by default is an option, but I would have to change a lot of code to handle something that gets zipped but does not also get deleted.
@mnadareski commented on GitHub (Oct 19, 2025):
To fix the possibility of a missing cuesheet in the main folder, I've added the ability to zip the cuesheets while still keeping them in the output directory. This means that situations where only the log zip is available should fully work with no extra effort. This was introduced in
584b8c0109which will be merged into the main branch along with everything else there later.@JohnVeness commented on GitHub (Oct 19, 2025):
Thanks for all your work on this :)
@mnadareski commented on GitHub (Oct 19, 2025):
Fixed as of
c6258b5520and584b8c0109@JohnVeness commented on GitHub (Oct 19, 2025):
I'm trying 3.5.0-6eb976c8421b43fe80c03a30059a26b909daa51d which should have these changes. I'm not sure if I'm doing something wrong but it's still not working for me, when I only have zipped logs available for a dumped BD.
If I do
MPF.Check -u redumper gamefolder/gamename_logs.zipI get:If I try and fake things as mentioned in your comment https://github.com/SabreTools/MPF/issues/905#issuecomment-3419066168 that doesn't work either, e.g.
MPF.Check -u redumper gamefolder/gamename.logorMPF.Check -u redumper gamefolder/gamename.isowhen neither are in the folder (in the case of the .log file, it is zipped up), I get:Have I misunderstood?
@mnadareski commented on GitHub (Oct 19, 2025):
There was an issue extracting information!is the key part here. There's something that caused the submission info not to be built.@mnadareski commented on GitHub (Oct 19, 2025):
The requirement of a real file existing was an old check that I had in there due to some limitations. I removed that part in
ac6a77d9da@mnadareski commented on GitHub (Oct 19, 2025):
Ah ha, I found it. There's another place where the original full input path is used. I just need to handle that in the same way with the zip removal.
@mnadareski commented on GitHub (Oct 19, 2025):
The secondary place has been fixed in
ff0c742dee@JohnVeness commented on GitHub (Oct 19, 2025):
Thanks, we're getting somewhere! Now it doesn't complain if I pass the name of a file which doesn't actually exist :). And I can pass the name of a (non-existant) .iso or .log, or the path to the _logs.zip file and it does... something.
However, it doesn't seem to be fully unzipping the logs zip - it only unzips the .log file, not the .state or .physical. So
MPF.Check xboxone -u redumper gamefolder/gamename_logs.zipgives:@mnadareski commented on GitHub (Oct 19, 2025):
It only unzips if all files are found. I guess I have the state file as a required piece, even though it's not used for anything. That's just an oversight that can be fixed.
As for the first thing you're seeing, that's actually intended behavior. The log being extracted makes finding the internal media type easier.
@mnadareski commented on GitHub (Oct 19, 2025):
Given that the state file is not strictly needed for output parsing, I've removed the optional-required flag on it as of
071e3a0024@JohnVeness commented on GitHub (Oct 19, 2025):
Woohoo! Seems to be working now, for Xbox One dumps at least :)
Thanks for your quick work on this.
@Deterous commented on GitHub (Oct 19, 2025):
If you're passing a zip, can you check that the new zip still has the same set of files as the old one? As a sanity check.
@JohnVeness commented on GitHub (Oct 19, 2025):
I'm not sure if that's a comment for me or for @mnadareski, but certainly for my test dump, for which I now have four zips, each zip has the same .log, .physical, .state.zst files with same checksum. The !submissionInfo.txt varies of course, due to the version number of MPF for example.