Recent changes to third-party-tracker-quickpar

Select multiple items in file grid

Anonymous — Sun, 28 Aug 2005 23:45:04 -0000

Though I'm genuinely in love with this piece of software I
just ran in to a small annoyance.

If you right click a file in the grid on the checking/recovery
screen you get the nice standard explorer context menu
so you can move files and the like. Cool stuff.
Unfortunatly you can only select one file at a time, I'd like
to be able to select multiple at once, all of them actually.

You see, If I mess up and put a couple of similarly
named collections in the same folder, It's usually a pain
to seperate them. I could just run the par file of every
collection and copy the files with the context menu from
the grid, but that takes a decent while if I have to do it
one by one.

Thank you

Incompatibility with other clients.

Anonymous — Tue, 01 Jun 2004 06:11:53 -0000

I am using Quickpar v0.8.0.0 with Windows Xp Pro,
and the latest service packs. Often when I have
attempted to recover downloaded attachments from
usenet I receive error messages which appear to be
erroneous. I also receive these errors when checking
known good archives.

These files are encoded with an unknown par2
client. These files are not reported as bad by other
users, or other utility programs (Winrar,SFV) and appear
to be otherwise whole and uncorrupted. However these
recovery files are reported as status 'damaged (0 blocks
available)' with the seemingly correct file sizes and
filenames. All of these files are within the same
subdirectory, with full user rights.

Please advise.

"Memory fault detected" almost everytime!

Anonymous — Mon, 17 May 2004 03:40:56 -0000

What does one do if they keep getting the error "Memory
fault detected" almost everytime? Shouldn't the
software have some checks and balances to make sure
that even if there are errors, they get fixed before
computing the par2 recovery files? I mean, lots of
people have memory that will not produce 100% error
free storage (most of us don't have ECC RAM). I will
check out the source code to try and fix if you like,
but I figured the original developers would know the
problem better than I. Plus, digging around the code
on a weekend doesn't seem like such a blast if you can
fix it in an hour! Other than this issue, the PAR2
verification rocks! Keep on truckin...

Kristian Hermansen
keherman@student.umass.edu

drag and drop

Pete — Sun, 28 Mar 2004 17:23:55 -0000

allow drag and drop of additional files and pars straight
into the quickpar window (quicker and easier than using
the add button)

QuickPar 0.8.0.0 does not display file size.

Anonymous — Sun, 29 Feb 2004 04:31:28 -0000

When verifing or using a PAR2 file to validate PAR2 files,
file size is not displayed of PAR2 file's. Even if file size is
100% and green, it should still display file size of par or
par2 file size. If file is not of correct,only then will you
see the amount of blocks and file size.

PAR2 Not Repairing Properly

Peter Doris — Fri, 02 Jan 2004 22:24:22 -0000

When Repairing a PAR2 archive with all the neccessary
pieces, it can sometimes take upwards of 10 attempts to
completely fix the archive, and occasionally won't
repair it at all, even with a valid archive.

Shouldn't the computations allow that one or two times
be sufficant? Also, is there anyway to enable an option
Autorepair until no repair needed, thus negating the
babysitting of the program otherwise?

Combining everything togethor

Anonymous — Thu, 11 Dec 2003 01:46:54 -0000

I know this is QuickPAR & not QuickEverything; but i
would like to know/ ask for .sfv & .md5 file support to be
added to quickpar. I like Quickpar; but i hate to have
more then one program to check my downloads.

many people still post with .sfv and even
occasionally .md5 files. as it is; i have to keep QuickPar,
QuickSFV, and an md5 checker around to handle them.
I, and many others, would greatly appreiciate having all
these things in one interface.

i have tried; and frankly; i'm nowhere near capable of
handling the PAR code. far too much there for my
modest skills.

I thank you for at least listening to this request; and
please; if you know anywhere that this request should
go; i'll be more then happy to take it there.

W.Gwinn@verizon.net

adding just plain .sfv & md5 support

Anonymous — Wed, 10 Dec 2003 14:12:48 -0000

I realise that this doesnt really fall into the scope of
parchive's intent or scope; and would really be suited
more to Quickpar's forum; but as this is the closest i can
find..
many people still post with .sfv and even
occasionally .md5 files. as it is; i have to keep QuickPar,
QuickSFV, and an md5 checker around to handle them.
I, and many others, would greatly appreiciate having all
these things in one interface.

i have tried; and frankly; i'm nowhere near capable of
handling the PAR code. far too much there for my
modest skills.

I thank you for at least listening to this request; and
please; if you know anywhere that this request should
go; i'll be more then happy to take it there.

Usage hints/warnings

Thomas Harold — Sat, 29 Nov 2003 17:23:18 -0000

1) One of the things that it took me a while to figure
out (although I confess to not having read the docs in
depth) is the efficiency value. Mostly because I
didn't figure out that files are boundary-aligned, so
it's a bad idea to have block sizes that are
drastically larger then your average file size.

I think it might be helpful if, when I click on the
"create" button that QuickPar would toss a warning
message (Yes/No/Help) if the efficiency value is going
to be less then 75%. Something to the effect of:
"Warning: You have chosen to create a recovery data set
with a large amount of wasted space. You may wish to
use a smaller block size to reduce this wasted space
and make your recovery set more space efficient." The
user should still be allowed to say "Yep, I'm sure" and
create the set anyway.

A refinement might be to allow the user to set their
pain threshold in the Options dialog (e.g. "Warn me if
wasted space is greater then 25%"), which would double
as a way to turn off the warning.

2) Warn the user if they are creating too many blocks.
I think the heuristic might be that you should
generally not have more then (number_of_files x 10)
blocks in a set. So for a 100 file set, there
shouldn't be more then 1000 blocks.

This might help with the slowness complaints because of
people creating PAR2 sets that take forever on the
destination machines due to large block counts.

Refinement would be to allow an option to tune this
setting... "Warn me if the recovery set has more then X
blocks per file."

Automatic block size pick

Thomas Harold — Sat, 29 Nov 2003 00:30:33 -0000

Right now, there are (3) options for picking the block
size:

1) Exact
2) yEnc
3) UUEncode

What I'm finding is that, depending on the type of data
that I'm archiving off to DVD/CD, I'm constantly
tweaking the block size to balance between efficiency
and having too many blocks. Generally, I make my block
sizes around 1/4 of the average file size, which gives
me efficiencies over 90% usually.

I'd like to see an option added that would
automatically pick a good block size based on what I
have selected. Off-hand, I'd say (average_file_size /
3) or (average_file_size / 4) would be good automatic
values.