reboot after 21 days worked, but with fault - page 2 - General Help and Assistance on using CHDK stable releases - CHDK Forum  

reboot after 21 days worked, but with fault

  • 16 Replies
  • 271 Views
Re: reboot after 21 days worked, but with fault
« Reply #10 on: 06 / June / 2019, 02:44:20 »
Advertisements
All things considered I think it is amaizing that it survived this run,

Definitely…
But maybe there is a limit (16Bit) for the maximum number of recordings that can be handled by the cam on the SD card ...
M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), 2*S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

*

Offline Mlapse

  • ***
  • 184
  • A480 A490 S95 M10
Re: reboot after 21 days worked, but with fault
« Reply #11 on: 06 / June / 2019, 03:03:32 »
Quote
Definitely…
But maybe there is a limit (16Bit) for the maximum number of recordings that can be handled by the cam on the SD card ...

I would have expected some 4000 more then.
to test that theorie i just copied 3000 pictures extra to that card, put it back in the cam, fired it up manually so the cam stalls checking all those files and started the script. and that works.
might not be the same as if it was the same run, but it's more files on the card. so it is not a total file number limit (yet)
« Last Edit: 06 / June / 2019, 03:07:59 by Mlapse »
frustration is a key ingredient in progress

*

Offline Mlapse

  • ***
  • 184
  • A480 A490 S95 M10
Re: reboot after 21 days worked, but with fault
« Reply #12 on: 06 / June / 2019, 03:15:05 »
Quote
The script logs this if set_record fails. If this happened, then all subsequent shooting would likely also fail (though later attempts to shoot of half press could coincidentally switch to rec on many cameras)
so if I understand you, the set_record fail was because it came in too early after the reboot. resulting in no shot at 11:51:00, but the attempt to shoot made set_record initialise correctly
so the next at 11:51:30 was then recorded.
this at least explaines partly why there is a 2.5 minute gap instead of a 1.5 minute gap when i was testing.

BTW the 10s delayed start Waterwingz made for me (CHDK 1.5.0) makes the CF zoom setting in custom mode delay as well, but since timing after reboot for the next shot was close. it mights be that the lens was not ready and this created the set_record flag and that I should set the script shoot delay in the UI menu to prevent this.

just out of curiosity, why is the 'rebooting now' time later than the startup time.
Code: [Select]
Day 21 Sat Jun  1 11:50:10 2019 lens retraction wait
Day 21 Sat Jun  1 11:51:22 2019 rebooting now

Day -- Sat Jun  1 11:50:57 2019 === Ultimate v4.8 : 11:50 ===
Day -- Sat Jun  1 11:50:57 2019 CHDK 1.5.0 s95 100k May  6 2019
« Last Edit: 06 / June / 2019, 04:19:47 by Mlapse »
frustration is a key ingredient in progress

Re: reboot after 21 days worked, but with fault
« Reply #13 on: 06 / June / 2019, 08:28:00 »


just out of curiosity, why is the 'rebooting now' time later than the startup time.
The camera reads it's hardware battery backed real time clock (RTC) when it starts up. After that it maintains time in software. It's unlikely Canon worried too much about the accuracy of the software maintained time as most people don't leave their camera powered up for many hours.
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline Mlapse

  • ***
  • 184
  • A480 A490 S95 M10
Re: reboot after 21 days worked, but with fault
« Reply #14 on: 09 / June / 2019, 00:48:59 »
@waterwingz, if your explanation is right that it only reads RTC at startup, why isn't that time used after the reboot? I would suspect the reboot simulates a startup(it at least resets the tick-counter)
thus shouldn't the CF reboot with that time and thus set the time in CHDK as well?

I have found another strange thing after reboot and I think this needs more attention than the time-traveling features of the cam.
related to this or to reyalps remark of set_record fail?

the interval for this run was set at 30seconds, so it should create 2880 pics a day. and it did for the first 3 weeks.

After the time-shift in the log occured(rebooting now 11:51:22, day21)and set_record fail, i am missing 10 pictures of that day.(except for the 2 because of a reboot)
this keeps occuring the following days with loss of 20-25 frames a day.

looking through the log I found this:
the missing ones are logged with exact times in seconds (00 or 30)
those also had similar IMG_numbers in the log. It looks like the ones with the 00 or 30 sec. in the log were not recorded on the SD card, not that the old one was overwritten.
I have no missing pics on a day pre-reboot (nor have i experienced this problem in a non-reboot run ever)
Can this be solved?....or can I find out why this happens, so we might solve it in the future.
hereby a small portion from the log where it happened twice in 5 minutes.


Code: [Select]
Day 21 Sat Jun 1 21:11:04 2019 IMG_0539.JPG tv: 0.6 f: 3.1 ISO: 75 bv: 14 V: 3.949
Day 21 Sat Jun 1 21:11:30 2019 IMG_0539.JPG tv: 0.6 f: 3.1 ISO: 75 bv: 5 V: 3.949
Day 21 Sat Jun 1 21:12:04 2019 IMG_0540.JPG tv: 0.6 f: 3.1 ISO: 75 bv: -2 V: 3.953
Day 21 Sat Jun 1 21:12:34 2019 IMG_0541.JPG tv: 0.6 f: 3.1 ISO: 75 bv: -11 V: 3.94
Day 21 Sat Jun 1 21:13:04 2019 IMG_0542.JPG tv: 0.6 f: 3.1 ISO: 75 bv: -19 V: 3.949
Day 21 Sat Jun 1 21:13:34 2019 IMG_0543.JPG tv: 0.6 f: 3.1 ISO: 75 bv: -27 V: 3.953
Day 21 Sat Jun 1 21:14:00 2019 IMG_0543.JPG tv: 0.6 f: 3.1 ISO: 75 bv: -35 V: 3.949
« Last Edit: 09 / June / 2019, 05:11:07 by Mlapse »
frustration is a key ingredient in progress

Re: reboot after 21 days worked, but with fault
« Reply #15 on: 09 / June / 2019, 11:30:18 »
@waterwingz, if your explanation is right that it only reads RTC at startup, why isn't that time used after the reboot? I would suspect the reboot simulates a startup (it at least resets the tick-counter) thus shouldn't the CF reboot with that time and thus set the time in CHDK as well?
My explanation is correct - the RTC is only read at startup or a reboot. And it does use the RTC time after each reboot. Which is consistent with the log file snippet you posted.  Prior to the reboot, the internal time maintained by the Canon firmware was running slightly faster than the time maintained by the RTC. So when the reboot happens the Canon firmware reads the RTC and uses that time to initialize its software internal clock. This causes the logged time to appear  to go backwards (as the software maintained time prior to reboot was running ahead of the RTC time).

Quote
I have found another strange thing after reboot and I think this needs more attention than the time-traveling features of the cam related to this or to reyalps remark of set_record fail?
This is quite interesting.  Before I dig deeper into it, it would be nice to see a much bigger piece of log file. Can you post the whole thing somewhere and sent me a link? Or at least the part of the log including the reboot message and then all the shots up until the skipped images, and then a couple hundred shots after that?

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline Mlapse

  • ***
  • 184
  • A480 A490 S95 M10
Re: reboot after 21 days worked, but with fault
« Reply #16 on: 09 / June / 2019, 12:05:45 »
hereby, i left the header and a small portion before reboot and then until the end. as you can see there is not much consistancy in when it does this, the skipped images are just scattered throughout the day.

if you want the complete thing, that ok too, but it's just this + some 58000 lines stating all is well.
« Last Edit: 09 / June / 2019, 12:42:48 by Mlapse »
frustration is a key ingredient in progress

 

Related Topics