SABnzbd Forums

Hello,

I have a few feature requests, if you don't mind. These are mostly related to the handling of problems. It is possible the features exist and I missed them, but I will post them anyway. I was using 0.7.0 Beta 8, when I started writing this, but final now, just for reference. Got a bit busy. It seems these haven't been changed, so I'll post this anyway.

#1 - I would like to see a new option for user choice of how to handle a harddrive not being present. Say, for example, that you use an external harddrive. If it isn't plugged in and the temporary directory is set to folder on it, then it sets itself to the default directory when Sabnzbd starts. Then, you have to plug the drive in, set the directory, and then rebuild the queue. Wouldn't it be easier to just have it not change anything and go to an inactive state or something? Perhaps auto detect if the drive is added? The changing of the directory is what is screwing everything up.

It might be better as an optional choice, but I think it would be a good one. Not just for that situation, but for drive problems when they aren't detected and for other reasons. It seems like it shouldn't just change to a new path and force a whole queue rebuild every time. On top of that, if nzbs are present elsewhere, they start downloading to the wrong place, which isn't useful either.

It isn't a bug, but it is probably something that could be made better. I can see why it does, what it does, but I don't find it useful for my setup.

#2 - I would like a way to stop files that are being processed. Whether it be unrarring, par checking, or whatever other state.

I was downloading a 7 gig collection of files, parred and rarred the standard ways. One of the rar files was damaged, pre par creation. Initially the pars were taking forever (Before I realized the damage) and it seemed to not be handling the problematic files well.

So... I then decided it was quicker to just crash the client and use Quickpar. Eventually, quickpar fixed all the files (Took a few tries with the damage). Anyway, of course the rar was still damaged.

So then, comes the two problems. I restarted Sabnzbd and it tried to unrar the files, only it couldn't and just hung on the broken file and nothing could be done. That is when I saw that again, I couldn't stop the processing from happening. I used Unlocker this time and stopped it from running.

The main issue, both times, was that I simply couldn't stop the files from being processed. I would like a simple way to pause, stop, or whatever can be done. To be able to kill it and delete it, completely, would be nice as well. Any control would be better than what I currently see.

#3 - A better way of remembering the queue order. My client always resets it, a bit, on me. No matter what I do, it will pick a different order based off from my last sorting and some randomness. It simply doesn't remember when I move stuff on my own, other than priorities. Would it be possible for it to respect the last order, every time? Basically, if I move something to the top, it should stay in the same spot if the client is restarted. Basically, lets say I have 5 files on Force and 5 on High. If I sort them, within their priorities, those sorts should hold. Those ten files and should be in the same order that I put them in, next time it starts. It happens more with downloads on Force, but... my queue gets screwy, here and there, as well.

#4 - A way of bringing back the new tray icon if it crashes.

#5 - A way to pause/unpause files individually. I was trying to unpause some pars I needed and it wouldn't give me a way. Which leads me to:

#6 - If only pars are added, it should allow downloading of the pars. It wouldn't do this for me. Maybe I am missing a setting, but it would only grab the first one, see there was nothing to unrar or par check, then delete the job.

#7 - An option for duplicate files to retain the same name/temporary folder location. Imagine you only grabbed parts of something and you go back with a fully complete nzb later, you then have a different name and a different temporary folder. Now, lets say you have all files that are available already on the system, the option should allow them to not be downloaded. If you have files in the job that aren't in the temporary folder, then it should download them and add them to be checked. If there are pars for the job, then it should check, then add them if need be. Right now, it just sticks the junk in another folder and the two jobs can't connect. A possibility would be to just have it have an option to compare to existing files in the same temporary folder, but a more advanced option, if possible, could have it even register better versions of broken files, missing par files now added, etc...

#8 - I think I remember Plush used to have a double click a job to move it to the top of the queue. Maybe, maybe not, but that was really cool. I would like to see that again. My computer that I use to download is a bit on the slow side, so it lags a bit on priority selection. This might be a bit easier on it.

That is all. Thank you for reading. You can totally ignore me. Not trying to force anything, just some friendly suggestions.

Take care.

#1:
Problem not existent on Windows, solved for OSX.
Unfortunately the Linux world suffers from lack of standardization;
there's no sure way to tell where volumes are mounted.

#2:
Just shoot down the running par2 process, preferably not SABnzbd itself.
Currently we cannot terminate processes in a way that doesn't require platform-dependant code
(lack of standardization again).

#3:
I don't know what you mean here. There's priorities. The queue order is remembered, unless you have auto-sort enabled.

#4:
Windows problem (or else the library that we must use).

#5:
Makes not much sense for most users and would only complicate matters.

#6:
Use "Download-only" instead of +Repair, +Unpack, +Delete
Besides if you want to add par2 files to a failed job, just add an extra NZB files in the Retry dialog box.

#7:
You miss the basic premise of SABnzbd. It's an automation tool.
If this is the way you need to scrape stuff together, then maybe SABnzbd is not the right program for you.
We're not going to turn it into a highly interactive tool that gives you all sorts of manual repair options.
Basically if you're dealing with broken NZBs all the time, SABnzbd is not for you.

