Could you combine 'is_video_recording()' with a call to 'TakeSemaphore()' that has a very short timeout? If the TakeSemaphore fails then it might be a better indication that movie recording is actually in progress.
I'm thinking about leaving 'is_video_recording()' out of all this. 'fileio_semaphore' seems to be a good indication of an ongoing movie recording.
- Fopen_Fut: we could 'take' and 'give' the semaphore right before the call, but doing that does not seem too professional nor is it 100% reliable.
We could also switch to 'Fopen_FileStream' and protect it the same way as open().
- Other file system related functions: ?
QuoteWe could also switch to 'Fopen_FileStream' and protect it the same way as open().Not sure what implications of this are. We would presumably have to identify the equivalents of all the other Fut functions.
Quote- Other file system related functions: ?Presumably, all the ones that have the fileio_semaphore protection now and all of the _Fut io functions. I verified on a540 that opening a file in lua, starting movie record, and then trying to write causes the same sort of hang.This raises the possibility that open will work, but reads, writes or the subsequent close will fail. The last would be particularly bad, since no one expects close to fail and the file handle would be left open.
An alternative might be to forcefully release the semaphore from whatever movie task it's used in, but presumably they lock out all IO for a reason.
IIRC there are some cameras that let you take stills in video (causing a momentary break in the video) It might be worth looking at what they do.
I'm thinking about leaving 'is_video_recording()' out of all this. 'fileio_semaphore' seems to be a good indication of an ongoing movie recording. I think I have found its equivalent on VxWorks (in attachment) too, it's called "FileAccessSem" in the ixus30 fw.We can't take this semaphore during a call to Fopen_Fut, because all _Fut functions appear to 'take' it.So, taking care of open() seems to be possible (also in the attachment). Question is, what else do we want to protect.- Fopen_Fut: we could 'take' and 'give' the semaphore right before the call, but doing that does not seem too professional nor is it 100% reliable. We could also switch to 'Fopen_FileStream' and protect it the same way as open().- Other file system related functions: ?edit:link added
How confident are you that the VxWorks fileio_semaphore values are correct?
Also, why only protect the _Open call with the semaphore for VxWorks? _Close and _Write are also protected for DryOS (or is this just due to the age of the patch).
- file IO using fopen/fclose while recording video will lockup the camera until video stops or battery pulled.
Quote from: philmoz on 02 / November / 2014, 20:21:54How confident are you that the VxWorks fileio_semaphore values are correct?I have taken a look at some old, newer and new Vx firmware and the file semaphore init routine (must be part of their FileSem library) always seemed the same (1st check is for "FileAccessSem", I'm assuming they did not move lines in their source around). The routines following the init function are "StartFileAccess_FileSem" and "EndFileAccess_FileSem". They have wrappers which are used in most _Fut functions. We/I could perhaps add the file access semaphore init function to the sigfinder's list and use a script (I do have such a script) to mass-disassemble its content for visual inspection.QuoteAlso, why only protect the _Open call with the semaphore for VxWorks? _Close and _Write are also protected for DryOS (or is this just due to the age of the patch).I either wasn't paying attention or because it was good enough for basic testing.Quote - file IO using fopen/fclose while recording video will lockup the camera until video stops or battery pulled.We could perhaps add the above mentioned imperfect protection to fopen, so it has less chance to lock the camera?
It might also be worth converting existing code from fopen/fclose to open/close where possible.
Thanks Phil, this looks like a big improvement. Quote from: philmoz on 03 / November / 2014, 19:49:45It might also be worth converting existing code from fopen/fclose to open/close where possible.The Lua IO code uses fopen/fclose because that's what the standard Lua code uses. AFAIK other users are pretty minimal at this point.The Lua stuff could probably be converted, but it would involve changing a lot of upstream code. An alternative would be to roll our own minimal clone of fopen etc based open/close.Firmware fopen handles have a 32k buffer attached to them, so a minimal conversion to open/close might affect scripts that do a lot of small IOs.
What about a user selectable option to allow 'potentially unsafe' IO operations to continue?If the option is enabled, then instead of failing when TakeSemaphore times out we just revert to the old functionality and call the underlying firmware function without the semaphore protection.
Started by scroaticle General Discussion and Assistance
Started by emutier Script Writing
Started by muchachotron General Help and Assistance on using CHDK stable releases
Started by flarn2006 General Discussion and Assistance
Started by 123blackjack General Chat