Bug Reports against Recent Builds -- Report bugs here

[zincopal]

Well I'm not good to use the forum ...... I want to say <- Back function.
regards

[fe50]

Hi zincopal,
you can also edit your posts, use the "Modify" button in the upper right corner of your post. 

I'm not sure whether i understand you - do you mean the "<- back" entry in the script menu ?
This will only work when you have entered the script menu from within the CHDK menu !
If you enter the script menu directly by pressing SET/FUNC in <Alt> mode, you can leave it with the MENU button (and stay in <Alt> mode) or with PRINT (and leave also <Alt> mode).

[zincopal]

 Hi fe50,
Many thanks fo Your reply, ( You, often peek me out of the troubles and I appreciate Your generosity but I would not impose on You and Your disponibility ) .

The little imperfection is in the  SET/FUNC in <Alt> mode( for the A720 release )
Naturally I know how can solve the little problem,  but I would like that the CHDK should be perfect, the function actually exist and it is a pity that don't work, I hope only that in some next revision when someone not overburned of others interesting modifications found a little time for fix the little bug
Anyway I want to send You again my thanks
Regards

[reyalp]

In both the current trunk and juciphox, on a540
set subject distance override
leave alt mode
enable flash
set mode to auto happens in several modes
press half shoot
-> ui freezes (sometimes all the menus/icons/histogram are shown, sometimes not)
press half shoot again
-> camera shuts down camera shuts down after being hung for a while (watchdog, I assume)

I'll investigate after I get my current work tidied up.

edit:
sometimes shuts down with only one halfshoot.
seems not to happen if zoomed (thx to hacki for the tip, may also affect ixus750)

edit:
appears to be in this loop

Code: C

