CHDK for longtime timelapse

Caefix

947
Sorry, busy deleting test shots...

Re: CHDK for longtime timelapse

« Reply #80 on: 27 / October / 2021, 11:48:23 »

Advertisements

Quote

It would be much more helpful to explain the idea than a complicated script.

Maybe, I´ll try.

DT´s workflow seems shoot(), copy pic to PC, delete=replace with 0Byte filedummy on SD.

So it has still an entry in filesystem and the tables Canon wants to index/synchronize after reboot().
My hope is that erasing .JPG [&.CRW] with scripted buttons pantomiming manually deleting aviods that, so only last one or two files remain on card/ in cam´s memory.

That needs several seconds, needs to be fitted to the interval timing.
The script is more to adjust/confirm the camspecific stuff, the key to enter "delete menu" and the sleeps cam needs to update display & it´s secret bureaucracy...

Btw. Lens retraction time should be set to 1 min.

Edit2:

Code: [Select]

luar set_record(0) sleep(1000) wheel_left() sleep(1000) click("erase") sleep(500) click("right") sleep(500) click("set") sleep(1000) set_record(1) sleep(1000) shoot()

wheel_left() is optional, the (remaining) files counter keeps constant, "handels" too?

No "unidentified image".
Edit3:

... same line even shorter ...

Code: [Select]

luar function c(k,s) click(k) sleep(s*100) end set_record(0) sleep(1000) c("left",10) c("erase",5) c("right",5) c("set",10) set_record(1) sleep(1000) shoot()

Edit:

Quote from: reyalp on 26 / October / 2021, 21:31:01

Quote from: dolomiti_timelapse on 26 / October / 2021, 09:11:25
It took me over one hour to write this post. Then I wanted to post it. Then I was logged out and the hole message was gone :'( very frustrating!
Yes, it is, and it happens even with the "always stay logged in option" caefix mentioned. It's happened to me enough that I try to copy my post to clipboard before posting, but sometimes I still forget

OOpss. Our internet connection is often quite weak or broken for hours, posting to digital nirvana

, so
mostly I write my postings in npp++ as a .Lua file because of highlighting syntax, and finish the laylout with the attachments. Usually copy to clipboard, too. [/code]

« Last Edit: 28 / October / 2021, 16:05:02 by Caefix »

Logged

All lifetime is a loan from eternity.

dolomiti_timelapse

96

Re: CHDK for longtime timelapse

« Reply #81 on: 06 / November / 2021, 08:42:50 »

Quote from: Caefix on 27 / October / 2021, 11:48:23

DT´s workflow seems shoot(), copy pic to PC, delete=replace with 0Byte filedummy on SD.
So it has still an entry in filesystem and the tables Canon wants to index/synchronize after reboot().
My hope is that erasing .JPG [&.CRW] with scripted buttons pantomiming manually deleting aviods that, so only last one or two files remain on card/ in cam´s memory.
That needs several seconds, needs to be fitted to the interval timing.
The script is more to adjust/confirm the camspecific stuff, the key to enter "delete menu" and the sleeps cam needs to update display & it´s secret bureaucracy...
Btw. Lens retraction time should be set to 1 min.

Edit2:
Code: [Select]
luar set_record(0) sleep(1000) wheel_left() sleep(1000) click("erase") sleep(500) click("right") sleep(500) click("set") sleep(1000) set_record(1) sleep(1000) shoot()wheel_left() is optional, the (remaining) files counter keeps constant, "handels" too? No "unidentified image".
Edit3: ... same line even shorter ...
Code: [Select]
luar function c(k,s) click(k) sleep(s*100) end set_record(0) sleep(1000) c("left",10) c("erase",5) c("right",5) c("set",10) set_record(1) sleep(1000) shoot()

Thank you, Caefix, for your answer. It is still little bit to cryptic for my understanding.

What I do is running the rawopint script via chdkptp remoteshoot command with a dummy modification which means, for each photo taken a dummy is been created. I'm not sure if the shoot is been send directly to the PC or first saved to sd card than send to pc and than deleted and replaced by a dummy file?!

I don't know if it makes sense to replace the photo whit a dummy but I actually also don't know it this is the case, that the photo is saved before on sd card?.
I understand your approach to delete one single photo with the code shown above.
So you suggest to implement this code in the rawopint script and change between each shoot to playback mode and delete the photo?
As far as I know, in the night the exposure is up to 13 seconds, so there is no time left for changing to playback mode within 15sec of total interval between each shoot.

