mirror of
https://github.com/SabreTools/MPF.git
synced 2026-02-03 21:29:27 +00:00
[Request] Ignore useless volume labels #742
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 @Deterous on GitHub (Sep 3, 2024).
Originally assigned to: @Deterous on GitHub.
Currently MPF outputs ISO volume labels that are useless, e.g.
[T:VOL] Young, YOUNG (ISO)or[T:VOL] LIVINGFACTORY (ISO), LivingFactory (Joliet)TODO: Add logic to delete useless volume labels. Compare them after removing spaces/underscores and normalising case. Drop empty volume labels after this. And ensure that if only one volume label is left, don't add the brackets
e.g. the output after this should be
[T:VOL] Youngand ``[T:VOL] LivingFactory`@PurpleNekoNova commented on GitHub (Sep 5, 2024):
Strongly request a toggle in options to include them anyway. I'd like to still have them and having it off by default will let the mods be happy.
@mnadareski commented on GitHub (Oct 10, 2024):
Is there a preferred order to the "accepted" labels? Like does Windows always take precedence over Joliet? Or if they match (ignoring case), is it always the one that includes at least one lower-case character?
@Deterous commented on GitHub (Oct 10, 2024):
Windows > UDF > ISO > Joliet
Windows probably is UDF anyway.
Honestly I've only seen bad results from the joliet label. Maybe it's coded wrong for DIC log parsing..? (my fault if so)
@mnadareski commented on GitHub (Oct 10, 2024):
The current formatting code doesn't take into account where the labels are coming from when formatting. It just assumes that they're organized properly. That is, there is no actual distinction between UDF, ISO, and Joliet when the formatting happens. If we go with the hierarchy, that will require special checking cases. Also worth noting that it actually doesn't do any sort of comparisons between labels at the moment.
@mnadareski commented on GitHub (Oct 10, 2024):
As discussed in Discord, part of the issue here is needing to rebuild the current mapping dictionary based on the "correct" labels. For a human user, this is nearly trivial to point out, regardless of what the source of the label is. For a computer, it's a bit harder, since either the key in the dictionary needs to be normalized OR a separate mapping needs to be made from the key to the "real label". Neither of these are trivial to implement and neither scales particularly well.
@Deterous commented on GitHub (Oct 11, 2024):
Currently,
labelsexists as a mapping of actual volume labels to zero or more filesystem names ("ISO", "Joliet", "UDF", "UNKNOWN")It should be possible to compare the volume labels and pick the one with the better filesystem. There is no need to determine which is better through heuristics (which has case sensitivity, etc).
For example:
labels= a mapping of "EXAMPLE_DISC" = (ISO, Joliet) and "Example Disc" = (UDF)string.Equals(a, b, StringComparison.OrdinalIgnoreCase)Note: this logic should occur here:
83a189a5d3/MPF.Frontend/Tools/SubmissionGenerator.cs (L414)i.e. after checking that at least one label exists, but before the check for only one label.
@mnadareski commented on GitHub (Oct 11, 2024):
You're proposing a static readonly list that defines the hierarchy. It also seems like you're suggesting the "highest ranked" out of each set of label sources would be considered.
@Deterous commented on GitHub (Oct 23, 2024):
Another request as part of this: don't put any volume labels in submissionInfo for Xbox/Xbox360.
@mnadareski commented on GitHub (Dec 15, 2024):
Initial filtering has been added. Additional, smarter filtering taking the source into account is needed.
@Deterous commented on GitHub (Dec 15, 2024):
#780 / #781 has implemented what I wanted, so I'm closing this issue. A TODO remains in the code if someone wants to do this "properly", but the cases where the current implementation falls short are currently rare and will not occur with Redumper logs at all.
In cases where the ISO9660 volume label is superficially different, it will no longer appear in the submission info, but the Redumper .log file still has the ISO9660 volume label if this is ever desired.