LottaNZB doesn't delete finished downloads

I'm sorry, but this is once again a won't-fix. First of all, the downloading is handled by HellaNZB, not by LottaNZB. LottaNZB only displays what's downloading/processing or not.

Second, this might have something to do with diskspace. Are you running out of space?

But HellaNZB alone never restarts my processed downloads. This can't be related to diskspace, first because in this case I wouldn't get any downloads nomore, and second because I've got many space free on both main and data disks :).

Still, the only thing that LottaNZB could do is requeue the NZB-file.
However, this is impossible, since the NZB-file gets deleted as soon
as it's queued for the first time.

On Sat, Mar 29, 2008 at 6:42 PM, Steph <email address hidden> wrote:
> But HellaNZB alone never restarts my processed downloads. This can't be
> related to diskspace, first because in this case I wouldn't get any
> downloads nomore, and second because I've got many space free on both
> main and data disks :).
>
>
>
> --
> LottaNZB doesn't delete finished downloads
> https://bugs.launchpad.net/bugs/208409
> You received this bug notification because you are subscribed to
> LottaNZB.
>
> Status in LottaNZB • Automated Usenet Client: New
>
> Bug description:
> Downloaded and finished downloads are re-processed on next LottaNZB startup, when leaving the finished item and even when the queue has been cleared. This creates new folders in the Download directory, and creates duplicates of allready finished downloads.
>

@Stéphane: Wonder if you still have this problem? If not, how did you solve it?

I'm interested as well in a solution if you found one because i also experience that issue.

I think duplicated files comes from the hellanzb daemon : when i download with lottanzb the files are both saved in the Download directory of lottanzb and in the daemon.processing directory of hellanzb. If you remove the files from daemon.processing previous downloads won't appears in lottanzb and won't be duplicated.

So it's kinda annoying because files are stored twice and are also duplicated again after that.

I use the standalone mode.

Hi Kevin Viraud,

thanks for confirming this bug! As aVirulence stated: The downloading and processing is handled by HellaNZB. LottaNZB doesn't have any influence on it. It's basically just a graphical interface to edit the configuration file used by HellaNZB and to monitor the download progress. However, I consider it important that we reveal the cause of this issue. We might be able to make LottaNZB fix this issue itself or at least provide a guide on how this bug can be fixed manually.

The extraction of downloads is done in the daemon.processing directory. As soon as it's complete, the extracted files are moved to the final Download directory. For some reason HellaNZB doesn't seem to clear this directory when a download is complete and instead does all the processing operation a second time once restarted.

Things that might help us to track down the problem:

1. Have a look at the HellaNZB log in your home directory: ~/.hellanzb/log. Are there any error message when a download is completed/processed the first and second time? Copy&paste the lines that might be useful.

2. You could also send us a copy of your HellaNZB configuration file: ~/.lottanzb/hellanzb.conf (Remove the password and username at the top first)

3. Quote Stéphane: "But HellaNZB alone never restarts my processed downloads." Totally weird, but well then: Try to run HellaNZB without LottaNZB (shut down LottaNZB first): hellanzb -c ~/.lottanzb/hellanzb.conf
3.1. Add a small-sized RAR download from another Terminal window using: hellanzb enqueue /path/to/the/file.nzb
3.2. Wait for the download to complete.
3.3. Ctrl-C to quit HellaNZB.
3.4. How does the daemon.processing directory look like?
3.5. Restart HellaNZB using the same command as above.
3.6. Does HellaNZB reprocess the download? Check the log and directories.

4. HellaNZB stores a list of downloads in the file ~/.hellanzb/nzb/hellanzbState.xml Doesn't the download dissappear in this file once it's completed and processed the first time?

5. You might try to enable the debugging mode of HellaNZB by shutting down LottaNZB and editing the HellaNZB configuration file in ~/.lottanzb/hellanzb.conf:

