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.
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.
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.
Windows problem (or else the library that we must use).
I get it, thanks.
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.
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.
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.
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.