Search for torrents with data instead of .torrent files
closes #53
At the moment this is only a minimum viable product to experiment with this working.
Limitations:
- Cannot simultaneously search with .torrent files and data, only one or the other.
- Cannot inject yet, only saving works
- Must be run on the top level directory of torrent downloads. Torrents in that directory cannot be nested
- Can only run on one directory at a time
Changes planned:
- Fix injecting
- Add ability to search multiple directories
Maybe changes:
- Have option to just search on individual video files, ignoring folders. This would cost matches but could allow matches within an organized directory such as the one produced by radarr/sonarr
- Run with .torrent files and data in the same run. This is probably a good idea and useful for those that have their torrent and usenet downloads separate.
- Maybe some sort of hardlinking solution for better matching in the first maybe-change. Ideally this could extract an .mkv or other video file from an organized directory, make a hardlink to it elsewhere where it can match a torrent to 99% and download .nfo or samples to complete seeding. This is definitely larger and scope and would be tough to accomplish.
Maybe some sort of hardlinking solution for better matching in the first maybe-change. Ideally this could extract an .mkv or other video file from an organized directory, make a hardlink to it elsewhere where it can match a torrent to 99% and download .nfo or samples to complete seeding. This is definitely larger and scope and would be tough to accomplish.
you can safely call this out of scope lol
Also if you want to try tackling Daemon mode, I'd start by looking at implementation/usages of indexNewTorrents
Must be run on the top level directory of torrent downloads. Torrents in that directory cannot be nested
I think we should keep this limitation as-is. I don't think there's really any way to easily figure out if a given file/directory at arbitrary nesting level X is a root or not, and people don't really store their downloads that way either.
might be able to use https://stackoverflow.com/a/54439981 to reduce the number of disk reads
Yes, I would rather you go through and do the map edits. I'm not familiar with the syntax and I have a high probability of messing something up with it.
Other limitations I've come up with:
Regarding partial torrents, as I understand it qbit will allocate the storage space required at the start of the download, so there's no way to determine whether a download is complete or not. Right now it assumes true. I think it might be wise to at least give the option to recheck torrents or start paused so there's a safeguard against partial downloads. It would be pretty easy for the user to filter and resume the paused ones in qbit, anyway.
Also for usenet downloads: my Sabnzbd puts everything into folders. I think this is the default behavior and I don't even know if it can be changed. This will likely cause issues with usenet->torrent matching. I think my next move in terms of a feature will be looking inside of folders for matchable files. This would give better usenet matching and more importantly from my perspective it can allow users to scan the organized libraries that sonarr/radarr produce.
my Sabnzbd puts everything into folders
what does the folder structure look like?
my Sabnzbd puts everything into folders what does the folder structure look like?
/Usenet Downloads
|___ /download 1
| |____item1.mkv
| |____item2.mkv
|
|___ /download 2
| |____item1.mkv
|
|___/ download 3
|____ item1.mkv
No matter what, even if you're only downloading a single item, it will put it in a parent dir. I'm actually not sure if nested dirs are possible or common, someone else would have to comment on that. For some reason my sab is deleting my old downloads anyway lol