issues with open and fopen while recording video - page 2 - General Discussion and Assistance - CHDK Forum  

issues with open and fopen while recording video

  • 69 Replies
  • 19909 Views
*

Offline reyalp

  • ******
  • 13751
Re: issues with open() and fopen() while recording video
« Reply #10 on: 07 / June / 2014, 17:12:12 »
Advertisements
I don't know that part of the code, but I suspect that a file operation is attempted upon leaving ALT mode.
Yes, IIRC it tries to save the cfg.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4450
Re: issues with open() and fopen() while recording video
« Reply #11 on: 07 / June / 2014, 18:01:30 »
Code: [Select]
Index: platform/generic/wrappers.c
===================================================================
--- platform/generic/wrappers.c (revision 3457)
+++ platform/generic/wrappers.c (working copy)
@@ -366,14 +366,21 @@
  return _open(name, flags, mode);
 #endif
 */
+    if ( !is_video_recording() )
+    {
 #if CAM_DRYOS
-    _TakeSemaphore(fileio_semaphore,0);
-    int fd = _Open(name, flags, mode);
-    _GiveSemaphore(fileio_semaphore);
-    return fd;
+        _TakeSemaphore(fileio_semaphore,0);
+        int fd = _Open(name, flags, mode);
+        _GiveSemaphore(fileio_semaphore);
+        return fd;
 #else
-    return _Open(name, flags, mode);
+        return _Open(name, flags, mode);
 #endif
+    }
+    else
+    {
+        return -1;
+    }
 }
 
 int close (int fd)
This appears to solve the problem on my a3200 ( fopen() would need similar treatment ).
Now, the problem is that is_video_recording() is not reliable on every port:
some ports would need CAM_HAS_MOVIE_DIGEST_MODE even though they have no digest mode - I have fixed this on the a3200, but there's likely more.

*

Offline philmoz

  • *****
  • 3427
    • Photos
Re: issues with open() and fopen() while recording video
« Reply #12 on: 07 / June / 2014, 19:03:24 »
Code: [Select]
Index: platform/generic/wrappers.c
===================================================================
--- platform/generic/wrappers.c (revision 3457)
+++ platform/generic/wrappers.c (working copy)
@@ -366,14 +366,21 @@
  return _open(name, flags, mode);
 #endif
 */
+    if ( !is_video_recording() )
+    {
 #if CAM_DRYOS
-    _TakeSemaphore(fileio_semaphore,0);
-    int fd = _Open(name, flags, mode);
-    _GiveSemaphore(fileio_semaphore);
-    return fd;
+        _TakeSemaphore(fileio_semaphore,0);
+        int fd = _Open(name, flags, mode);
+        _GiveSemaphore(fileio_semaphore);
+        return fd;
 #else
-    return _Open(name, flags, mode);
+        return _Open(name, flags, mode);
 #endif
+    }
+    else
+    {
+        return -1;
+    }
 }
 
 int close (int fd)
This appears to solve the problem on my a3200 ( fopen() would need similar treatment ).
Now, the problem is that is_video_recording() is not reliable on every port:
some ports would need CAM_HAS_MOVIE_DIGEST_MODE even though they have no digest mode - I have fixed this on the a3200, but there's likely more.

It looks like it's getting stuck waiting for the semaphore in the _TakeSemaphore call - from memory the 0 second parameter means wait forever. Presumably the video recording has taken the semaphore so it's not available for us to use.

Your solution will prevent to file operation - if it's trying to save an updated config file, then this will fail and the changes won't get saved.

What happens if you call _Open instead of just returning -1? This has the risk of triggering the FsIoNotify issue; but that was a pretty rare occurrence.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 13751
Re: issues with open() and fopen() while recording video
« Reply #13 on: 07 / June / 2014, 20:15:29 »
What happens if you call _Open instead of just returning -1? This has the risk of triggering the FsIoNotify issue; but that was a pretty rare occurrence.
On at least some cameras, this problem predates the addition of the semaphore check.

Making open and fopen fail would probably be better than hanging, though I wouldn't be surprised if there is code that assumes open works and behaves badly.
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3427
    • Photos
