Camera freezes during intervalometer execution

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Intervalometer started with hand
2. after 150-200 shots camera freezes
3. unable to turn off, must remove batteries.

What is the expected output? What do you see instead?

As the camera is frozen the blue light in print button is still blinking as 
normal during interval shooting and the LCD screen is on, but no buttons work 
including on/off.

What version of the product are you using?

400plus-20111111-3

Please provide any additional information below.

If there is a possibility to debug og log the error I can try to do so, but I 
don't know any way of doing it. I will try different approaches and see if I 
can narrow the fault down a bit.

Original issue reported on code.google.com by kredittk...@gmail.com on 4 Mar 2012 at 5:52

[GoogleCodeExporter]

Is this reproducible? Or just happened once?
Could you post all the parameters, please?

The debugging facilities are in the "developers' menu", but you must enable it 
from the "settings menu". Blue led keeps blinking because we use a separate 
thread to make it blink; if the camera locks, out main thread locks too, 
waiting for the camera, but not the other one.

Original comment by eduardo....@gmail.com on 4 Mar 2012 at 7:40

[GoogleCodeExporter]

Could this be the result of the card getting full? We currently do not check 
for this condition, and 400plus could wait endlessly for the camera to be ready 
to shot. 

On the other hand, I made some changes to the intervalometer recently; could 
you please try again with the latest nightly build? Many thanks.

Original comment by eduardo....@gmail.com on 15 Mar 2012 at 8:59

• Changed state: Started

[GoogleCodeExporter]

I also have this issue! It happens every time. I will turn on the debugger next 
time

Original comment by Daniel.D...@gmail.com on 26 Mar 2012 at 8:14

[GoogleCodeExporter]

Same question: Could you post all the parameters, please?

Original comment by eduardo....@gmail.com on 26 Mar 2012 at 8:56

[GoogleCodeExporter]

This (and issue #207, which I just merged into this one) is probably caused by 
AutoISO (even if it is set to "Off"):

* We have two ENQUEUE_TASK, in the intercom_proxy, related to AutoISO (one at 
IC_MEASURING and another one at IC_MEASUREMENT).
* Both events may happen while a script is running; in fact, they probably 
happen at least once before each shot.
* But when a script is running, out task_dispatcher is executing the script, 
and thus not listening to the task_queue.
* And if the task_queue fills, intercom_proxy locks trying to push new 
messages, and the camera freezes.

NOTE: I'm figuring this out just by looking at the source code, so probably 
everything I wrote is plainly wrong; but did not want to forget it by the time 
I get home, and decided to write it down somewhere.

Original comment by eduardo....@gmail.com on 2 Apr 2012 at 6:27

[GoogleCodeExporter]

Actually makes sense. Hope this is the cause of the problem, otherwise it would 
be a nasty bug, not easy to catch it.
(and sorry for not seeing the already started issue)

Original comment by fired...@gmail.com on 2 Apr 2012 at 7:20

[GoogleCodeExporter]

Right okay, is there anything else I can do or shall I just sit tight until 
you've figure it out? 

Original comment by ASUllr...@gmail.com on 2 Apr 2012 at 11:53

[GoogleCodeExporter]

No, right now we do not need any more tests or info; please, just wait until we 
have it fixed. Many thanks!

Original comment by eduardo....@gmail.com on 2 Apr 2012 at 1:33

[GoogleCodeExporter]

ENQUEUE_TASK is a call to TryPostMessageQueue with FALSE as the "forever" 
parameter; even it our task_dispatcher is busy running a script and the queue 
fills, intercom_proxy will never block... back to the drawing board.

Original comment by eduardo....@gmail.com on 2 Apr 2012 at 9:34

[GoogleCodeExporter]

My camera has been executing an intervalometer for more than two hours, and is 
still running. This does not seem to be something that always happen, and I'll 
need more info about when it happens to be able to debug it.

Original comment by eduardo....@gmail.com on 3 Apr 2012 at 9:03

[GoogleCodeExporter]

okay, long exposures 30" lasts an hour and 10 minutes maybe. but then i did 
another series that was 1" exposures and that failed after 1 hour. could it be 
to do with it the fact that there was no time inbetween shots?

Original comment by ASUllr...@gmail.com on 3 Apr 2012 at 9:31

[GoogleCodeExporter]

No, I cannot think of any reason why having no time between shots could have an 
effect here: there is _always_ some time between shots, we added a small pause 
precisely to be safe. But it is something worth investigating, thanks; I will 
repeat my tests and report back.

Original comment by eduardo....@gmail.com on 4 Apr 2012 at 6:48

[GoogleCodeExporter]

I just did another test: 30-second exposures, no pause between shots... two 
hours of continuous shooting, and still going. Sorry guys, but if I cannot 
reproduce it, I cannot fix it.

Original comment by eduardo....@gmail.com on 12 Apr 2012 at 1:21

[GoogleCodeExporter]

Issue 242 has been merged into this issue.

Original comment by eduardo....@gmail.com on 6 May 2012 at 5:36

[GoogleCodeExporter]

I still cannot reproduce this issue, but another user reported the same 
problem. I have prepared a modified 20120415-6, with additional debug 
information; please, follow these instructions to help me find the source of 
the problem:

* Install the attached AUTOEXEC.BIN file.
* Switch camera on and configure the intervalometer script (configure the EAEB 
script too, if you plan to use it).
* Go to the settings page, and activate the developers' menu.
* Press the TRASH button to enter the developers' menu.
* Set "Debug on PowerOn" to "Yes" and "Log File Mode" to "Overwrite".
* Switch camera off and back on (camera should beep, and the red LED will flash 
more than the habitual).
* Launch the intervalometer script, and wait until it fails.
* Card should contain now a "DEBUG.LOG" file; please attach it to this issue.

Many thanks!

Original comment by eduardo....@gmail.com on 6 May 2012 at 5:44

Attachments:

• AUTOEXEC.BIN

[GoogleCodeExporter]

This time there was no ERR 99, it just stopped with "BUSY" on the screen. I 
left it for a while, but it didn't seem keen to carry on.

I was shooting with the intervalometer set to trigger the EAEB script. Earlier 
today I did a timelapse for around four hours with just the intervalometer and 
that didn't lock up. I will run this again and attach another log file, for 
consistency :)

