FWIW download_images provides extensive controls for naming the files, using the "subst strings" documented for imdl or variables defined in your own code, so you could organize them at download time rather than trying to keep the camera counter in sync.
Note using CHDK reboot may cause the Canon image counter to not be saved, and that the Canon firmware may reset the counter based on the highest numbered image found on the card.
i have to give that renumbering some thought, i made a calculation based on time: at this moment the pc side script already calculates the number an image 'should' have and that might be used when downloading to rename it......have to add IMG_ to it, enough 0 to make up 4 digits and figure out how to use it in download_images{lastimg=1} while keeping the folder dates from the cam.
because the cams work with utc+1, but the pc is changing from summer to wintertime and i don't want that hour ending up in the wrong folder.
otherwise i guess it has to become something like :
download_images{lastimg=1} [${subdir}/${dlseq}]
and that will probably lead close to the same numbering.
and maybe you just handed another option although implementing it might prove difficult:
delete all images but the last, so that last image is still there at reboot, keeping the image counter correct
By "it stays off" do you mean the camera crashes? If this the case, and you are using the code posted below, it's likely that it's caused by not switching to playback before deleting.
If there's a lot of images, the camera may spend quite a bit of time "indexing" when you switch to play.
Note the deleting bug applies to CHDK delete (and remoteshoot). Some alternatives are discussed in https://chdk.setepontos.com/index.php?topic=14302.msg147265#msg147265 and https://chdk.setepontos.com/index.php?topic=11481.msg146783#msg146783
I think i do, but it's not a hard crash.....don't have to pull the battery, it works again with pressing the [on] button.
and although indexing takes up a lot of time. i have not seen that as a problem when rebooting from SUIx after 3 weeks and at that moment some 60.000 images on card.
it just reboots without waiting the indexing to finish and never had trouble with that.
did have some trouble, but that was the indexing when it starts up again. (busy)
so i would not expect it to become an issue with multicam ordering the reboot.
the sequence of shooting, downloading and removing works in record, move to play seems to work and reboot stops after powering down and the screen turns black, i can either remove the reboot or the delete sequence and the script will keep running..........will look more in depth at those alternatives.
If the problem is the crash mentioned above, the simple approach is to switch to play, delete, and then reboot.
wanted to try that, will test if that does not halt the reboot..it doesn't.
however i did see 'image too large' with a question mark on one of the cams when in play...it appears before the reboot happens and i've only seen it on rev 102b cam, not on the 103a and it does not happen every time.
it does not seem to hinder the reboot, so time to look into that numbering sequence, because after 10 reboots i still only have 2 cams of img_0001.jpg downloaded and cam side they are gone.
If that causes too much delay, then maybe the PT_EraseAllFile approach might be another option.
if i have to wait for indexing to finish before i use delete. and for now it looks like that need is not there.
and to see if delete_files itself takes up much time, i have to test with more images.
EraseAllFile, i don't know this one...what i read so far, makes me believe it is cam model specific to make it work and for that reason should be avoided by me if at all possible.
it will take a few more tweaks to the script, like the file numbering, before i can do a proper test where it will reboot once a day for a week to see how much time is involved in deleting a days worth of images and rebooting is complete.