1. void lens_set_focus_pos(long newpos)
2. {
3.     _MoveFocusLensToDistance((short*)&newpos);
4.     while ((shooting_is_flash_ready()!=1) || (focus_busy));
5.  

It also seems to be somewhat intermittent, possibly related to the subject it is trying to focus on.

Turning off the flash or removing the shooting_is_flash_ready() part appears to make this go away, unless I'm getting caught by the random element.

[fudgey]

It also seems to be somewhat intermittent, possibly related to the subject it is trying to focus on.

Turning off the flash or removing the shooting_is_flash_ready() part appears to make this go away, unless I'm getting caught by the random element.

My first thought is that it's intermittent (also) because flash charging time varies, and that the problem is that CHDK stays in a loop waiting for the flash without letting the camera's software work it's magic, including watchdog resets.

I don't know how often the camera resets its watchdog, so the phase of the reset period could also be a source of variation.

[reyalp]

My first thought is that it's intermittent (also) because flash charging time varies, and that the problem is that CHDK stays in a loop waiting for the flash without letting the camera's software work it's magic, including watchdog resets.

Interestingly, I'm don't need to actually use the flash for this to happen, or even trigger the pre-flash / af assist beam. It does seem like it might depend on subject and/or lighting but I haven't worked out exactly how.

Putting a simple timeout in the loop (get tick count, bail out after 1 second) avoids the shutdown.

I don't know how often the camera resets its watchdog, so the phase of the reset period could also be a source of variation.

Good point. It would be interesting to know when and how the camera watch dog triggers. It's also be nice to make a BSOD sort of thing instead of shutting down

[whoever]

It's an age-old bug. The condition occurs if you (i) set flash to Auto, (ii) set some exposure parameter override, and (iii) shoot in bright light, so that the flash is not used. Then the following function

int shooting_is_flash_ready()
{
   int t = 0;
   _GetPropertyCase(PROPCASE_FLASH_MODE, &t, sizeof(&t));
   if ((t != 2) && (shooting_in_progress()))
    return (shooting_is_flash() && _IsStrobeChargeCompleted());
   return 1;
}

returns 0, so that the loop

    while ((shooting_is_flash_ready()!=1) || (focus_busy));

becomes infinite and hangs CaptSeqTask. Then, after 10s or so, the watchdog kicks in.

Correcting, instead of
   if ((t != 2) && (shooting_in_progress()))
    return (shooting_is_flash() && _IsStrobeChargeCompleted());
one should say
   if ((t != 2) && (shooting_in_progress()))
     if (shooting_is_flash()) return _IsStrobeChargeCompleted();

[PhyrePhoX]

hm, so this behaviour should occur on all cameras, right?
will do some tests tonight.
this fix of yours, is it considered to be safe and not breaking anything? if yes (perhaps some people can do tests) i can patch the trunk and the branch. right?

[whoever]

hm, so this behaviour should occur on all cameras, right?

I should believe so. I'm surprised nobody except reyalp complained yet. Scared perhaps...

will do some tests tonight.
this fix of yours, is it considered to be safe and not breaking anything? if yes (perhaps some people can do tests) i can patch the trunk and the branch. right?

In my understanding it's a safety fix, not break. Testing never hurts though...

[whim]

Suggestion to eliminate unnecessary compiler warnings (juciphox 479, all cams):

ubasic.c: In function `case_statement':
ubasic.c:830: warning: 'gosub_ln' might be used uninitialized in this function
ubasic.c: In function `case_else_statement':
ubasic.c:919: warning: 'gosub_ln' might be used uninitialized in this function
kbd.c: In function `kbd_process':
kbd.c:565: warning: 'drmode' might be used uninitialized in this function

these 3 are all no-brainers: all 3 are in the initial declarations after the
function headers, so gcc will initialise them to 0 anyway, won't it ?
just add '= 0' and presto

lmathlib.c: In function `math_pow':
lmathlib.c:118: warning: implicit declaration of function `luai_ipow'

'lmathlib.c' needs to declare `luai_ipow' an external function,
because it is defined in 'lvm.c'
I tried, but couldn't get it done, all his recursive macroing in the LUA
sources kinda baffles me - the price of portability, i guess ...
should be easy for some of you, though 

IMHO with these changes all cams that have 0 errors/warning in trunk would do
so in juciphox as well

wim

[reyalp]

Correcting, instead of
   if ((t != 2) && (shooting_in_progress()))
    return (shooting_is_flash() && _IsStrobeChargeCompleted());
one should say
   if ((t != 2) && (shooting_in_progress()))
     if (shooting_is_flash()) return _IsStrobeChargeCompleted();

Oh that makes sense. I'm embarrassed to say I looked at that a couple times and didn't notice

[whoever]

Oh that makes sense. I'm embarrassed to say I looked at that a couple times and didn't notice

In which case would somebody rectify, please. And while at it, perhaps also remove the few unhelpful lines in that same function.

[whoever]

Well, one more little fix for the trunk. A brief click on the "Alt" button is supposed to invoke/dismiss the alt-menu. Well, invoke it does, but on the way out "Alt" remains clicked, so if there's a regular function on that button, it gets invoked whenever exiting the alt-menu. A simple fix takes just a few lines in core/kbd.c, namely instead of

   if ((key_pressed == 2) && !kbd_is_key_pressed(conf.alt_mode_button)){
       key_pressed = 0;
   }

say

   if (key_pressed == 2) {
     if (kbd_is_key_pressed(conf.alt_mode_button))
       return 1;   // wait until Alt released before unblocking kbd
     else
       key_pressed = 0;
   }

[fudgey]

Well, one more little fix for the trunk. A brief click on the "Alt" button is supposed to invoke/dismiss the alt-menu. Well, invoke it does, but on the way out "Alt" remains clicked, so if there's a regular function on that button, it gets invoked whenever exiting the alt-menu. A simple fix takes just a few lines in core/kbd.c, namely instead of

Sounds like fix #7 in My modifications to CHDK, already in juciphox since #417. I use a (bit old by now) trunk build with some patches including ljl's zebra and cyril42e's alt fix and both work well. Your modification is suspiciously lot simpler, though...

[whoever]

Sounds like fix #7 in My modifications to CHDK, already in juciphox since #417. I use a (bit old by now) trunk build with some patches including ljl's zebra and cyril42e's alt fix and both work well. Your modification is suspiciously lot simpler, though...

Could be. I was talking about the trunk not branches though. I hope it will remain the source reference, while branches will remain such.