#8:
It didn't. Just set a job's priority to the highest level and it will jump up.
So slow that it is too slow for Prio changing? I can imagine that drag-and-drop queue ordering is slow.
The Classic skin works with numbers (not recommended as a skin though).

#1:
Problem not existent on Windows, solved for OSX.
Unfortunately the Linux world suffers from lack of standardization;
there's no sure way to tell where volumes are mounted.

It exists on Windows. Maybe you misunderstood what I said. The short version would be: If you set the temporary directory on another drive and then start the program without the drive there (Say you unplug it), it auto defaults to the original temporary folder. This forces a change back to the chosen temporary folder (Once the drive is back) and a queue repair, every time.

#2:
Just shoot down the running par2 process, preferably not SABnzbd itself.
Currently we cannot terminate processes in a way that doesn't require platform-dependant code
(lack of standardization again)

I understand the lack of ability to do this. Definitely something that would be cool if ever possible in the future.

#3:
I don't know what you mean here. There's priorities. The queue order is remembered, unless you have auto-sort enabled.

Forced jobs revert back to their original order on every restart, for me. I don't know why. I can't change their order. As for everything else, maybe it is a glitch, but the queue does seem to sort itself, on it's own, once in a while. I don't know how to explain or track it, really. So lets say not important.

#4:
Windows problem (or else the library that we must use).

I get it, thanks.

#5:
Makes not much sense for most users and would only complicate matters.

I get that. The automation of SABnzbd doesn't always work perfectly, so it would be nice, but at the same time the client would become awkward if it had paused jobs sitting there or something. I can always use another client to get something specific, so it isn't the end of the world.

#6:
Use "Download-only" instead of +Repair, +Unpack, +Delete
Besides if you want to add par2 files to a failed job, just add an extra NZB files in the Retry dialog box.

It wasn't for a failed job, but it is nice to know that you can use Download-only. I didn't think of that. I think I am too used to it being a feature of other clients that I didn't think of it being done, that way, in SABnzbd. Good enough for me.

#7:
You miss the basic premise of SABnzbd. It's an automation tool.
If this is the way you need to scrape stuff together, then maybe SABnzbd is not the right program for you.
We're not going to turn it into a highly interactive tool that gives you all sorts of manual repair options.
Basically if you're dealing with broken NZBs all the time, SABnzbd is not for you.

Alright, lets not go to not the right program or not getting it. I've used the program since the beginning, before you guys took over. I know what it does and what you are going for. I do tend to switch between three clients, so I get both lost once in a while and sometimes I see features that I think all should have, regardless of their aim.

Now, I was only talking about the way it handles duplicate jobs, not going further in and saying that I use it non stop to manually connect jobs or anything. Obviously I would break out a more appropriate client. I know SABnzbd glitches here and there and lets just say that manual intervention has to happen. My suggestion was simply to allow for a way of speeding it up by not creating a new folder and being able to work off from the same job. Sometimes it isn't always as clean as being able to retry or use another NZB.

However, I also see your point and even though it isn't an all the time thing, if you download many jobs, it is likely that any user has to be smarter than the client once in a while. So, my thought is that I accept that. I know not everything can or will be built in, so once in a while, a job will have to have some manual work done. Cool with me.

#8:
It didn't. Just set a job's priority to the highest level and it will jump up.
So slow that it is too slow for Prio changing? I can imagine that drag-and-drop queue ordering is slow.
The Classic skin works with numbers (not recommended as a skin though).

Maybe it was Classic. I thought Plush had it right when it first came out. Lets just say a bit of bad luck took out two faster download only computers, so I broke out the oldest one I had, 13 years old and set it to the task. It works quite well after a personally hacked version of XP and lots of additional tweaking.

I wouldn't call changing priorities painfully slow. It is more that I pick one, then it has to wait a second or two. I just thought having a double click the part you can click would be a lot faster and more convenient to move it to the top of the queue. I know it used to be there in either Plush or Classic. I thought I remember Plush. I always have had many jobs going, since the dawn of time. I download a lot and I get nitpicky over priorities. Drag-and-drop is not so good with a few hundred jobs going.


Thanks anyway, for replying.

#1
I did misread your comment.
SABnzbd just must have its temp download folder.
Going into blocked mode or something like that may very well confuse
inexperienced users.
We have't really found a right solution.
If it's really a problem for you, encapsulate the SABnzbd startup
with a little script.

shypike wrote:#1
I did misread your comment.
SABnzbd just must have its temp download folder.
Going into blocked mode or something like that may very well confuse
inexperienced users.
We have't really found a right solution.
If it's really a problem for you, encapsulate the SABnzbd startup
with a little script.

What's the problem of adding a switch that allows you to manually set a temporary directory so that it stays persistent? The current situation is really bugging me because my nfs shares are up after sabnzb is loaded.
If its the inexperienced users you're worried about, why don't allow hidden settings in the sabnzbd,ini file so they don't get bothered.

k7o wrote:

shypike wrote:#1
I did misread your comment.
SABnzbd just must have its temp download folder.
Going into blocked mode or something like that may very well confuse
inexperienced users.
We have't really found a right solution.
If it's really a problem for you, encapsulate the SABnzbd startup
with a little script.

