evilhero / harpoon

an rtorrent automated monitor script that will transfer from a seedbox to local machine, with additional post-processing for sonarr, radarr, lidarr, mylar, lazylibrarian and sickrage. Can also manually drop torrents for monitoring/transfer/post-processing...
GNU General Public License v3.0
45 stars 2 forks source link

harpoon crashes on Apple ._ files #15

Open vidjya opened 5 years ago

vidjya commented 5 years ago

When adding a torrent from a mac with the harpoon watch folder mounted as a smb share, harpoon seems to stop at apple resources forks (._filename.torrent).

There's no way to disable the creation of these files when moving a file to the share.

Here's the entry from the log:

Traceback (most recent call last): File "./lib/apscheduler/scheduler.py", line 476, in _run_job retval = job.func(*job.args, **job.kwargs) File "./harpoon.py", line 1258, in Scanner torrent_info = tinfo.main() File "/home/user/harpoon/harpoon/rtorrent.py", line 172, in main loadit = self.client.load_torrent(self.filepath, self.label, self.start, self.applylabel, self.basedir) File "/home/user/harpoon/harpoon/torrent/clients/rtorrent.py", line 112, in load_torrent torrent = self.conn.load_torrent(filepath, verify_load=True) File "/home/user/harpoon/lib/rtorrent/init.py", line 167, in load_torrent tp = TorrentParser(torrent) File "/home/user/harpoon/lib/rtorrent/lib/torrentparser.py", line 54, in init assert isinstance(self._torrent_decoded, dict), "Invalid torrent file."

As far as I can tell, it does not go past that point.

vidjya commented 5 years ago

Scratch this, I think this was due to the specific torrent file I was using. I removed that one and added another one without issue. It seems that the torrent file I was using was already in rtorrent and it didn't really deal with that.

evilhero commented 5 years ago

If the torrent file was already in rtorrent when you added it, it should just simply report back some of the stats and then try to harpoon it back locally and perform the post-processing as required.

Odds are it was trying to actually load the ._filename.torrent file as a legitimate file (because it looks for anything with a .torrent extension in the watch dirs when monitoring), and obviously it wasn't. Should be an easy fix to ignore those types of files going forward.

vidjya commented 5 years ago

To be clear, I thought it was stopping on the dotbar file. It probably wasn't because I dropped another torrent into that folder and macos automatically creates a dotbar. That torrent worked fine, however. Loaded and downloaded to my local server.

In terms of downloading an existing torrent, it wasn't doing that. It creates a hash file and then stops. I tried that a couple of times with the daemon, but had no issue downloading it manually with harpoon.

vidjya commented 5 years ago

Harpoon's definitely having some issues with dotbar files. I'm having some trouble recreating it due to other stability issues (possibly OS related?), but I can confirm that after deleting a stray dotbar file, the waiting torrent started up on the next run.