Original comment by laurence...@gmail.com on 6 May 2012 at 6:51

Attachments:

• DEBUG.LOG

[GoogleCodeExporter]

And the second crash :) Took much longer this time so the file is much bigger. 

Original comment by laurence...@gmail.com on 6 May 2012 at 7:52

Attachments:

• DEBUG.LOG

[GoogleCodeExporter]

Original comment by eduardo....@gmail.com on 7 May 2012 at 3:48

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I set the camera to P mode, and configured EAEB for 5 shots with 1EV 
separation; then the intervalometer for 5 EAEB sequences, with 1s separation 
between them. Whenever the buffer fills, and the camera displays the BUSY 
message, I get one correct frame at EV0 and two (instead of four) frames at 30s.

Still could not reproduce the issue; but obviously, not what I expected...

Original comment by eduardo....@gmail.com on 7 May 2012 at 5:50

[GoogleCodeExporter]

I've been working in this issue; as I commented somewhere else, this has top 
priority for me.

The attached version improves the stability of scripts, specially when lots of 
photographs are taken in burst mode. In my tests, it hasn't locked once, nor 
has repeated the problem explained in my previous comment. I'll leave this here 
for a couple of days; and, if nobody complaints, will release it as 20120415-7.

Thanks!

Original comment by eduardo....@gmail.com on 10 May 2012 at 9:04

Attachments:

• AUTOEXEC.BIN

[GoogleCodeExporter]

I've just released 20121415-7, that contains the same code as in comment 20, 
plus a fix for an unrelated bug in the EAEB script. If someone still 
experiences camera freezes while executing scripts, please save your camera 
settings as a preset and post it here, so I can reproduce the issue. If nobody 
complaints in a couple of days, I'll consider the issue solved. Many thanks.

Original comment by eduardo....@gmail.com on 13 May 2012 at 9:32

[GoogleCodeExporter]

Thanks for all your hard work. I've been away from home for a week, back on 
Wednesday, so will give it a good testing when I get back :) 

Original comment by laurence...@gmail.com on 14 May 2012 at 11:36

[GoogleCodeExporter]

I've tested 20121415-7 now and it seems to have the same problem. "P" mode with 
image size set to small (to help save memory writes). Intervalometer, every 3 
seconds, set to trigger the EAEB script with three exposures at +/- 2. I also 
have the camera set to Manual Focus so the lens is not refocusing every shot. 
ISO 400. I put it into debug mode as previously described and attach the log. 
If there is anything else you would like me to do, or other tests to run, 
please let me know.

