newsbin.com

Some downloads from a NZB are being saved to the correct $(NZBPATH) folder but others go to the parent.
Almost all triggered retrys go to the parent. The "Files list" does not always show accurate location. Downloading to multiple folders is preventing autopar / unrar from working correctly and most times ALL the pars are loaded (even when not necessary)!
I show plenty of available disk space on DOWNLOAD (network) folder and (local) DATA drives...

any suggestions?

What version are you using?

Currently on latest (6.60: 00 43 25 BD 20 E4), but this was happening on earlier 6.x as well.
System details:
Windows 7 /64 Professional, SP1 Intel i5-2500K with 4G Memory (shows 600Mb free in resource monitor)
"Download" directory target is a mapped network resource, 72G free; "DATA" is local with 43G free.
I haven't applied any O/S updates recently. (Windows Update is disabled)

Is it possible that the database could be involved? I have years worth of download history that have never been purged.
(and I would like to keep the 'duplicate detection' working, if possible!)

You ought to be able to look at the download list and see which folders the files are going to. I'm unclear what would make them go to random folders.

Not really random, they seem to go where they should or in the parent directory of that.
Also, this seems to happen more often when I have a "dirty" (slow/during prime-time) Internet connection.
Could the problem be related to the error / retry functions of download routines?

Perhaps the subject of a new thread, but ..
In the past, the 'download status' showed the color of server used for the various blocks. Now, when a segment is complete, it just shows all grey. This was useful in past and I see no reason why it was changed Comment?

Thanks in advance

n the past, the 'download status' showed the color of server used for the various blocks. Now, when a segment is complete, it just shows all grey. This was useful in past and I see no reason why it was changed Comment?

I thought the colors were pretty too but the problem was people couldn't visually tell when a file was completed or not. Now it's not ambiguous. If the file has colored chicklets, it's not complete. If it's all gray it's finished. Sometimes you have so many chunks it's impossible to tell if one is still downloading, failed or missing. Certainly the text status would tell you but most people never looked there.

Ok. Reasonable I guess. Still, the status of a segment was always shown in several other places. Maybe bring back the "chicklets" as an option?

Any new info / update to the download directory issues posted earlier in this thread?

This is becoming a consistent problem. Almost always results in autopar downloading ALL available .par files which adds 10% extra overhead.
File manager seems to show where they are saved, but autopar doesn't seem to find them for reconstruction.

I am using .nzb files with the following configured directories:
Main Download folder: \\Today\
NZB Download folder: \\Today\$(NZBFILE)\
UnRar folder: \\UnRar\$(NZBFILE)\

Also, following successful UnRar, many of the files are left and not cleaned up as was true in past versions...

It is hard for me to believe this is an O/S or configuration problem ...

Has this been looked into?

Has anyone else experienced this Issue?

I'd start by mounting the drive as a drive letter, changing the paths to use the drive letter and see what happens. It looks like you're using UNC paths, which should work but is relatively untested. There are no other reports of this so, I assume it's a local problem for now. If you're not using UNC paths, I suggest adding drive letters back. I don't think it's ever been tested without drive letters.

Using a Mapped drive letter fixed the problem(s).
apparently unc references are not parsed correctly in some of the modules ...

Thank You for your excellent work!

Good to know. I wonder if the issue is the repair and unrar stuff? Everything else is native windows but both unrar and repair are cross platform code.

I've tested with UNC when I implemented it, but not recently.