Hellanzb.DEBUG_MODE = "/home/you/Desktop/hellanzbdebug" (it may be commented out with a # right now).

Reproduce the bug and check the debug file on your Desktop (it will be quite verbose I guess).

The list of tasks has become quite long, sorry. But thanks in advance for your cooperation! Let's hope we get closer to the solution thanks to it.

There are no similar bugs reports on hellanzb.com. LottaNZB might in fact be connected with this bug somehow, though I can barely imagine it.

1 - No errors messages

2 - See the attachement

3 - When the download is complete, the file goes to daemon.proccessing and into DEST_DIR. The download in indeed reprocessed when HellaNZB is started again.

4 - Nothing particular in the file

5 - Haven't tried, but i really think that n°3 helped to see that it's probably hellanzb which is causing the problem and not LottaNZB unless it's a problem related to hellanzb.conf .

Anyway a temporary fix could be to use this line in the .conf :

# Optional external handler script. hellanzb will run this script after post
# processing an archive, with the following arguments:
#
# handler_script type archiveName destDir elapsedTime parMessage
#
# type: post processing result, either 'SUCCESS' or 'ERROR'
# archiveName: name of the archive, e.g. 'Usenet_Post5'
# destDir: where the archive ended up, e.g. '/ext2/usenet/Usenet_Post5'
# elapsedTime: a pretty string showing how long post processing took, e.g.
# '10m 37s'
# parMessage: optional post processing message. e.g. '(No Pars)'
#Hellanzb.EXTERNAL_HANDLER_SCRIPT = '~/bin/post_hellanzb.sh'
Hellanzb.EXTERNAL_HANDLER_SCRIPT = 'path/script.sh'

That way, in case of success, we could remove the files in deamon.processing.

I'm pretty new to hellanzb i probably suggest dump things ...

Ok, the log debug revealed itself very helpfull, i think ifound the bug ! Neither lottanzb or hellanzb is responsible : the problems comes from a python 2.5 library ( shutil.py ) which send an exception when copying the files to DEST_FILE because i'm trying to copy file from ext3 partition to a fat32 partition ( partition i use to share data with my windows instance ).

I tried to setup DEST_EXT on a EXT3 partition and it works ... So my bug definitivly comes from python, i'm trying to find a patch. Hope this will help some people.

Thanks a lot for triaging this odd bug! Good to hear that neither LottaNZB nor HellaNZB is responsible for this bug but on the other hand, it means that there is no quick fix for the problem we can provide with LottaNZB.

This bug has actually already been reported upstream. See http://bugs.python.org/issue1545 and the duplicate http://bugs.python.org/issue2549.

For the time being, it might be a good idea to write a FAQ in the Answers section.

Thanks again for your contribution.

LottaNZB 0.4 will make use of the EXTERNAL_HANDLER_SCRIPT for a new category feature. It would be interesting to know if HellaNZB passes a "SUCCESS" result to it even if the files weren't deleted from the daemon.processing directory. If so, it would be easy to remove the remaining unwanted files.

In this case we wouldn't need to implement any file system detection mechanisms and to add warnings to both the application and the documentation etc. Would be much cleaner IMHO.

Let's make a blueprint!

Well, I am a new linux user here, and I had the same problem. After I deleted all files in ~/.hellanzb/nzb/daemon.processing folder, downloaded and finished downloads were not re-processed on next LottaNZB startup. That's the way I solved this problem.
Why this happened in the first place I don't know...

I also experience this problem. It looks like it has trouble saving the files to my NTFS-partition. 'Operation not permitted'

2009-11-27 22:32:12,449 ERROR chrome: An unexpected problem occurred: Error'>: [('/home/ruud/.hellanzb/nzb/daemon.processing/chrome/Chrome OS 0.4.237 beta.part06.rar', '/windows/D/Downloads/GrabIt/lottanzb/chrome/Chrome OS 0.4.237 beta.part06.rar', "[Errno 1] Operation not permitted: '/windows/D/Downloads/GrabIt/lottanzb/chrome/Chrome OS 0.4.237 beta.part06.rar'"), ('/home/ruud/.hellanzb/nzb/daemon.processing/chrome/Chrome OS 0.4.237 beta.part11.rar', '/windows/D/Downloads/GrabIt/lottanzb/chrome/Chrome OS 0.4.237 beta.part11.rar',

The folder has the following permissions automatically assigned by Ubuntu:

Owner: root -> create and delete files
Group: plugdev -> create and delete files
Others: none

I don't know weather these are the correct permissions or not, but if I check another folder on that partition it has the same permissions and from nautilus i can read, write and delete files from it, so read and write access shouldn't be the problem.

Hi Ruud,

the problem is located in the Python module "shutil" and neither in LottaNZB nor in HellaNZB, so we depend on the Python developers to fix this bug and you most probably cannot fix it by changing the permissions of this NTFS directory. Theoretically it would be possible to change HellaNZB so that it works around the problem, but getting this patch included in the Debian/Ubuntu package is a devil of a job.

So what I suggest you to do is to select a download directory on a non-ntfs partition.