Original comment by laurence...@gmail.com on 19 May 2012 at 7:40

Attachments:

• DEBUG.LOG

[GoogleCodeExporter]

Ok, I have the same problem. It has happened to me twice so far. On Saturday I 
made a timelapse and it stopped working when I have only 53 photographs. By 
then I thought it was a battery issue, but I've tried to reproduce the error 
again, and I did it with only 14. The exposure time is different in both 
situations (45 and 120 seconds), only a second between shots... and now I'm 
trying to debug it. 

Original comment by siri...@gmail.com on 28 May 2012 at 12:10

[GoogleCodeExporter]

Well, I was about to give up trying to reproduce the issue, but finally I got 
it. 

This was made with the following configuration:
- P mode
- Exposure: 1 minute
- Interval: 1 second
- ISO 800
- RAW

My previous attempt was made in M mode.

Original comment by siri...@gmail.com on 28 May 2012 at 5:45

Attachments:

• DEBUG.LOG

[GoogleCodeExporter]

I promise I'll get back to this as soon as possible; as I wrote before, this 
bug has top priority for me.

In the meantime, one question about comment #25: how can you have 1-minute 
exposures in P mode? Also, notice that intervals shorter than the exposure time 
do not make sense on the last version (basically, the interval time is now the 
time between the start of each shot).

Many thanks for your patience and help!

Original comment by eduardo....@gmail.com on 29 May 2012 at 8:15

[GoogleCodeExporter]

Thanks four your effort Eduardo ;)

> how can you have 1-minute exposures in P mode?

Well, easy question. I just put P Mode and in "!Long Exposures" I set it to 1 
minute. That's it. I thought I had to put it in Manual Mode, but then I just 
found out it wasn't needed. But the first time my camera got frozen was in M 
mode.

> Also, notice that intervals shorter than the exposure time do not make sense 
on the last version (basically, the interval time is now the time between the 
start of each shot).

What? I don't think so, at least in my camera, "time" in "intervalometer" is 
the time between shots.

Original comment by siri...@gmail.com on 29 May 2012 at 8:54

[GoogleCodeExporter]

>> how can you have 1-minute exposures in P mode?

> Well, easy question. I just put P Mode and in "!Long Exposures" I set it to 1 
minute. That's it. I thought I had to put it in Manual Mode, but then I just 
found out it wasn't needed. But the first time my camera got frozen was in M 
mode.

Are you using the intervalometer plus the long exposure script? Then you are 
shooting in M mode: the script changes the mode before each shot; IMHO, you 
should consider moving to M mode altogether, or the aperture could get random 
values.

>> Also, notice that intervals shorter than the exposure time do not make sense 
on the last version (basically, the interval time is now the time between the 
start of each shot).

> What? I don't think so, at least in my camera, "time" in "intervalometer" is 
the time between shots.

Have a look at the user guide: 
http://code.google.com/p/400plus/wiki/UserGuide#Strict_scheduling. At the end, 
with 1-minute exposures and 1-second intervals there is no practical 
difference; but try to set a longer interval (2 minutes, for example), and see 
what happens.

Original comment by eduardo....@gmail.com on 29 May 2012 at 9:10

[GoogleCodeExporter]

> Are you using the intervalometer plus the long exposure script?

Yes! I was in M mode then. 

> Have a look at the user guide: 
http://code.google.com/p/400plus/wiki/UserGuide#Strict_scheduling. At the end, 
with 1-minute exposures and 1-second intervals there is no practical 
difference; but try to set a longer interval (2 minutes, for example), and see 
what happens.

Thank you, I didn't know that, I'm going to take a look at the user guide to 
clear this things up :)

Thanks, and if you need me to test my camera, tell me and I'll do it.

Original comment by siri...@gmail.com on 29 May 2012 at 9:30

[GoogleCodeExporter]

By the way, is it possible to set long exposures of 35 and 40 seconds? Well... 
in my timelapses it'd be nice to have these options :)

Original comment by siri...@gmail.com on 29 May 2012 at 11:21

[GoogleCodeExporter]

Some possible explanation...

