I'm pretty sure this functionality is not built in to sabnzbd, but I'm wondering if there is some way I could enable it, or if there is any chance of supporting it.
I know that unraring two things at once isn't necessarily efficient - because both unrar processes will take longer, especially if PAR is going on, but the issue is kind of this...
Sometimes I'm downloading a really large thing and it is missing a lot of blocks it starts repairing. Depending on the thing, sometimes this repair can literally take an hour or more.
Meanwhile, a bunch of things have downloaded in the background, don't need to be repaired at all, but are being held up from unraring for a whole hour while the other thing repairs.
I would love if the newly downloaded items would at least verify/extract, even if they take slightly longer -- if they need to be repaired, then they could queue behind the other ?
Because I know that even if the unrar normally takes ~20 seconds... maybe while a par2 is running it will take 60 seconds, but it will still be a lot less than an hour.
I guess the other concern is putting more stress on the CPU and hard drive which is why maybe this setting wouldn't be enabled by default, but I still think the setting would be useful, and for me I would enable it.
It doesn't seem like it would be that hard, but I'm not sure. Has anyone thought about this or considered something like this before? I guess I'm just curious,
Thanks !
Unrar two at once?/Unrar another while one is repairing?
Forum rules
Help us help you:
Help us help you:
- Are you using the latest stable version of SABnzbd? Downloads page.
- Tell us what system you run SABnzbd on.
- Adhere to the forum rules.
- Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings. - Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Re: Unrar two at once?/Unrar another while one is repairing?
It would be quite a lot of work to enable this; the code is now relatively simple
because there is no parallelism.
Only more powerful systems would benefit.
Other than that, it's hard to predict the time needed for a repair.
So SABnzbd could not determine by itself whether starting an extra job woul be beneficial.
Right now the to-do queue is full enough without this feature.
because there is no parallelism.
Only more powerful systems would benefit.
Other than that, it's hard to predict the time needed for a repair.
So SABnzbd could not determine by itself whether starting an extra job woul be beneficial.
Right now the to-do queue is full enough without this feature.
Re: Unrar two at once?/Unrar another while one is repairing?
Ok no worries about that if it would be a lot of work.
I would just comment though I don't think only powerful systems would benefit. For example I run sabnzbd in a few places but I run it primarily on my NAS. I used to run it on a popcorn hour media jukebox, but I moved it to the NAS because the popcorn hour would totally freeze up when repair was happening. On the NAS this doesn't happen because the NAS is more powerful than the popcorn hour (but it's by no means a 'powerful system' compared to any PC) But still the NAS has no problem downloading while other things are repairing/extracting. And it has no problem streaming over the network to multiple PCs at once while things are downloading or repairing.
So what I mean is I think if it could benefit a "less" powerful system like the NAS, which it could because when repairing the NAS CPU is only around 40%, it could easily be configured with no worry about CPU/etc. with a setting (assuming it existed I mean) like "Verify 1 at a time, Repair 1 at a time, Extract 2 at a time" . It's repair 2 at a time that would start to cause an issue. I guess verify would raise CPU also --- but since we need to verify before unraring that's what would be worrying.
I also want to say that I don't think it's necessary 99% of the time to run a full PAR2 check in order to perform adequate verification. If you look you will notice that 99% of the time files are corrupt bits are actually missing from the download and the file size of RARs are smaller -- of course this is getting (possibly) out of the territory of what sabnzbd strives to support, but when files are packed with a common-size rar, example 50,000,000 bytes -- every RAR except for the final rar which is smaller will be exactly the same size. You can almost instantly tell if for most cases if a file is corrupt by just scanning the file size. Therefore, I mean, if sab wanted to implement such a feature, they could check the RAR sizes, and if everything looks good - attempt to extract - if extract fails, THEN move to par2 verification which could even queue behind the ongoing repairs.
As it stands now, even perfectly OK files have to wait behind repairs , that's what is sort of tedious.
Anyway I understand the development time might not be worth it but I just wanted to make sure it's clear what would really be useful for the behavior of such a feature. SAB wouldn't really "determine if starting an extra job would be beneficial", it would just maintain two seperate queues, the RAR queue and the repair queue (and possibly a third verification queue, depending on if the file size trick can be applied). Sab wouldn't care if it's "beneficial" it would just do it regardless if your settings are defined that way.
I would just comment though I don't think only powerful systems would benefit. For example I run sabnzbd in a few places but I run it primarily on my NAS. I used to run it on a popcorn hour media jukebox, but I moved it to the NAS because the popcorn hour would totally freeze up when repair was happening. On the NAS this doesn't happen because the NAS is more powerful than the popcorn hour (but it's by no means a 'powerful system' compared to any PC) But still the NAS has no problem downloading while other things are repairing/extracting. And it has no problem streaming over the network to multiple PCs at once while things are downloading or repairing.
So what I mean is I think if it could benefit a "less" powerful system like the NAS, which it could because when repairing the NAS CPU is only around 40%, it could easily be configured with no worry about CPU/etc. with a setting (assuming it existed I mean) like "Verify 1 at a time, Repair 1 at a time, Extract 2 at a time" . It's repair 2 at a time that would start to cause an issue. I guess verify would raise CPU also --- but since we need to verify before unraring that's what would be worrying.
I also want to say that I don't think it's necessary 99% of the time to run a full PAR2 check in order to perform adequate verification. If you look you will notice that 99% of the time files are corrupt bits are actually missing from the download and the file size of RARs are smaller -- of course this is getting (possibly) out of the territory of what sabnzbd strives to support, but when files are packed with a common-size rar, example 50,000,000 bytes -- every RAR except for the final rar which is smaller will be exactly the same size. You can almost instantly tell if for most cases if a file is corrupt by just scanning the file size. Therefore, I mean, if sab wanted to implement such a feature, they could check the RAR sizes, and if everything looks good - attempt to extract - if extract fails, THEN move to par2 verification which could even queue behind the ongoing repairs.
As it stands now, even perfectly OK files have to wait behind repairs , that's what is sort of tedious.
Anyway I understand the development time might not be worth it but I just wanted to make sure it's clear what would really be useful for the behavior of such a feature. SAB wouldn't really "determine if starting an extra job would be beneficial", it would just maintain two seperate queues, the RAR queue and the repair queue (and possibly a third verification queue, depending on if the file size trick can be applied). Sab wouldn't care if it's "beneficial" it would just do it regardless if your settings are defined that way.