also, it should work on any linux, as long as it has the same libraries. avidownload works on my clamshell ppc ibook, my arm ixp nslu2, my x86 tablet, my xbox, and my normal systems. i've -*test*-('")ed it quite a bit. ubuntu, debian, slackware, unslung, openembedded. it just needs the right libraries. Any idea what libraries I would need different from the defaults provided by Ubuntu in order for this to work without my changes? Also, I took the cheap way out - I keep a count of what has actually been downloaded (not the round * 4 bit) then it's simple to print and the computation of the percentage is easy ((count / size) * 100). Haven't figured out the rate thing yet to get it work. Sure wish I knew why all of this works for you but not for me. I would assume whatever it is is also responsible for ops-for-linux failing with the same type of error (read of 0x0fe), and I suspect also why my pv2tool-linux doesn't work either. I even did the permanent unlock on my CVS digicam but pv2tool-linux still won't download anything while Windows does from the exact same camera in the exact same state. I guess an even bigger question would be, if it doesn't work for me, and I use just a plain as delivered version of Ubuntu (both 7.04 and 7.10) as I would assume others do, and I get the errors, shouldn't the other Ubuntu users be getting the same error? How about it - any Ubuntu users out there able to use avidownload and ops-for-linux and/or pv2tool-linux in Ubuntu 7.04 or 7.10? Sorry for the hassles - it just seems that since it didn't work, I make the changes, and it does work, there should hopefully be something I would hope to be easy to track down. What versions of the libraries are you using ? Maybe I can try to check them against the Ubuntu versions. Hopefully nobody changed them for some reason for Ubuntu! :)

all it should rely on is libc, libstdc, libstdc++, and libusb. i think there's an overflow happening in the app, actually. in the logkeyfile subroutine, when it loops through to structure the challenge to output it to the screen, it should loop 32 times <0 - 31>. it loops 33. the loop counts 0 - 30, then 0, then some outlandish number in the hundreds of thousands. to which it prints the erroneous byte of the challenge. transfers work again if the code is once again defaulted to 64 byte transfers, but 4k no more. which makes me think that something internal changed within libusb that now prevents it. i'd like to thank you for bringing this stuff to my attention. i never would have known, considering i haven't gone to an arcade and recorded gameplay in a while. it got me in the groove again. thanks again.

Another twist: tonight I reset the challenge and response sizes back to 128 and reset the loop limiter to < 0x80. It ran fine. I took out the log "debug" lines I put in, and bingo, stack smashing again, but this time it unlocked fine and got to the end of the generate file list function (I put in Log call to show it got to the return true at the end of the function - the Log line is directly before the return) but never gets back to main. I don't understand at all :?

see? it's funky. i'll probably install an older linux system and see what i can get out of it.

Here's a weird question, but how can we determine what parameters were used for the make of gcc and libusb per each distribution. Perhaps something like the stack-smashing checking was enabled where in previous versions maybe it wasn't. I still suspect there is an overflow on one of the strings that ends up clobbering the return address on the stack (hence why it never returns to main). I'm a little curious as to the length of the _VA_ARGS_ variable used in Log. :D

Found something that works, and maybe it makes sense since if there was an overflow it would no longer be on the stack but in regular memory: in function "unlock", change the declaration of challenge and response to static. I still suspect, but haven't been able to trace yet, that one of those ends up with no null terminator but yet is referenced as a string somewhere. But, lacking that trace at this time, it would seem that making them static will keep them off the stack and no longer cause problems. :D

Okay, so I've got this thing working fine for me. It means I do have the ability to download videos from the camcorder in Linux. Now a new question in this saga: what would be required (can it go on the open of the file?) to set the owner of each file created to be the current user, not root? :D

Question about the logkeydump function: you are using string concantenation in the loop where the maximum value could be 127 - what happens when the end of the string (buffer) is not null terminated?

FOUND THE PROBLEM IN UBUNTU!! I checked the /etc/udev/rules.d/40-permissions.rules file and found that USB devices were getting mounted with a default mode of 0664 - hence needing to use super user to access the device! I changed it to a mode of 0666 and it works great now.

huh. mine's 0664. hey, beats me. if it worked for you, sweet. i'll have to make a mental note of that.