Thanks. I did some testing (average photo size 1.7 Mb ).
Again, the size of the photos is irrelevant. The actual transmission is done in chunks whose size is based on free RAM. Where you are running out is the code that builds the list of files and returns it to the PC.
Unfortunately, the current CHDK code for dealing with directories must list the entire directory, rather than reading each file name in turn and processing it, so the number of files will always have an impact.
Memory must be quite low on this camera to be running into this problem, can you post the output of
!return con:execwait('return get_meminfo()')
You can use CHDKshell to build a copy of CHDK that has some optional features turned off to get more free memory. Using the (unstable) trunk version should also give you quite a bit more free memory.
If you are running out of memory with a batchsize of 5, you are probably quite close to the limit and risk failing in other situations too. Or something else is going wrong...
I notice no big difference in download speed between the default 20 and 4. Are there any other drawbacks to having a lower batchsize value? If it affects (slows down) other commands then I could use a special copy of chdkptp with lower batchsize only for downloading.
No, there should be no other impact. I've optimized the chdkptp message wait functions since I implemented batching so maybe it isn't so important now. Anyway, the change I gave you only affects the multi-file operations (mdownload and mdelete).