For me a simple and sufficient approach would be to delete all dummy files at the end of the timelapse.

Thank you for the hint to use n++

Logged

If you want to see a sunset or sunrise of Dolomiti Val Gardena shot with CHDK visit
Instagram: dolomiti_timelapse
YouTube: https://www.youtube.com/channel/UCEJHg--ujxLkjMrevJXh-Gw

dolomiti_timelapse

96

Re: CHDK for longtime timelapse

« Reply #82 on: 06 / November / 2021, 09:19:39 »

Thank you for your replay

Before I was going to give you an answer, I wanted to do one more test.

I found out that the "ASSERT!! MotionVector.c Line 338" error doesn't happen if I can ensure that all images (or dummies) are deleted after max 2 consecutive timelapse ( at the moment 720 photos each).
The last days I connected to my timelapse pc and checked with chdk ptp GUI that there were no "unidentified image". If so I deleted all images via the canon menu in playback mode using the chdk ptp GUI. -> no more "ASSERT!! MotionVector.c Line 338" error

The downside was that the command "imrm -quiet" never worked (this command would be prefered). Instead the code

Code: [Select]

luar click'menu'
exec sys.sleep(500)
luar click'down'
exec sys.sleep(400)
luar click'down'
exec sys.sleep(250)
luar click'down'
exec sys.sleep(250)
luar click'down'
exec sys.sleep(250)
luar click'set'
exec sys.sleep(500)
luar click'down'
exec sys.sleep(400)
luar click'down'
exec sys.sleep(250)
luar click'set'
exec sys.sleep(500)
luar click'right'
exec sys.sleep(400)
luar click'set'
exec sys.sleep(40000)

only works some times? (this would be the steps I use for deleting the images via the GUI). That's why I tried to use longer sys.sleep times but with no real success up to now. I'm trying now even longer sys.sleep times between click commands.
maybe click'erase' would be more stable but I'm not sure if there is a setting to make sure all images are deleted and not just one single photo.

Quote from: reyalp on 26 / October / 2021, 21:31:01

Yes, it is, and it happens even with the "always stay logged in option" caefix mentioned. It's happened to me enough that I try to copy my post to clipboard before posting, but sometimes I still forget

Yeah I also normally copy my post to clipboard but forgot to do so

Quote

For this one, it's possible that trying to set user av immediately after mode switch could cause problems. I would probably put a few hundred ms sleep between them, but given the other crash, I don't have high expectations.

I don't think so as this code part was working fine before I started to change to playback mode after each timelapse.

What's interesting on this part is:

Code: [Select]

!print(con:execwait[[if get_zoom() == 15 then return 'zoom ok' else set_zoom(15) return 'ERROR: zoom wrong - set to 15%' end]])

