sabnzbd/sabnzbd — pull request #43 by isc-usenet (2012-06-02 04:29:46+00:00)
Title: Fix sabnzbd handling for splitfiles that start with .000

The problem lies with newsunpack.py in the `file_join()` function.

As an example, I have an NZB file of a creative commons song http://pastebin.com/Me2iC2HZ

Despite there only being 3 splitfiles (.000, .001, .002) the function calculates the `expected_size` as 6. This is due to the lines
```for i in xrange(len(joinable_sets[joinable_set])+1):
expected_size += i```
running with the attached NZB, `joinable_sets[joinable_set] = ['unreal_dm_-_Judgement_Day.mp3.000', 'unreal_dm_-_Judgement_Day.mp3.001', 'unreal_dm_-_Judgement_Day.mp3.002']`, which is 3 items plus 1 is 4
So that means the for loop is running over an iterable that is equivalent to the list `[0,1,2,3]`
Adding these numbers together, you get 6 when the correct number is supposed to be 3

The next problem lines are the ones that handle `real_size`
excluding the .ts handling lines
```for joinable in joinable_sets[joinable_set]:
head, tail = os.path.splitext(joinable)
real_size += int(tail[1:])```
in this case, int(tail[1:]) is the number at the end of the split file, so 000 in .000, 001 in .001, etc.
with the NZB above, the values added to real_size are `[0, 1, 2]` because those are what the splitfiles end with.

I have modified these two portions to simply count the number of files, rather than attempt to count the values of the extensions.

We believe the reason this has gone undetected for so long is because the majority of NZB uploaders use a tool called "hjsplit", which starts at .001 instead of .000. In the case of a file split with this method, if we had the NZB with .001, .002 and .003 instead, the `expected_size` would be `sum([0,1,2,3])` and the `real_size` would be `sum([1,2,3])`, both of which equal 6.

This pull request will fix handling for .000 while keeping support for .001 working fully.