Missing file paths

[Gfy]

Some SRRs have the file paths of the RARs missing. An example: http://www.srrdb.com/release/details/Fat.Head.2009.DVDRiP.XViD-SML

They are fine and won't be replaced because it matches the hash of dupe uploads. Duplicate uploads could have those paths. OSO hashes from these other uploads do get copied over.

This issue also exists for stored files.

A solution for this could be a second collision like queue for SRRs that have paths where the online SRR doesn't have paths.

[Gfy]

We're throwing away useful info from dupe uploads.

[Tony]

A solution for this could be a function in the rescene-library to rename rar-files.

This would make it possible to get correct path names without requiring someone to re-upload a srr-file.

[Gfy]

That is possible, but it's a lot more work and needs thorough testing. Pretty low priority wise for me now. (Some bug fixing of pyReScene and a new release, and then ZIP support comes first. Even a GUI I would start on sooner.)

I think batch renaming files can be more error prone too, depending on the implementation. I would not like to give the ability too soon for renaming just the RAR file name. Someone can make capitals to lower case "because it looks nicer". Since we try to have it original, this is of course contra productive. CD2 folder would still be before CD1 if it was made like that.

When reusing the collision queue code, not much new has to be written. It's a familiar concept and it'll be a learning platform for the collision queue.

One issue could be that while replacing, some capitals would be lost and maybe others new. For this case a renaming function will be necessary.

[Gfy]

SRRs with different RAR paths are stored on disk for further handling + db record.

Stored file names with a different path or capitalization are stored in the database.

Both tables still need a front-end to handle them.