always return "zoom ok", which is correct (as the lense doesn't retract. instead

Code: [Select]

!print(con:execwait[[if get_focus_mode() == 1 then return 'focus mode ok' else set_mf(1) return 'ERROR: focus mode wrong - set to mf' end]])

and

Code: [Select]

!print(con:execwait[[if get_focus() == -1 or get_focus() == 33079 then return 'focus distance ok' else set_focus(-1) return 'ERROR: focus distance wrong - set to infinity' end]])

always returns

"ERROR: focus mode wrong - set to mf"
"ERROR: focus distance wrong - set to infinity"

Maybe after switching back from playback mode to rec mode the focus mode is always changed to AF?
What also didn't help was to set AF to MF manually in the GUI after a restart as the setting is not permanent after the change to playback mode.

You once wrote:

Quote

In the camera log for these, I see a lot of lines with "SS:SetFace". If the Canon menu AF setting is set to something Face, AiAF, or Tracking, I'd suggest trying setting it to Center instead.

maybe this is related to this.

@Caefix:
I don't understand how this script is supposed to help dolomiti_timelapse's problems, or indeed how it will work at all. It would be much more helpful to explain the idea than a complicated script.
[/quote]
Thanks.

« Last Edit: 06 / November / 2021, 09:23:05 by dolomiti_timelapse »

Logged

If you want to see a sunset or sunrise of Dolomiti Val Gardena shot with CHDK visit
Instagram: dolomiti_timelapse
YouTube: https://www.youtube.com/channel/UCEJHg--ujxLkjMrevJXh-Gw

Caefix

947
Sorry, busy deleting test shots...

Re: CHDK for longtime timelapse

« Reply #83 on: 06 / November / 2021, 13:58:50 »

Quote from: dolomiti_timelapse on 06 / November / 2021, 08:42:50

For me a simple and sufficient approach would be to delete all dummy files at the end of the timelapse.

If so then

Quote from: reyalp on 02 / November / 2021, 20:50:07

to call camera_reboot or or just do the part with
Code: [Select]
set_autostart(2) -- autostart once ... sleep(1000) reboot()

else if get_free_disk_space()<100000 then ...

Quote from: dolomiti_timelapse on 06 / November / 2021, 08:42:50

Quote from: Caefix on 27 / October / 2021, 11:48:23
Edit3: ... same line even shorter ...
Code: [Select]
luar function c(k,s) click(k) sleep(s*100) end set_record(0) sleep(1000) c("left",10) c("erase",5) c("right",5) c("set",10) set_record(1) sleep(1000) shoot()

Preparing the settings in playback menu speeding up to not animated change:
(could be <2sec. on muted cam.)
Last shot or last seen is the marker for next erase one image from Gui.
A click "left" at first deletes the shot before the shot, (PC side gluescript can fetch the last)
a click "right" probably the oldest image recognized (slow dashcam like), if 'last shot', or a bufferzone else...
Once the function is called after 100 shots, it will stay at 100 shots, rotating...
Btw. in Record menu: Lens retraction time should be set to 1 min.
Review image after shoting -> Display Time Off.

Edit: Your G1x - Erase all images?

?? in one line...

Code: [Select]


luar function c(k,s) click(k) sleep(s*100) end c("menu",5) c("down",3) c("down",3) c("down",3) c("down",3) c("set",5) c("up",3) c("set",5) c("right",5) c("set",3) sleep(40000)

Quote from: Caefix on 27 / October / 2021, 11:48:23

Edit3: ... same line even shorter ...

Code: [Select]

luar function c(k,s,x) x=x or 1 for x=1,x do click(k) sleep(s*100) end end c("menu",5) c("down",3,4) c("set",5) c("up",3) c("set",5) c("right",5) c("set",3) sleep(40000)

and shorter, because this case isn´t a race, time to sleep has place in space.

Code: [Select]

luar function c(k,x) for x=1,x or 1 do click(k or "set") sleep(500) end end c("menu") c("down",4) c() c("up") c() c("right") c() sleep(40000)

DON´T INVOKE THIS SPELL IF YOU DON´T WANT NO IMAGE!

ForGuiErase.jpg (72.22 kB, 637x358 - viewed 11 times.)

NoImage!.jpg (5.97 kB, 360x270 - viewed 4 times.)

« Last Edit: 10 / November / 2021, 13:29:10 by Caefix »

Logged

All lifetime is a loan from eternity.

reyalp

14111

Re: CHDK for longtime timelapse

« Reply #84 on: 06 / November / 2021, 18:03:54 »

Quote from: dolomiti_timelapse on 06 / November / 2021, 09:19:39

I found out that the "ASSERT!! MotionVector.c Line 338" error doesn't happen if I can ensure that all images (or dummies) are deleted after max 2 consecutive timelapse ( at the moment 720 photos each).

Hmm, it would surprise me that the files / dummies trigger this crash. But I've been surprised before

Quote

The downside was that the command "imrm -quiet" never worked (this command would be prefered). Instead the code
Code: [Select]
luar click'menu' exec sys.sleep(500) ...
only works some times? (this would be the steps I use for deleting the images via the GUI). That's why I tried to use longer sys.sleep times but with no real success up to now. I'm trying now even longer sys.sleep times between click commands.

If you can watch it doing this and see what happens on the when it fails, that provide some clues, but I understand this could be difficult in your configuration.

One possibility is that it's the click command itself that fails, rather than the sleeps between. "click" is a press and release with a built in delay (I think 60ms in the current G1 X port, though there may be some additional delay), and there can be cases where the delay isn't long enough. So you could replace the click with something like

Code: [Select]

luar press'down' sleep(200) release'down'

Note:
1) If the delay is too long, a command like this could move multiple items in the menu. 200 was OK in a quick test on one of my cams, but YMMV. 300 seemed too long.
2) You must put the press and release in the same luar command with a camera side sleep, as shown above, rather than a separate chdkptp side exec sys.sleep(), because any keys pressed in luar are automatically released when the luar command completes.
3) When in playback after connecting USB, the camera will ignore all key presses until it has either been switched to rec (and back, if you want play mode) or you've posted an unlock event like luar post_levent_to_ui(4484). In your normal workflow, deleting should happen after shooting (which means the keyboard will already be unlocked by going to rec and back), but this could be relevant if you try to delete after a crash or reboot.

