resume priority: again priority should be enough.
How about assigning prios from 1-100 with low == 20, normal == 50, high == 80 and custom == whatever ?
Wouldn't that confuse auto-prio?
I expressed myself wrongly. I meant that automatic priority is based on the number of sources available for the file, but a stopped file (waiting to be resumed) doesn't have any sources, thus gets 'Auto [Hi]' priority.
Problem #1: There's no matter which number you choose for the 'Auto [Hi]' priority value, there will be a series (or whatever, someone want to download) that is longer than the remaining value range. You could of course make it "infinite", by using the whole range of an uint64, but:
Problem #2: You'd use download priority as resume priority. If I want a file to be resumed before the 'auto' files, I have to set a manual priority higher than automatic high priority. But that priority will be kept after resuming the file, so that file will have a (manual) priority higher than all other files, which I might not want, I'd want it to download normally. We could of course add a preference option 'Reset manual priority upon resuming file', but this is the point where we are just adding complexitiy (and most likely bugs).
Thus I'd suggest the following, if we're ever implementing such a feature:
- leave download priority alone, that's a completely different thing,
- add a new property 'Resume order', which is automatically set to, say, -1, meaning random,
- think of this number as an index into a list, and handle it accordingly when setting on a file,
- when resuming a file, select the 'first in the list', i.e. the one with the lowest non-negative value,
- if there's no file with non-negative value, select one randomly.
