Fmstrat wrote:However, I thought I was following your directions for how I should contribute, since I was originally working on the master branch:
If you based in on "develop" then you did the right thing.
It's only me who is behind with the work of merging patches from "0.7.x" to "develop".
It requires a few evenings of concentrated work, those evening are hard to find
Fmstrat wrote:However, I thought I was following your directions for how I should contribute, since I was originally working on the master branch:
If you based in on "develop" then you did the right thing.
It's only me who is behind with the work of merging patches from "0.7.x" to "develop".
It requires a few evenings of concentrated work, those evening are hard to find
Like posted in the other thread I too am missing out of the new 0.7.x releases as I am using the develop branch as I thought this would be the latest code releases but this is going in the 0.7.x branch.
If the better priority code makes it at some point it is something there are at least a few people in this thread that can feedback and probably more that are just lurking.
Currently "develop" is seriously behind 0.7.x
This has to do with the fact the the Unicode-ification makes the code bases divergent.
As soon as 0.7.17Final is out, I will start the merge actions.
It has become quite a challenge.
shypike wrote:Currently "develop" is seriously behind 0.7.x
This has to do with the fact the the Unicode-ification makes the code bases divergent.
As soon as 0.7.17Final is out, I will start the merge actions.
It has become quite a challenge.
Sounds good. I will update and give it a try when you have time to merge.
shypike wrote:Currently "develop" is seriously behind 0.7.x
This has to do with the fact the the Unicode-ification makes the code bases divergent.
As soon as 0.7.17Final is out, I will start the merge actions.
It has become quite a challenge.
Hi Shypike,
I got a PM about wanting to pull from my GitHub version and realized that you've made changes to the master that have overwritten my server priority updates in my own fork(I'm assuming because of overlapping lines). Were you ever able to look at that pull for integration?
Fmstrat wrote:
I got a PM about wanting to pull from my GitHub version and realized that you've made changes to the master that have overwritten my server priority updates in my own fork(I'm assuming because of overlapping lines). Were you ever able to look at that pull for integration?
By the time I'm ready syncing "develop" with "0.7.x",
I will hand-merge your solution into "develop".
I'll get back to you then, so that you can easily create a new pull-request, so that your authorship is acknowledged.
Currently, I'm simply flooded with other things in the non-SABnzbd part of my life.
shypike wrote:By the time I'm ready syncing "develop" with "0.7.x",
I will hand-merge your solution into "develop".
I'll get back to you then, so that you can easily create a new pull-request, so that your authorship is acknowledged.
Currently, I'm simply flooded with other things in the non-SABnzbd part of my life.
Wondering if you have had any time to look at getting the new priority system merged and integrated?
When the develop branch has caught up with recent 0.7 enhancements please announce.
shypike wrote:"developer" is now about at the same level as "0.7.x".
You can rebase and create a new pull request.
Sorry for all the delays.
shypike wrote:By the time I'm ready syncing "develop" with "0.7.x",
I will hand-merge your solution into "develop".
I'll get back to you then, so that you can easily create a new pull-request, so that your authorship is acknowledged.
Currently, I'm simply flooded with other things in the non-SABnzbd part of my life.
Fmstrat wrote:
Hi shypike,
I know this isn't the newest post on the topic, but since it's the first result on Google I figured I would respond here.
I spent the day today forking sabnzbd in github to https://github.com/Fmstrat/sabnzbd and I think I've got an enhancement in place for this. It took me longer to figure out the current process than it did to update for priorities.
As it stands now, Primary servers still outrank Backup servers regardless of the number set in the priority setting. 0 priority means it will be used first, higher numbers later. On upgrade everything is set to 0, retaining current randomized backup order.
The code has a ton of debug logging calls in it now that I'll remove after I've tested this for a while before pushing up to the master (new to git, so still figuring that out).
Thanks,
B.
Thanks for the update I assume you mean the "develop" branch.
No idea where to start with this myself I was just enquiring if there was a chance of testing the priority code out?
I do not know if Fmstrat is still around to submit a pull request it would be a pity to not have this functionality.
sab12397 wrote:Thanks for the update I assume you mean the "develop" branch.
No idea where to start with this myself I was just enquiring if there was a chance of testing the priority code out?
I do not know if Fmstrat is still around to submit a pull request it would be a pity to not have this functionality.
Yes, the "develop" branch.
I'll have another look at fmstrat's contribution.
I don't have time at the moment to resync and re-make the changes, but if it helps, here is a diff from when I conducted the change. It was a pretty straight forward tweak overall:
Added a numerical priority option into the config_server and setup wizard skins
In get_article, where it looped through the servers, it originally only skipped a server if it was a backup and all primaries had not been tried. I simply made it say: "If we are in primaries, and there is a primary left with higher priority, skip. If we are in backups, and there is a backup left with a higher priority, skip." This required passing the "servers" array to get_article, too.
P.S. I should note, this isn't the MOST efficient way to accomplish this. Due to the multi-threaded nature of processing I couldn't simply go in order without re-writing the code (which is the reason I know you didn't tackle this). However, this method didn't show any noticeable slow-downs in transfer speed for me, or in CPU cycles even on a lowly VM.