What's the problem of adding a switch that allows you to manually set a temporary directory so that it stays persistent?

Probably none. Only one way to find out: start coding, k70.

k7o wrote:
The current situation is really bugging me because my nfs shares are up after sabnzb is loaded.

Great; It's best to spend your precious time on something that is really a problem for you and that you really want to solve.

k7o wrote: If its the inexperienced users you're worried about, why don't allow hidden settings in the sabnzbd,ini file so they don't get bothered.

Sounds like a great idea!

k7o wrote:

shypike wrote: What's the problem of adding a switch that allows you to manually set a temporary directory so that it stays persistent? The current situation is really bugging me because my nfs shares are up after sabnzb is loaded.
If its the inexperienced users you're worried about, why don't allow hidden settings in the sabnzbd,ini file so they don't get bothered.

I'm afraid that I don't understand you suggestion.
Manually set a temporary folder?
I thought your problem was that SABnzbd doesn't wait for the temp folder
to come on-line?
A --wait-for-temp switch would be helpful for you, wouldn't it?

shypike wrote:

k7o wrote:

shypike wrote: What's the problem of adding a switch that allows you to manually set a temporary directory so that it stays persistent? The current situation is really bugging me because my nfs shares are up after sabnzb is loaded.
If its the inexperienced users you're worried about, why don't allow hidden settings in the sabnzbd,ini file so they don't get bothered.

I'm afraid that I don't understand you suggestion.
Manually set a temporary folder?
I thought your problem was that SABnzbd doesn't wait for the temp folder
to come on-line?
A --wait-for-temp switch would be helpful for you, wouldn't it?

My problem is that when I change a property in the sabnzbd.ini file, I expect it to be 'set', and not defaulted to a value that's hard coded in source. Although a --wait-for-temp switch could be usefull, I think a simple property for the default dir in the ini file is much cleaner. And when it's not available, throw an exception so the user can handle it.

My current fix for the problem:
Located constants.py
Changed row 78 and 79 with
DEF_DOWNLOAD_DIR = 'tempfolderlocation'
DEF_COMPLETE_DIR = 'completedirlocation'

I added a "special" to make SABnzbd wait for the temp download folder at startup.

shypike wrote:I added a "special" to make SABnzbd wait for the temp download folder at startup.

Never expected you'd add the feature in the next release (as i've learned from the source/docs, wait_for_dfolder), much respect for that.

Still I think it's nicer to just add a default_download_dir to the specials and let the user handle the exception if it's not available. When the service is inoperable because of a blocking state it's even more confusing in my opinion for inexperienced users (as you said yourself). At least you should raise the log level to error/warning instead of debug because it's a show stopper.

Nevertheless I'm very happy with this solution, you guys are doing a great job writing this superb service. Also I never expected feedback would be implemented this fast. Really like the agile mindset, as that's what developing software is all about. Merry Christmas all

k7o wrote:

shypike wrote: Still I think it's nicer to just add a default_download_dir to the specials and let the user handle the exception if it's not available. When the service is inoperable because of a blocking state it's even more confusing in my opinion for inexperienced users (as you said yourself).

Terminating SABnzbd because of a missing folder is not very helpful.
An automated start would then require a script to retry,
which means that you might as well use a script to test and wait for the drive before starting SABnzbd.
It's a special, for people who know what they're doing.
Handling this with visible feedback in the normal UI would just be too much work,
that's why I chose this simpler solution.

shypike wrote:#1:
#2:
Just shoot down the running par2 process, preferably not SABnzbd itself.
Currently we cannot terminate processes in a way that doesn't require platform-dependant code
(lack of standardization again).

While nice in theory, there often isn't a process running, and sabnzbd is stuck. For example, mine currently says
But there is no par2 or unrar process running on my system and it's been stuck on this for 9 hours. There's no way to get out of it because sabnzbd will not shutdown or restart. I have a large queue behind this stuck job, but it won't continue. The previous 4 or 5 jobs from last night all went fine, and I was able to manually extract the file from the incomplete directory (and there weren't even any PAR files in the archive).

There's two processes in ps Auww that reference SABnzbd.app at all both show they are "Sleeping". I can assume that the newer job is the one hanging things up, but it would be nice if there was something in that line that indicated unrar or par2 was part of that process, especially since after several weeks of system uptime, it can sometimes be harder to see which SABnzbd process is the one that should be killed.

shypike wrote:

k7o wrote:

shypike wrote: Still I think it's nicer to just add a default_download_dir to the specials and let the user handle the exception if it's not available. When the service is inoperable because of a blocking state it's even more confusing in my opinion for inexperienced users (as you said yourself).

Terminating SABnzbd because of a missing folder is not very helpful.
An automated start would then require a script to retry,
which means that you might as well use a script to test and wait for the drive before starting SABnzbd.
It's a special, for people who know what they're doing.
Handling this with visible feedback in the normal UI would just be too much work,
that's why I chose this simpler solution.

For the record, something like this:
Obviously you would want to check if sabnzbd is already running and you will want to run this periodically (like, say, from cron or launchd).