When a file gets queued up, first check to see if that filename
already exists. If so, skip the file. Currently nzbperl checks to
see if the "part" filename exists, and if so it skips it. It doesn't
(from what I can see) check to see if the resulting (complete) file
already exists. Currently if you stop nzbperl in the middle (or
wherever) of a large download and re-start it the already downloaded
files will be re-downloaded, and the file will be named <file>.1,
<file>.2, <file>.3... (etc, depending on the name of the file that
already exists).
Thanks for the great work!
The only way for nzbperl to know what the filename will be is to
download the first part of the file and peek at the uuenc or yenc
header. By default, when the file already exists on disk, it will *not*
be redownloaded. Unless you're using the --redo option, you shouldn't
normally see .1 .2 etc. files.
-jason
Thanks
On Aug 6, 12:21 am, Jason Plumb <ja...@noisybox.net> wrote:
> Unfortunately, this is by design.
>
> The only way for nzbperl to know what the filename will be is to
> download the first part of the file and peek at the uuenc or yenc
> header. By default, when the file already exists on disk, it will *not*
> be redownloaded. Unless you're using the --redo option, you shouldn't
> normally see .1 .2 etc. files.
>
> -jason
>
Interesting. I suppose this could happen with small, single-part files.
Is that maybe what you've got?
-jason
On Aug 7, 3:18 am, Jason Plumb <ja...@noisybox.net> wrote:
Still stumped. Maybe you can self censor and post a portion of your log
file that shows this behavior?
-jason