adrian-bl / bitflu

Bitflu BitTorrent Client
http://bitflu.workaround.ch
32 stars 6 forks source link

autload stops working if a zero-lenght file is present #8

Closed melo closed 13 years ago

melo commented 13 years ago

Hi,

I'm haven't completed my investigation of this problem, but it seems that this is the problem.

My RSS-to-torrent application has a bug and sometimes creates 0-lenght .torrent files. When this are present, autoload stops working.

I've added a script to remove 0-length files over 5 minutes old and this restarts the problem, so it seems that this is the problem somehow.

I'll investigate further.

melo commented 13 years ago

BTW, this is with 1.35. I'm going to upgrade to 1.37 today to see if that solves the problem.

I'll keep you posted.

adrian-bl commented 13 years ago

A 'fix' for this is may be already present in the git version with commit bfc2f663653f025f19dbe64a37253da3d1b11014

Bitflu <= 1.37 stops the autoload loop after checking 10 files. So if the autoload directory has too many 'invalid' files, bitflu might never actually see any 'valid' files. (Bitflu only deletes the source file if it was able to load the file - it doesn't touch 'unknown' files)

In 1.38 this has been changed: The loop doesn't count the files but exits after >= 2 seconds.

The real fix would be to keep the directory *FH open and use seekdir() if we hit the end, but i'm not sure if it's worth the trouble as the autoload directory simply isn't supposed to contain any non-torrent files (and bitflu prints a warning if it failed to load a file in autoload)

melo commented 13 years ago

I'll check the latest version.

But regarding the "autoload" directory having only .torrent files, in my case I use a Dropbox directory as autoload, so I can drop .torrents on any of my PC/Mac's and have bitflu on a remote VPS start the download. Dropbox on Linux creates a .dotfile for control, so at least the autoload code should skip over .dotfiles.

melo commented 13 years ago

Latest version fixed my problem, thanks.