If that doesn't work, there are also a couple other ways you could navigate the menu with chdkptp commands:
1) Simulating the jogdial instead, using wheel_left() / wheel_right(). These should consistently move exactly one menu item. You'll still need to key presses for menu and set, of course.
2) Using events. This simulates key presses at a different level in the firmware. So you could simulate a menu press with

Code: [Select]

luar post_levent_to_ui('PressMenuButton') post_levent_to_ui('UnpressMenuButton')

The events for the other keys are as you'd expect: PressSetButton, PressUpButton etc. In a quick test, sending the press/unpress like the above with no delay worked, but again, YMMV.

Quote

maybe click'erase' would be more stable but I'm not sure if there is a setting to make sure all images are deleted and not just one single photo.

Not that I'm aware of.

I recall in an earlier discussion (https://chdk.setepontos.com/index.php?topic=11481.msg146783#msg146783) you were using PT_EraseAllFile. Did this end up causing problems? Note it must be used in rec mode, and you'd need to avoid switching to play until it finished (I think the function should block, but I haven't tested).

Also, the example I posted in that thread used con:call_function(...). It's possible this will fail if a function takes a long time. Since you have native calls enabled now, you can use call_func_ptr in a camera side script instead, which should be both clearer and less likely to have timeout problems. I can post the equivalent code if you want.

Quote

Quote
For this one, it's possible that trying to set user av immediately after mode switch could cause problems. I would probably put a few hundred ms sleep between them, but given the other crash, I don't have high expectations.
I don't think so as this code part was working fine before I started to change to playback mode after each timelapse.

FWIW, I would recommend a delay in any case, because there are known issues related to mode switches not being fully complete when when the mode switch command returns.

Quote

What's interesting on this part is:
Code: [Select]
!print(con:execwait[[if get_zoom() == 15 then return 'zoom ok' else set_zoom(15) return 'ERROR: zoom wrong - set to 15%' end]])
always return "zoom ok", which is correct (as the lense doesn't retract. instead

Code: [Select]
!print(con:execwait[[if get_focus_mode() == 1 then return 'focus mode ok' else set_mf(1) return 'ERROR: focus mode wrong - set to mf' end]])and
Code: [Select]
!print(con:execwait[[if get_focus() == -1 or get_focus() == 33079 then return 'focus distance ok' else set_focus(-1) return 'ERROR: focus distance wrong - set to infinity' end]])always returns

"ERROR: focus mode wrong - set to mf"
"ERROR: focus distance wrong - set to infinity"

Maybe after switching back from playback mode to rec mode the focus mode is always changed to AF?
What also didn't help was to set AF to MF manually in the GUI after a restart as the setting is not permanent after the change to playback mode.

It is normal for the MF setting to be cleared when switching to playback on some cameras, though my impression is this mostly affects much older cameras. Turning the display off through the Canon UI also generally turns off MF. CHDK set_lcd_display generally does not affect the focus setting but the Canon auto display/sensor off power saving mode can.

Quote

You once wrote:
Quote
In the camera log for these, I see a lot of lines with "SS:SetFace". If the Canon menu AF setting is set to something Face, AiAF, or Tracking, I'd suggest trying setting it to Center instead.
maybe this is related to this.

From the manual it looks like "FlexiZone" is the normal/non-face setting. If the face related messages appear in that mode, I'd assume that's normal Canon firmware behavior. We've observed elsewhere that a lot of the face stuff runs all the time, even when it's not in use.

You mentioned the setting being reset in https://chdk.setepontos.com/index.php?topic=14302.msg147124#msg147124
One thing to be aware of is if you reboot with CHDK reboot, Canon settings are not saved. You should shut down with the physical button or post_levent_to_ui('PressPowerButton') to ensure they are saved.

Logged

Don't forget what the H stands for.

dolomiti_timelapse

96

Re: CHDK for longtime timelapse

« Reply #85 on: 07 / November / 2021, 07:44:17 »

Quote from: reyalp on 06 / November / 2021, 18:03:54

One possibility is that it's the click command itself that fails, rather than the sleeps between. "click" is a press and release with a built in delay (I think 60ms in the current G1 X port, though there may be some additional delay), and there can be cases where the delay isn't long enough. So you could replace the click with something like
Code: [Select]
luar press'down' sleep(200) release'down'

Thanks I will definetly try this out!

Code: [Select]

luar press'down' sleep(200)

You mean that this code would be the same as above?

Quote

If that doesn't work, there are also a couple other ways you could navigate the menu with chdkptp commands:
1) Simulating the jogdial instead, using wheel_left() / wheel_right(). These should consistently move exactly one menu item. You'll still need to key presses for menu and set, of course.
2) Using events. This simulates key presses at a different level in the firmware. So you could simulate a menu press with
Code: [Select]
luar post_levent_to_ui('PressMenuButton') post_levent_to_ui('UnpressMenuButton')The events for the other keys are as you'd expect: PressSetButton, PressUpButton etc. In a quick test, sending the press/unpress like the above with no delay worked, but again, YMMV.