* When the camera is not in M mode, some scripts must change to M mode 
internally, in order to work properly
* Each time the camera changes modes, we must update the main dialog, to add 
some non-standard icons (spot-metering, for example).
* If the review mode is not set to "Off", the main dialog will appear after 
each shot.
* So, whenever the script changes to M mode, we end updating the main dialog
* It could happen that we are not fast enough updating the dialog, and by the 
time we try to redraw it, the script has already fired the next shot.
* There is no dialog displayed while a shot is being taken.. so the camera 
hangs because we redraw a non-existing dialog.

The attached version simply does not update the main dialog at all, while a 
script is running; it has the side effect that some enhancements (spot 
metering, ...) will not show during a script, but everything else should work 
as before (it's just the display not being updated, nothing else). I'll try to 
do more tests tomorrow, but so far I have not been able to reproduce the issue 
with this version.

Original comment by eduardo....@gmail.com on 30 May 2012 at 9:21

Attachments:

• AUTOEXEC.BIN

[GoogleCodeExporter]

Thank you very much, but my first error happened in Manual Mode, and I think 
that the display was off when I was making my timelapse. However, I'll try this 
new file tomorrow ;)

Thanks for you work.

Original comment by siri...@gmail.com on 30 May 2012 at 11:29

[GoogleCodeExporter]

If you manage to lock the camera, please restart it and save the configuration 
as a preset, then post the file from the card here. Right now, knowing the 
exact values for all the parameters that trigger the bug is more useful to me 
than obtaining the log. Many thanks!

Original comment by eduardo....@gmail.com on 31 May 2012 at 6:39

[GoogleCodeExporter]

Ok, done it. It was fast this time. 

Manual Mode, Bulb, F.5.6, 100ISO, RAW, 45 sec. exposure, 48 sec. between photos.

And I send you the preset and debug files ;)

Original comment by siri...@gmail.com on 31 May 2012 at 5:00

Attachments:

• PRESET_2
• DEBUG.LOG

[GoogleCodeExporter]

Yep, the latest version locks up for me very quickly too :) Preset attached!

Original comment by laurence...@gmail.com on 3 Jun 2012 at 1:55

Attachments:

• PRESET_1

[GoogleCodeExporter]

I just released 20120415-8.

It contains a bypass (not the real fix, but it will do) for some cases:
 * Intervalometer plus long exposure.
 * Intervalometer plus EAEB in M mode.

Using the intervalometer plus EAEB in P, Tv, and Av is still unreliable; other 
uses of the intervalometer should be stable, on the other hand.

Hope this helps.

Original comment by eduardo....@gmail.com on 5 Jun 2012 at 3:41

[GoogleCodeExporter]

I just tried 20120415-8 in M mode for an intervalometer + EAEB shoot, and it 
gave me an err 99 after about 50 intervals. This is shooting in "S" JPG mode to 
minimise file size (and thus writes), manual focus, "M" on the dial. 
Intervalometer set to 2 second gap, EAEB set to take three shots, at +/- 2 
stops. I attach the debug.log from the second run, where the camera froze up 
very quickly.

Original comment by laurence...@gmail.com on 6 Jun 2012 at 4:29

Attachments:

• DEBUG.LOG

[GoogleCodeExporter]

Even if I have been silent for some time, I'm still working in this issue; 
unfortunately, I haven't still found the real solution to this bug. It all 
seems to be caused by us sending commands to the camera too quickly, but all my 
attempts to properly synchronize our scripts with the camera have failed. I 
have been tempted to throw the towel so many times... 

I'd like to try a different approach now, and just add some fixed time between 
shots (ideally, this idle time should be as short as possible, so we can fire 
as fast as possible; but I prefer a slow camera to a dead camera). This version 
adds 250ms before each shot, even if the camera seems ready to go; the EAEB 
will be noticeably slower, and the intervalometer will be slower too, but only 
with short interval times.

It seems to be rock solid for me, but you will surely bring some real-world 
tests to the table, and spoil all the fun. If this fails, I'll buy a hammer, 
and then a new camera.

Original comment by eduardo....@gmail.com on 28 Jun 2012 at 9:44

Attachments:

• AUTOEXEC.BIN

[GoogleCodeExporter]

Hey Eduardo - very much appreciate the work you put in to bring unexpected 
functionality to the camera :D I've been running an intervalometer EAEB script 
for over an hour now with a 2 second interval on three bracketed shots, and 
it's been powering away happily in "M" mode. I'm going to leave it going until 
the battery goes flat - that should be enough of a test for me to be happy :D 
Otherwise - looking good so far - will report back as I go :D