Re: issues with open() and fopen() while recording video
« Reply #14 on: 07 / June / 2014, 20:58:44 »
What happens if you call _Open instead of just returning -1? This has the risk of triggering the FsIoNotify issue; but that was a pretty rare occurrence.
On at least some cameras, this problem predates the addition of the semaphore check.

Making open and fopen fail would probably be better than hanging, though I wouldn't be surprised if there is code that assumes open works and behaves badly.

That's annoying, though not really surprising - and yes, I suspect there would be code that doesn't check the 'open' return value.

A lot of ALT mode functionality relies on file I/O (modules, file browser, scripts) - maybe it's better to just block ALT mode when video is recording.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4450
Re: issues with open() and fopen() while recording video
« Reply #15 on: 08 / June / 2014, 09:45:06 »
A lot of ALT mode functionality relies on file I/O (modules, file browser, scripts) - maybe it's better to just block ALT mode when video is recording.
I'd still vote for making open and fopen fail. Opening the ALT menu, changing video related settings (such as compression quality or AF key) can be useful sometimes even during recording. The drawback is that settings made during recording may not be saved at all, new modules will not load, new scripts won't load, script settings won't be saved, logging will not work. I'm not sure if there can be any fatal consequences.
Also, there are video related scripts which need ALT mode (these can be loaded before recording).

The bad thing is that we can't safely enable such measures automatically for all ports due to problems with is_video_recording() on some cameras as mentioned above.

*

Offline reyalp

  • ******
  • 13751
Re: issues with open() and fopen() while recording video
« Reply #16 on: 08 / June / 2014, 15:08:04 »
I'd still vote for making open and fopen fail.
I agree. I'm sure there is code that will behave badly if open fails, but the current behavior is quite bad too, and generally we should try to make things error check and handle failures.

Quote
The bad thing is that we can't safely enable such measures automatically for all ports due to problems with is_video_recording() on some cameras as mentioned above.
Assuming that the TakeSemaphore does get blocked in this case, one thing we could do is put a timeout on it and make open fail if it times out. However, the timeout would likely need to be somewhat long (a second or more?) to avoid hitting in other "normal" situations.

Fopen is more complicated since it checks the semaphore internally...

I would guess a more reliable indication of video recording could probably be found in the firmware somewhere.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4450
Re: issues with open() and fopen() while recording video
« Reply #17 on: 08 / June / 2014, 17:40:04 »
Assuming that the TakeSemaphore does get blocked in this case, one thing we could do is put a timeout on it and make open fail if it times out.
Tried this on the a3200. The semaphore does get blocked and the timeout works (I'm checking bit0 of the returned value as the fw usually does). So, this one would be good for DryOS and open().

Perhaps I did not specify how is_video_recording() is acting on those few problematic DryOS models: it returns true when movie mode is active, regardless of the state of recording.
Furthermore, there can be ports where 'movie_status' was not found correctly...


*

Offline srsa_4c

  • ******
  • 4450
Re: issues with open() and fopen() while recording video
« Reply #18 on: 09 / June / 2014, 17:55:06 »
Turns out the value of 'movie_status' can be 6 on some models which pre-date the "movie digest" feature (sx130, s95 for example). It also seems like testers/users don't notice the inappropriate appearance of the CHDK "movie bitrate / remaining recording time" display - several ports would need CAM_HAS_MOVIE_DIGEST_MODE to correct that.
That means is_video_recording() can't be trusted enough to disallow file operations based on its value.
Next idea is to find the 'master semaphore' that blocks file operations...

*

Offline philmoz

  • *****
  • 3427
    • Photos
Re: issues with open() and fopen() while recording video
« Reply #19 on: 09 / June / 2014, 18:18:19 »
Turns out the value of 'movie_status' can be 6 on some models which pre-date the "movie digest" feature (sx130, s95 for example). It also seems like testers/users don't notice the inappropriate appearance of the CHDK "movie bitrate / remaining recording time" display - several ports would need CAM_HAS_MOVIE_DIGEST_MODE to correct that.
That means is_video_recording() can't be trusted enough to disallow file operations based on its value.
Next idea is to find the 'master semaphore' that blocks file operations...

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.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics