Quote "You are only shooting jpeg correct ?"
Yes, they are 1M JPGs ... small to help isolate the problem. I wait long enough until everything on the camera LCD settles and is ready for the next shot before I allow dcimdl() to execute ... roughly 2s after myshoot, so I give it 4s to be sure. I think that's not the problem ... only that w/o the sleep it occurs much more frequently.
Quote "If it always stops at exactly 37 now, maybe there is some other problem."
No it doesn't ... see below, with ROMLOG etc.
Quote "Given that you had a lot of crashes while the camera was writing files, it's possible your filesystem got messed up."
No, that's not the case. I make sure the sleep in front of dcimdl is long enough to put the camera state into "I am ready for the next shot." So definitely not while the SD is written. I did another similar test -- see below.
Quote "Another thing you could try to do is work out exactly which call it crashes on. You could also try eliminating different parts (e.g. don't download, just delete, or don't delete, just download)"
I could try that but as I am discovering more and more, the crashes randomly occur anywhere in listdir, mdl, rm, except shoot ... shoot always works. So for example if I knock out mdl and rm, I expect it will occur expect less often (go on for more successful myshoots).
Here is my understanding and insight I can presently offer:
#1 - I peppered dcimdl with 200ms sleeps (a very honest and real hack because fundamentally I have no idea what I'm doing) and the highest number of myshoots in a row I got was 40 // in effect, no difference.
#2 - The failure could happen during any of the three calls inside dcimdl() -- I certain now it's random, and even less related to the long sleep. Your shoot in myshoot has not failed.
#3 - I had a case yesterday where turning camera ON (with empty DCIM) and pressing PLAY/REC gave me the dead condition with the usual ptp error.
#4 - I restored the functional condition.
#5 - I figured this ...... the only asynchronous event I know that could interfere of is liveview. Liveview on the SX110 bench is 2.7 to 3 fps. I have had liveview running by itself overnight on the SX110 w/o a problem. So I set fps to 1, and I could see the slow transfer for a few frames. I left the bench unattended for a couple of minutes and came back to a dead system. There was *no* ptp error, in fact no message at all anywhere ... as if everything had frozen in time. Very strange.
#6 - After PDN/PUP, Connect, save ROM_7 attached for the above, REC mode, and no freeze for at least 10 minutes // OK.
#7 - My hypothesis, and hope, was to observe a statistical increase in the number of myshoots. So at 1 fps the first fail was at 7 myshoots, and the second fail was at 39 // in essence no difference.
#8 - The next step I restored the faster frame rate and increased the peppered sleeps in dcimdl: 0.4s, 1s (in addtion to 4s before dcimdl).
#9 - Again no difference .... but ..... look what noticed in the Fig 1 (next post) .. a sudden drop to 20K max block. That myshoot worked, but failed on the next attempt.
#10 - I reset the liveview to 3 fps and noticed a similar effect before failure, Fig 2 next post. So there may *in fact* be something related to malloc() which is transient and occurs randomly affecting only the functions in dcimdl ??
Q1. Does listdir return after it has delivered the goods?
Q2. Does mdl return only after it has delivered the goods?
I hope this helps. A tiny thing I never expected but showstopper. I am getting a little worried and willing to put more elbow grease to resolve it. Other than what you already suggested, how can we look deeper into the fail event? Another kind of debug code? elsewhere?
See next post for more attachments.
