Rename filename based on metadata

[scruffynerf]

There is no guarantee of nicely formed filenames right now... But as we build correct metadata, renaming the original filename to include correct metadata to at least allow reidentification if needed makes sense.

Scraping already tries to use filename information like title, studio, stars or date if available. Extra title info is often a problem in scraping. Adjusting the title to be the correct metadata standardizes this.

At a minimum, renaming files to something with the major elements (studio/title/date/stars) in a fixed order would be great.

Allowing a flexible renaming (templated?) with all of those (and other scraped/collected info like resolution, duration, etc, and perhaps tags?) would allow edge case uses as well. Consider it a stretch goal.

[cooperdk]

How would you want the choice system to be?

Would it be sufficient to allow (in settings) to enable/disable title parts within a row, with fx checkboxes, or would it be necessary to develop as you mention a form of template that could look like:

{website} - {date} - {performer} - {title} ({runtime}/{resolution}:{encoding}) - ({tags)}

This would be a larger project, and, how should we ensure that filenames don't become too long? (In my test setup, I have videos with as many as 15 tags even added with the automated system)

We discussed it a bit on Discord and I find it is a good idea to offer an alternative title/filename renaming option, we just have to make sure that people are aware that renaming "out of convention" could make it impossible for the TpDB scraper to detect the scene information.

[scruffynerf]

Checkboxes would be fine, and I'd say reordering isn't important (renamer software can manipulate a existing filename, it's getting the metadata into the title that matters most.

Yes, a fancy template system would take more effort, and risk weirdnesses. Importing in Stash allows some flexibility, but ultimately the key is some standard, so picking a fixed format for now is step 1. Making it checkboxes (yes, I want the usual plus resolution, and tags, but no runtime, for example) would keep it pretty simple.

[scruffynerf]

Just for clarity: are you saying there is an existing rename already? I haven't seen that.

[cooperdk]

There is (in videos.scrapers.scanners.tpdb) but it only does title rename, not filename rename. In YAPO, the titles are first taken from the filenames (minus extensions) and that is what the parsers/scanners work with. So at this point, the filename is not touched at all.

This also reduces stress on hard drives because SQLite does most of it's stuff in memory when the db is opened, making it unnecessary to actually read filenames from the various folders. YAPO just takes it from the database.

When I do a renamer, it also has to rename a field in the videos_scene database table named path_to_file. I already prepared YAPO for a "file renamer undo" by inserting a field named "original_path_to_file" much like the one called "original_title". With those two fields, YAPO is able to undo a rename (title or filename), but only to the previous name. I am thinking about changing it so it theoretically has unlimited undo options (by giving titles and filenames their own tables and using an ID to match previous names with scenes), but I think that's overkill.

[cooperdk]

Leaving issue open for a bit, as there MAY be issues with the renamer that I am pushing now. The mentioned "revert" option for scene titles and filenames has changed so that it only records the ORIGINAL scene name and filename. That is, the first one that was changed. If the title or filename is changed again, the TpDB scanner or the renamer will not overwrite those fields.

Manual title renaming is never stored in that field, as it is expected that the user changes the title on purpose.