Quote "This means that you are in the semi-alt mode I've described several times before. "
I recall asking you only once about getting CHDK menus to work again. You told me to push Alt a few times. I did not know this was also related to Canon buttons, and yes it works. Thanks. I am still learning, please be patient.
Quote "Assuming this "leak" is actually normal firmware behavior (which appears likely at this point), there's really very little alternative."
Although I could not confirm the above with a good test because the menu got stuck, sadly, I am concluding the same."
Quote "The most plausible approach would seem to be suppressing the file creation step completely, and downloading the data over USB."
That's how Canon's RemoteCapture works is why I haven't seen any issues in transfers of tens of thousands of files between scheduled maintenance intervals. This would be the best and correct solution.
Quote "Although I haven't tested yet, I expect srsa's remote capture system will not prevent this "leak", since it gets the data in the file write task, and still creates "ghost" files in the Canon UI."
Hmmmm, too bad // seems so. But ...... assuming "Canon UI" in this case must be the SD card, hence I am guessing what srsa is doing may be something like the following (CHDK RAWs notwithstanding) ....
a) shoot
b) instruct Canon to create file (or file pair) on SD with a new arbitrary file sequence number;
c) transfer the file (or file pair) to CHDKPTP;
d) delete the file (or file pair) from SD;
e) decrement the file counter in the camera;
f) increment a local CHDKPTP file sequence counter based on the last file number currently present in the target PC directory (Canon does Capture_NNNNN, ie five not four Ns);
g) save the file in the PC.
This sound generally right to you? This mechanism would preserve files already on the SD unaltered (what Canon RemoteCapture does too). It's not useful for me but I can see it has general use for photographers. There are two failure modes that have surfaced in this work over the last few weeks: post-shoot delay related and memory leak related. Given the limitations of Canon heap management, I think overall it is a good result and gives us some assurances and new knowledge. Sure, according to how you explain it here, we would quite definitely not see improvement on the memory leak. However ... if srsa can implement the "write-detect" hold-off in (a), then that would be a major improvement in my view. Why? Couple of reasons: 1) it would prevent random failures when the post-shoot delay is not worked out by the user for the worst-case in a specific hardware configuration (good for general use, not just me), leaving the memory leak to be handled externally by the user, and 2) leak-related failures can be made predictable and mitigated (reboot). For example, the srsa mechanism can sniff memory and simply report freemem to box on the GUI. It could be a bit more sophisticated, and allow user-settable warning threshold to turn ON a red LED on the CHDKPTP GUI when memory is getting dangerously low (reboot).
Also ...... could you use his write-detect holdoff in your shoot ?
What do you say?