[Question] can this be used with the Extractor

[saitoh183]

So i got a torrent that comes in a rar format and filebottool wont do anything with it if it isnt extracted. So i turned on the extrator but you have to choose a location to extract. But this location is not the files folder. Would there be a way to have some sort of setting to take charge of the unrar location ?

[Laharah]

Hmm, I know that the FileBot AMC script can do extraction, but I'm not sure it's built into FileBot directly.

The main issue is that any files extracted wouldn't be tied to the torrent in deluge anymore, so it would have to be some kind of special file mode built into the plugin. I'll look into it and get back to you.

[Laharah]

looking at the filebot cli, it does have an --extract flag. I'll test it out and see if I can fit it into the plugin somewhere.

[saitoh183]

Cool...cuz the other thing that maybe could have been done, would be to maybe grab the extraction location from the Extractor plugin. But if you can use the extract cmd from Filebot, this would be best so that the extract is done within the torrent folder and not at another location.

[Laharah]

Experimenting a little with the -extract flag in filebot, it looks like it will extract the files first, leaving the .rar file untouched, and then add those files to the list of files to act on, this behavior makes sense, but it makes things a bit complicated for the plugin, depending on the exact circumstances.

The first situation, is you have a torrent that is a single .rar file. The rar is first decompressed, leaving you with a bunch of new files and the original rar file. If the mode is move, the new files will be sorted, and the .rar file is left behind. Here's the issues:

• the .rar file will have to stay so you can keep seeding.
• even though the move rename action was selected, the torrent won't appear to have been renamed at all, and will still be seeding the .rar file from your default torrent location
• if the copy or any other rename action was selected, there will be 3 copies of your files. the rar file that you're still seeding from, the extracted files, and the copies/links of those extracted files that filebot has renamed and sorted.

The second situation is you have a torrent that contains a .rar file as well as normal non-rar files (for example subtitles all zipped together). Again, the archive will be decompressed and it's files added to the job. Here are the issues in this situation:

• If the file mode is move, the original archive will have to be moved with the rest of the files so that you can keep seeding everything. You will have both the archive and the files in it in the same place, next to the media files.
• if you copy, you'll have 2 copies of the media files and 2 copies of the archived files plus the original archive.

I'm trying to think of the best way to implement all this so that everything behaves both as you expect and as you would want. For the plugin I don't think it makes sense to allow the -extract flag in move mode, since the most common situation (a single .rar file torrent) won't actually move the torrent file. To the user, it will look like nothing happened.

I'm thinking that extract should only be allowed in copy mode. To stop the situation where you have 3 copies of each file (the achive, the files extracted as-is from the archive, and the duplicate that filebot makes to be renamed and sorted), I can get the list of files that were extracted and then delete them, leaving the archive for you to seed from, and the files that have been sorted. I think that will give the best balance of behavior that works and makes sense.

Some issues that will remain:

• torrents that have a .rar file as in addition to media files, will not have those archives extracted
• autosort rules to extract files will be a bit complicated, you would have to have a specific rule in copy mode with the extract flag for torrents that contain a .rar file.

Well, that's a lot of text for a fairly simple problem. I'm still not quite happy with that behavior, especially since it will really be complicated to automate everything with auto-sort rules. Let me know if you've got ideas for how things should behave, and I'll keep mulling everything over before I implement anything.

[saitoh183]

Yeah...phew...long read...

couldnt you utilize the hardlink function? Like create a hardlink of the completed to a temp directory and manipulate everything there and then delete it all once the process is done? this way you wouldnt be messing with the original file? Im thinking a bit like Rtorrent/RUtorrent autotool. I have it setup that it watches a folder containing sub folders of each or my blackhole apps. Torrent file is picked up and labeled the same as my watch folder subfolder. once done it hardlinks to my transfer folder which is linked to my btsync so i can manipulate the file as i please while it can continue to seed.

[Laharah]

well, the plugin already supports creating hardlinks and symlink (and soon reflinks for btrfs filesystems), which will leave the original untouched, while sorting the links to the correct places, but it won't solve the problem of needing to extract archive files somewhere, and then deciding where to point deluge when all is said and done. To keep everything seeding, any archives need to be kept as well, and since extracted files won't be shown in deluge I have to come up with a way to make the behavior consistent for when there's an archive and when there isn't.

[saitoh183]

But if you hardlink the completed folder, wont it take deluge seeding out of the equation because you would work on the hardlink file? As for the extraction, if possible, that should happen after the file has been hardlinked and if possible have it extract to the current folder. the --extract would extract to where by default?

[Laharah]

By default, -extract will extract to wherever the output field is set to, which if blank is wherever the completed torrent folder is. In the case of using the hardlink or symlink flags it's fairly simple, deluge would keep seeding without changing anything, The only thing to decide is where to keep the extracted files that we link to.

The hard part is deciding what to do when move is selected. Right now, the files are moved and renamed and then deluge points to their new locations. We couldn't do that with extracted files, since deluge would still have to point to the .rar files, the extracted files wouldn't be in the torrent info. We could just let it do it's thing, where as far as deluge is concerned, dexter.s01.rar or whatever wouldn't change (where even though you told it to move it looks like nothing happened), but we'd still have to decide what to do when there's a subtitles.rar or something as well as media files that are moved.

[saitoh183]

For the extraction location i would say make it the users choice (option to set). As you said...make this a copy function only since moving would complicate things...maybe you could tackle that later in another release? This would also give you time to see how the copy would work in real world usage.

[saitoh183]

any headway? Currently this is my only issue that is break automation.Right now since i use autoRemover plus to remove after certain seed time, i make sure it saves the torrent file so that i can redownload if it was a compress archive.

[Laharah]

I'm still considering the best way to implement things. It's not quite as straight forward as it seems. I'll post here when I can patch it in.

[saitoh183]

Ok no problem.