Closed GoogleCodeExporter closed 9 years ago
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
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
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
Same question: Could you post all the parameters, please?
Original comment by eduardo....@gmail.com
on 26 Mar 2012 at 8:56
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
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
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
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
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
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
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
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
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
Issue 242 has been merged into this issue.
Original comment by eduardo....@gmail.com
on 6 May 2012 at 5:36
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:
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:
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:
Original comment by eduardo....@gmail.com
on 7 May 2012 at 3:48
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
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:
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
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
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:
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
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:
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
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
>> 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
> 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
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
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:
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
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
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:
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
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:
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:
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
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
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
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
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
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
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
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
> 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
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:
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
Original comment by eduardo....@gmail.com
on 1 Dec 2012 at 10:59
Original issue reported on code.google.com by
kredittk...@gmail.com
on 4 Mar 2012 at 5:52