Original comment by laurence...@gmail.com on 29 Jun 2012 at 1:44

[GoogleCodeExporter]

Ok, it finally locked up after taking around 2100 shots. I think it overheated 
if I'm honest ;)

Original comment by laurence...@gmail.com on 29 Jun 2012 at 4:45

[GoogleCodeExporter]

Three shots every two seconds is almost a constant burst mode... you guys 
surely like to stress the machine! Just out of curiosity: did it show a 
"ERR-99" or just became unresponsive?

Anyway, it looks like an improvement; I'll do a release right now.

Original comment by eduardo....@gmail.com on 29 Jun 2012 at 9:29

[GoogleCodeExporter]

It showed an err99 code the first time, then after when I tried to restart the 
shooting it became unresponsive after a number of frames, which made me think 
it was just overworked :) I guess the use case isn't very common! But in case 
you were wondering, this is what I made to test it: 
https://www.youtube.com/watch?v=R0yBsIsRCm0

Original comment by laurence...@gmail.com on 30 Jun 2012 at 9:25

[GoogleCodeExporter]

Nice video, very interesting!
Usually, ERR-99 means we tried to shot too soon, and the camera wasn't still 
ready, while the locks happen when we send other commands too soon.
I'll leave the issue open, and hope that someday we will be able to fix this 
for real, but I'll carry on with other features for a while.

Original comment by eduardo....@gmail.com on 1 Jul 2012 at 6:28

[GoogleCodeExporter]

I have experienced the camera freezing while running intervalometer several 
times - however i assumed it was caused by low battery. sometimes it happened 
when there was still apparently power left in the battery, but the behaviour 
seemed identical to when the battery was genuinely going flat. is it possible 
that these issues are all actually power supply / battery issues? 

Original comment by purest...@gmail.com on 12 Aug 2012 at 9:46

[GoogleCodeExporter]

I must confess I never tried to see what happens if a script is running while 
the camera runs out of battery; but I am pretty sure that firing the shutter 
too fast from within a script does lock the camera, even with full batteries.

Original comment by eduardo....@gmail.com on 12 Aug 2012 at 5:23

[GoogleCodeExporter]

used the Intervalometer script several times while on holiday (I forgot my 
actual Intervalometer) - and every single time I used it, it ended with the 
camera frozen. (and it was not battery issues)

Normally it would freeze when the light levels changed, ie: when someone walked 
infront of the camera blocking out the sun, or at night when a car went past 
and lit up the frame with the headlights. (this could have been co-incidence i 
guess)

is it possible that if the camera is adjusting its exposure at the same time 
that a shot is fired then this somehow causes the issue?

I did do a little test just now, switching the lights on and off with the 
intervalometer running.

results:
   av mode: (camera froze after 11 frames)
 manual mode: (camera ran for 200+ frames without freezing).

however I tried to repeat the test and the camera did not freeze... what mode 
have other people had the camera in when it has frozen?

Original comment by purest...@gmail.com on 25 Sep 2012 at 4:24

[GoogleCodeExporter]

> is it possible that if the camera is adjusting its exposure at the same time 
that a shot is fired then this somehow causes the issue?

Yes, that sounds very reasonable; thanks for the info!

Original comment by eduardo....@gmail.com on 25 Sep 2012 at 7:26

[GoogleCodeExporter]

Despite the lack of activity around here recently, this is still my "favourite" 
bug. As many times before, I think I have finally nailed it...

Attached version removes all the extra delays added in 20120415-11, and the 
camera can now fire shots very quickly again; but I also added some code to 
wait for the camera in some specific places, trying to avoid any lock.

This version has passed all my torture tests with flying colours. I'll just 
leave it here for a while, I'm sure you'll soon find a way to make it fail 
again; otherwise, I'll make it into a new release.

Original comment by eduardo....@gmail.com on 12 Nov 2012 at 10:54

Attachments:

• AUTOEXEC.BIN

[GoogleCodeExporter]

Released as 20120415-15; will wait some days more, and then close the issue.

Original comment by eduardo....@gmail.com on 23 Nov 2012 at 9:08

[GoogleCodeExporter]

Original comment by eduardo....@gmail.com on 1 Dec 2012 at 10:59

• Changed state: Fixed