I will try out 2) if luar press'down' sleep(200) release'down' won't work 100% reliable.

Quote

I recall in an earlier discussion (https://chdk.setepontos.com/index.php?topic=11481.msg146783#msg146783) you were using PT_EraseAllFile. Did this end up causing problems? Note it must be used in rec mode, and you'd need to avoid switching to play until it finished (I think the function should block, but I haven't tested).

Also, the example I posted in that thread used con:call_function(...). It's possible this will fail if a function takes a long time. Since you have native calls enabled now, you can use call_func_ptr in a camera side script instead, which should be both clearer and less likely to have timeout problems. I can post the equivalent code if you want.

I read again the post. Now it seems much more comprehensive than it was at that time. It seems that I make progress.

you are saying, that I could just execute exec con:call_function(0xff077f50) in rec mode and than add say exec sys.sleep(20000) before switching to play mode? 0xff077f50 stand for PT_EraseAllFile_FW in G1X platform.

Quote

FWIW, I would recommend a delay in any case, because there are known issues related to mode switches not being fully complete when when the mode switch command returns.

I added exec sys.sleep(500) between the lines. So in this case a PC side wait is always recommended?

Quote

You mentioned the setting being reset in https://chdk.setepontos.com/index.php?topic=14302.msg147124#msg147124
One thing to be aware of is if you reboot with CHDK reboot, Canon settings are not saved. You should shut down with the physical button or post_levent_to_ui('PressPowerButton') to ensure they are saved.

ok, thanks!

EDIT:

Quote

3) When in playback after connecting USB, the camera will ignore all key presses until it has either been switched to rec (and back, if you want play mode) or you've posted an unlock event like luar post_levent_to_ui(4484). In your normal workflow, deleting should happen after shooting (which means the keyboard will already be unlocked by going to rec and back), but this could be relevant if you try to delete after a crash or reboot.

The problem why the photos are not deleted seems to be more related to 3).
The camera doesn't ignore the button press, but it can't go into the menu if rawopint has run for a certain minimum time though. If I do a test run with, say, 20 photos every 15 seconds, the menu command works fine. It could be related to what you say in 3), but I observed that the camera did something, but it tried to open something else (maybe the chdk menu), but not the Canon menu (unfortunately the web cam of the pc is too far away and the lag over anydesk too bad).
Maybe exec con:call_function(0xff099f1c) is also involved, and I should delete the photos before calling exec con:call_function(0xff099f1c). I will try that out as well.
I also added luar post_levent_to_ui(4484) for the next runs.

« Last Edit: 07 / November / 2021, 12:30:04 by dolomiti_timelapse »

Logged

If you want to see a sunset or sunrise of Dolomiti Val Gardena shot with CHDK visit
Instagram: dolomiti_timelapse
YouTube: https://www.youtube.com/channel/UCEJHg--ujxLkjMrevJXh-Gw

reyalp

14111

Re: CHDK for longtime timelapse

« Reply #86 on: 07 / November / 2021, 14:03:24 »

Quote from: dolomiti_timelapse on 07 / November / 2021, 07:44:17

Code: [Select]
luar press'down' sleep(200)You mean that this code would be the same as above?

Pretty much, but release also has a delay built into after the key is released, so if you did multiple calls one after the other its possible the camera wouldn't notice the previous one had be released.

Quote

you are saying, that I could just execute exec con:call_function(0xff077f50) in rec mode and than add say exec sys.sleep(20000) before switching to play mode? 0xff077f50 stand for PT_EraseAllFile_FW in G1X platform.

