Rom file and hashing refactor #1369
Conversation
gantoine
force-pushed
the
rom-hashing-background-task
branch
from
fb79d55 to
bb7913e
Compare
| "xbox-360", | ||
| "xboxone", | ||
| ) | ||
| ) |
There was a problem hiding this comment.
moved the location of this list and populated it with more platforms
gantoine
requested review from
zurdi15 and
adamantike
and removed request for
zurdi15
| category | ||
| for category in RomFileCategory | ||
| if category_matches(category.value, path_parts_lower) |
There was a problem hiding this comment.
For a future improvement, I think the way a category matches should be configurable by the user. They could provide a mapping in case they prefer to use a different term for each category.
First example that comes to mind is a different language: patch: "parche"
There was a problem hiding this comment.
Sure something to look into, but if we're already being strict about the filesystem structure there's no reason we can't mandate specific names for DLC/folders/etc.
| def full_path(self) -> str: | ||
| return f"{self.file_path}/{self.file_name}" |
There was a problem hiding this comment.
nit: This could return a Path, and use a notation like Path(self.file_path) / self.file_name
|
Thanks for the review! I think we should release a patch version in a couple days with the fixed we have in the pipeline, then I'll merge this in. That way this won't block anything if something major is found. |
Alright this bad boy is ready for review! The gist of changes can be found in the migration file, but basically this PR:
RomFileand migratesrom.filesover to itfile_*columns onRomtofs_*, to clarify that these are filesystem propertiesI've also cleaned up a lot of pylint errors, added extra checks all over the place for bad data/states, and added
HASH_SCANas a scan type in the UI.