Delete stale generated files on same-path content change instead of renaming - #7158
Delete stale generated files on same-path content change instead of renaming#7158lurkfueh wants to merge 2 commits into
Conversation
…enaming When a scene's file changes at the same path, the scan handler called MigrateHash, which renames the old hash's sprite/preview/transcode files onto the new hash's path instead of regenerating them. Every generator's "does this already exist" check then found a file already sitting there and skipped, leaving stale pre-edit content wearing the new hash's name - and the cover (a DB blob, never touched by MigrateHash) stayed stale too. Add InvalidateGeneratedFiles, used only for the same-path content-change case: deletes the old hash's generated files instead of renaming them, and clears the scene's cover. MigrateHash itself is unchanged and still renames for its real use case (the hash-naming-algorithm migration task, where content is unchanged). With the stale files/cover actually gone, every generator's existing exists-check works correctly on its own for any future regeneration path - scan, manual Generate, or scheduled. Also fixes ScenePlayer never refreshing a scene's video source/duration after such an edit: its player-(re)init effect only fired on scene ID change, so an in-place file edit under the same scene ID left the player showing the pre-edit duration/sources indefinitely. Fixes stashapp#7155 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gykes
left a comment
Gykes
left a comment
There was a problem hiding this comment.
Just a quick pass through. No actual testing was done.
| // so stale content doesn't pass as valid for the new content | ||
| InvalidateGeneratedFiles(h.Paths, oldHash) | ||
|
|
||
| for _, s := range existing { |
There was a problem hiding this comment.
What about secondary files? I think this would clear for every scene even if it's the secondary file that gets modified, is that expected? I think this should be guarded to the primary file only, no?
There was a problem hiding this comment.
Could I get more context on what secondary files are or a pointer to what file to start at?
| // where the old hash's generated files are no longer valid and should be | ||
| // deleted rather than renamed onto the new hash. | ||
| func InvalidateGeneratedFiles(p *paths.Paths, hash string) { | ||
| removeSceneFolder(filepath.Join(p.Generated.Markers, hash)) |
There was a problem hiding this comment.
Is this not essentially the same as line 67?
| scenePaths := p.Scene | ||
| removeSceneFile(scenePaths.GetVideoPreviewPath(hash)) | ||
| removeSceneFile(scenePaths.GetWebpPreviewPath(hash)) | ||
| removeSceneFile(scenePaths.GetTranscodePath(hash)) |
There was a problem hiding this comment.
This removes transcodes but your PR description said you're not touching them yet.
There was a problem hiding this comment.
my bad, but do we want to remove them? I think they should be removed since they would now differ from the source.
| // scene id changing, and still needs new sources/duration pushed | ||
| // into the player | ||
| if (!file) return; | ||
| const fingerprint = getFileFingerprint(file.fingerprints); |
There was a problem hiding this comment.
This seems to join all fingerprint types. I would think if one gets added (phash, MD5) the next scene refetch would throw the viewer back to the resume position. I would compare only types present in both or key off the file id + size + mod time
2 participants
Description
Deletes generated content when a file is modified (i.e. trimmed) but the file path remains the same. Also modifies the UI scene player to track media fingerprint instead of just scene id when deciding to update the player.
Related Issue
Fixes #7155
Testing
pkg/scene/scan_test.gocovering my changesScreenshots
Checklist
AI Usage Disclosure
used claude to make the code changes, tested and verified that the changes work
Additional Context
Note, this does not touch transcodes (I think they should be removed also but want to hear from maintainers)