Normally a "crash" in CHDK means the camera records a romlog (to internal flash memory), and then shuts down. Again, if you get the romlog I can confirm whether it is the file delete crash or something else.
i do not look at the card after each failed test, just change code and try again. there is no romlog on it at the moment.
I'm sorry, I don't understand what outcome you are describing here. Do you mean that switching to play before deleting avoids the crash, or not?
It's normal to see something like unknown or invalid image after deleting using CHDK.
yes, moving to play before deleting files makes delete files and then reboot work.
The names in ${whatever} need to be defined in the code, you can't just add new names like imagenr without implementing a new subst function (see download_images_subst_funcs) . I thought I posted more details of this, not sure if I messed up or or the forum ate something 
it was unclear to me how to define that or make imgnum = imagenr. and thought that the crippled code would at least show you what i was thinking of.
Anyway, if you have the number you want to use in a variable named my_image_number, you can do something like
dst='${id}/${subdir}/IMG_'..string.format('%04d',my_image_number)..'${ext}'
Note that this value would be used for every image downloaded by that download_images call, unlike the subst values which can vary per image. So if you download multiple images with one call, you'd need something else to ensure the names were unique.
this works for me.
but i'll remember for when i get to the point that i want to download more than one image between shots...something that, at this point, is still far beyond the horizon.
shotseq and dlseq are unfortunately special in multicam download_images. The initial value for the call is set by the dlseq_start and shotseq_start options passed to download_images, which default to 1. Note the value starts at the initial value for each camera. So if you shot ten shots, you will get images numbered 1 to 10 for each camera.
This also means shotseq / dlseq values are not preserved between calls (unlike imdl). In the example above, if you shot another ten images and downloaded again, the images would be numbered 1 to 10 again. So if you want to do sequential numbers over multiple download calls, you'd need to track that yourself somehow.
that's not unfortunate, it's a great numbering method, just not for me.
i created imagenr just making sure i always had the 'correct' sequential number for my purpose and in the current setup it works.
i changed reboot sequence to 15 minutes for the next tests.
after reboot #3 it had an i/o error after moving to play and files were not removed.
restarting the script resulted again in an i/o error after moving to play at some moment and files were again not removed.
it is every time cam #1 with the 102b revision, not cam #2 with the 103a..even if i swap usb ports.
i added a delay before it starts removing that seems to have solved it, maybe it's just too close to the 'go to play' that the canon software is not ready yet.
although i would think the cmdwait('play') would give enough time for the canon software to be ready.
and after running close to an hour i've seen 4 lines of
'attempting to close non present device'
between 2 shots.
must have happened during lastimg download. no idea what caused it or why it was resolved. but i stopped the script a few shots later, so i have to check if it repeats itself.
before i start rewriting it to something more functional and readable that doesn't work long term.
i think it's time to put it in a daily reboot sequence to see if it works stable and how
long the reboot will take when it removes a day worth of images.
