What does it mean when CS says it has changed the line length for pars?

[Radish]

Hello

I set up CamelSystem 2.3 (CS) to deal with files opened for posting as having  'lines' = 4,000.  The following files for a post are then loaded into CS in a good way, like this:

*.nzb
*.nfo
*.par2  (i.e. the empty par2 file for checking if other pars need to be downloaded)
*.rar   (i.e. all post rar files)

All those files will have a line length of 4,000.

However, when it lists the rest of the par2 files I get something like the following:

+xx.PAR2    line/part changed to 4001 to sync with pars packet size 512068

When I look at the properties for any of those par2 files I do see that the line length has been changed by CS to '4001'.  It is not clear to me why CS is doing this.

When I construct the rar files and then make pars for them using QuickPar v.0.9.1 I am very careful to see that QuickPar does have the 'block size' for the par files it is about to create set to 512,000 (which is optimal for posting at 4000 lines). I mean I check all this carefully.

Yet, as noted above, CS seems to be suggesting that I must have had the block size set to 512,068 in QuickPar2  -  which is not correct.

The same kind of thing happens if, for example, I try to construct a post set using 3,000 lines.  Same sort of thing happens CS claims the par2 packet size is wrong and changes the line length for them.

Is this a bug in CS or is there something I don't understand properly?

N.B. I also have a feeling that in changing the line length for the par2 files from 4,000 to 4,001 that this is some way inefficient and not like by servers when those par2 files get posted in that way. An further information on this would appreciated.

[Timothy]

I Think, and it's just an idea, that quickpar makes par2 files in that way.

quote:
+xx.PAR2    line/part changed to 4001 to sync with pars packet size 512068

So the packet size is 512068, therefore Powerpost is changing the lines.
Don't know why, but okay.

No big deal, works like a charm.

Anyway, did you know that Powerpost can make par2 sets and that it's doing this job quicker then Quickpar?
see http://forum.camelsystem.nl/index.php/topic,82.0.html (dutch version)

Sorry for dutch language of that topic, but here's a translation with google:
http://translate.google.nl/translate?js=n&prev=_t&hl=nl&ie=UTF-8&layout=2&eotf=1&sl=nl&tl=en&u=http%3A%2F%2Fforum.camelsystem.nl%2Findex.php%2Ftopic%2C82.0.html&act=url


I always click on okay! do your thing! and it all goes well. ;-)

[Radish]

Thanks for the response Timothy.

Having read it, yes, I think your suggestion that QuickPar v.0.9.1 is creating blocks larger than it states is probably correct, rather than CS-PP 'mis-reading' the PAR2 files.

Yes, I did see that CS-PP can create PARS.  However, when I tried (have to say didn't try very hard, just clicking through buttons) I couldn't get it to work.  Argh!!!!

However, saw a quick guide in English at this webpage:  http://www.binaries4all.com/powerpost/preparing.php

The page is instructions for using CS-PP.  I stepped through the instructions and made PARS no problem.  Also those PARS load into CS-PP with no messages about 'changing line lengths' or warnings about the PAR2 files being incompatible with number of lines.  Great, I thought, I guess I'll be using that from now on.

However, when I looked at the 'Task properties' of the PAR2 files I see that, again, the line length is changed from '4000' to '4001' - it's only that now no message is output by CS-PP that this has been done. So, again, there seems the same mismatch is going on - all the other files in the post are at line length 4000 except the PAR2 files (the line length still gets changed).

Also, I noticed after a little bit of testing that from what I understand of the standard way of posting that CS-PP isn't following 'standard rules of posting' for constructing the PARS.  Nothing serious but let's say I've made an 'nfo' file as part of a post.  Obviously I'll want to load that into CS-PP at the same time as I load in the RARS (or come to that, any 'archive set' e.g. ZIP, 7-ZIP, or 'working set' of files, the files that someone would actually want to use) - that way I get the post parts, including the 'nfo' numbering easily into the correct sequence.

But, if I get CS-PP to make the PARS, then the PARS that are produced will include the 'nfo' as being part of the set files that the PARS will repair if any file is damaged or missing.   Yet that is non-standard posting practice and wasteful of one PAR block - if they really were needed for a repair - because one block is going to be used to recreate an 'nfo' that some people might not bother to download anyway.

In the worst case, let's say someone downloads a set of RAR files that are damaged to the extent of needing 20 PAR blocks to repair the damage.  That person has also downloaded all the PARS for that 'file set' and all those PARS amount to 20 blocks.  But that person has not downloaded the 'nfo' for that post.  What happens in this case?  The repair fails.  There are enough PAR blocks to repair the RARS. But not enough to repair the RARS + the 'nfo'.  Of course the downloader could go and get the 'nfo' - but what now happens if the 'nfo' is damaged?

I'd therefore like to suggest that CS-PP just have that bit tweaked a little so that when it makes PAR files 'nfo' files will be excluded from the list of files sent to the PAR creating program.  Makes sense, at least to me.  I'd note that on creating PARS CS-PP doesn't include the 'nzb' in the list sent to the PAR creating program - which I think is the correct thing to do (and is also standard practice that 'nzb' files wouldn't be included in a PAR set repair list).

In any case I'd guess the PAR creation thing needs looked at a bit. The same error exists no matter if I use QuickPar or CS-PP - CS-PP will still change the line length for the PAR2.

Hope this makes sense and helps.