Yes. Of course you need the other parts (malloc, poke, free) too. Whether you need the sleep depends whether the function blocks until it's done. I think it probably does, you should. And as I mentioned, it's possible con:call_function will fail if the function blocks for a long time. I'd expect a "long time" in this context to be seconds or tens of seconds, and the failure would be a connection error and/or camera crash.

Quote

I added exec sys.sleep(500) between the lines. So in this case a PC side wait is always recommended?

Doesn't really matter whether it's PC side or not, I'd just recommend a small delay after mode switching before calling other camera functions.

Quote

The problem why the photos are not deleted seems to be more related to 3).
The camera doesn't ignore the button press, but it can't go into the menu if rawopint has run for a certain minimum time though. If I do a test run with, say, 20 photos every 15 seconds, the menu command works fine. It could be related to what you say in 3), but I observed that the camera did something, but it tried to open something else (maybe the chdk menu), but not the Canon menu (unfortunately the web cam of the pc is too far away and the lag over anydesk too bad).

It should not be possible for a CHDK key press to open any CHDK menu. If something happens in with the CHDK OSD, it's more likely to be an error message in the script console or something like that.

One thing that occurs to me is that when you switch to play after shooting a lot of images, the canon firmware spends some time "indexing" the files, with the green activity LED blinking. It probably doesn't respond to menu key presses in this time.

edit:
I see in the sunset_chdk_dummy.chdkptp you posted a while ago, there's a total of 3s sleep after switching to play.

Code: [Select]

#cooling down sensor after taking sunset until next sunrise
!print'change to playback mode'
play 
exec sys.sleep(2000)

!print'avoid lense retraction after 1 minute'
exec con:call_function(0xff099f1c) 
exec sys.sleep(1000)

I'd definitely try increasing that, to like 30s or a minute. If you can see when the LED stops blinking that would give you an idea how long it takes. The canon UI also doesn't show the total number of images until it's done.

Quote

I also added luar post_levent_to_ui(4484) for the next runs.

I don't think this is the issue. It should not be possible for the specific issue that needs that to happen after running rawopint, since you've already switched to rec, which unlocks the keyboard, and it wouldn't be an intermittent thing.

« Last Edit: 07 / November / 2021, 14:09:31 by reyalp »

Logged

Don't forget what the H stands for.

dolomiti_timelapse

96

Re: CHDK for longtime timelapse

« Reply #87 on: 08 / November / 2021, 06:41:28 »

Quote from: reyalp on 07 / November / 2021, 14:03:24

Pretty much, but release also has a delay built into after the key is released, so if you did multiple calls one after the other its possible the camera wouldn't notice the previous one had be released.

ok, thanks for this information!

Quote

Yes. Of course you need the other parts (malloc, poke, free) too. Whether you need the sleep depends whether the function blocks until it's done. I think it probably does, you should. And as I mentioned, it's possible con:call_function will fail if the function blocks for a long time. I'd expect a "long time" in this context to be seconds or tens of seconds, and the failure would be a connection error and/or camera crash.

I will definitely try this out after I tested the new modifications like waiting until indexing is finished.

Quote

One thing that occurs to me is that when you switch to play after shooting a lot of images, the canon firmware spends some time "indexing" the files, with the green activity LED blinking. It probably doesn't respond to menu key presses in this time.

edit:
I see in the sunset_chdk_dummy.chdkptp you posted a while ago, there's a total of 3s sleep after switching to play.

I'd definitely try increasing that, to like 30s or a minute. If you can see when the LED stops blinking that would give you an idea how long it takes. The canon UI also doesn't show the total number of images until it's done.

Quote

I don't think this is the issue. It should not be possible for the specific issue that needs that to happen after running rawopint, since you've already switched to rec, which unlocks the keyboard, and it wouldn't be an intermittent thing.

Ok, I removed luar post_levent_to_ui(4484) and added some waiting time for indexing.

The first run this mornig worked flawless. with the code below.

Thank you very much for your tips, which helped me get to the root of this particular bug.

Code: [Select]

#cooling down sensor after taking sunrise until next sunset
!print'change to playback mode'
play 
# waiting until indexing is finished
exec sys.sleep(10000)

!print'avoid lense retraction after 1 minute'
exec con:call_function(0xff099f1c) 
exec sys.sleep(1000)

!print'delete dummy files on sd card'
luar press'menu' sleep(200) release'menu'
exec sys.sleep(400)
luar press'down' sleep(200) release'down'
exec sys.sleep(300)
luar press'down' sleep(200) release'down'
exec sys.sleep(200)
luar press'down' sleep(200) release'down'
exec sys.sleep(200)
luar press'down' sleep(200) release'down'
exec sys.sleep(200)
luar press'set' sleep(200) release'set'
exec sys.sleep(300)
luar press'down' sleep(200) release'down'
exec sys.sleep(300)
luar press'down' sleep(200) release'down'
exec sys.sleep(200)
luar press'set' sleep(200) release'set'
exec sys.sleep(300)
luar press'right' sleep(200) release'right'
exec sys.sleep(300)
luar press'set' sleep(200) release'set'
exec sys.sleep(20000)

what I will try next is:

Code: [Select]

#cooling down sensor after taking sunrise until next sunset
!print'change to playback mode'
play 
# waiting until indexing is finished
exec sys.sleep(10000)

!print'avoid lense retraction after 1 minute'
exec con:call_function(0xff099f1c) 
exec sys.sleep(1000)

!print'delete dummy files on sd card'
luar click'menu'
exec sys.sleep(400)
luar click'down'
exec sys.sleep(200)
luar click'down'
exec sys.sleep(200)
luar click'down'
exec sys.sleep(200)
luar click'down'
exec sys.sleep(200)
luar click'set'
exec sys.sleep(500)
luar click'down'
exec sys.sleep(200)
luar click'down'
exec sys.sleep(200)
luar click'set'
exec sys.sleep(500)
luar click'right'
exec sys.sleep(200)
luar click'set'
exec sys.sleep(20000)

and last test, at the end of the rawopint script (or in a new script, maybe that's better in this case):

Code: [Select]

# allocate a buffer
# 0xff00420c,malloc
exec ptr=con:call_function(0xff00420c,4)
# set the contents of the buffer to the address of a function that returns 0
# in this case PT_ShootPicture, which is a "hook" eventproc that defaults to no-op.
# 0xff077f48,PT_ShootPicture_FW
# disassembly
# PT_ShootPicture_FW 0xff077f48
#    mov     r0, #0
#    bx      lr
exec con:execwait(string.format([[poke(%d,0xff077f48)]],ptr))
# call PT_EraseAllFile with the buffer
# 0xff077f50,PT_EraseAllFile_FW
exec con:call_function(0xff077f50,ptr)
# free the buffer
# 0xff004264,free
exec con:call_function(0xff004264,ptr)

I will come back in about 1-2 weeks with the results.

« Last Edit: 08 / November / 2021, 06:52:06 by dolomiti_timelapse »

Logged

If you want to see a sunset or sunrise of Dolomiti Val Gardena shot with CHDK visit
Instagram: dolomiti_timelapse
YouTube: https://www.youtube.com/channel/UCEJHg--ujxLkjMrevJXh-Gw

Caefix

947
Sorry, busy deleting test shots...

Re: CHDK for longtime timelapse

« Reply #88 on: 08 / November / 2021, 13:16:39 »

Quote from: reyalp on 07 / November / 2021, 14:03:24

If you can see when the LED stops blinking that would give you an idea how long it takes. The canon UI also doesn't show the total number of images until it's done.

Code: [Select]

    repeat sleep(1000) until get_jpg_count() --(??)--(??)--

Logged

All lifetime is a loan from eternity.

reyalp

14111

Re: CHDK for longtime timelapse

« Reply #89 on: 08 / November / 2021, 16:05:49 »

Quote from: Caefix on 08 / November / 2021, 13:16:39

Code: [Select]
repeat sleep(1000) until get_jpg_count() --(??)--(??)--

Have you tested this? As I posted in this thread my impression is that get_jpg_count is only valid/updated in rec mode. It uses the string the Canon firmware displays to show remaining images, which is the Canon firmware only displays in rec mode. From a quick test in my elph130, deleting images with the Canon UI or CHDK does not affect the value of get_jpg_count in playback, it just returns the last value seen in rec mode, or 0 if rec has not be used since boot.

Note also that get_jpg_count() is the Canon firmware's idea of the number of jpegs that could fit in the *remaining* space, not a count of the jpegs on the card.

It would be helpful if you can be clear whether things you post are just an idea, or something you've actually tested.

Logged

Don't forget what the H stands for.