issues with open and fopen while recording video - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2] 3 4 5 6 7   Go Down

issues with open and fopen while recording video

  • 69 Replies
  • 17964 Views
*

Offline reyalp

  • ******
  • 13502
Re: issues with open() and fopen() while recording video
« Reply #10 on: 07 / June / 2014, 17:12:12 »
Advertisements
Quote from: srsa_4c on 07 / June / 2014, 16:29:44
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.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4430
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.
Logged
*

Offline philmoz

  • *****
  • 3356
    • Photos
Re: issues with open() and fopen() while recording video
« Reply #12 on: 07 / June / 2014, 19:03:24 »
Quote from: srsa_4c 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.

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.
Logged
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

  • ******
  • 13502
Re: issues with open() and fopen() while recording video
« Reply #13 on: 07 / June / 2014, 20:15:29 »
Quote from: philmoz on 07 / June / 2014, 19:03:24
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.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3356
    • Photos
Re: issues with open() and fopen() while recording video
« Reply #14 on: 07 / June / 2014, 20:58:44 »
Quote from: reyalp on 07 / June / 2014, 20:15:29
Quote from: philmoz on 07 / June / 2014, 19:03:24
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.
Logged
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

  • ******
  • 4430
Re: issues with open() and fopen() while recording video
« Reply #15 on: 08 / June / 2014, 09:45:06 »
Quote from: philmoz on 07 / June / 2014, 20:58:44
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.
Logged
*

Offline reyalp

  • ******
  • 13502
Re: issues with open() and fopen() while recording video
« Reply #16 on: 08 / June / 2014, 15:08:04 »
Quote from: srsa_4c on 08 / June / 2014, 09:45:06
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.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4430
Re: issues with open() and fopen() while recording video
« Reply #17 on: 08 / June / 2014, 17:40:04 »
Quote from: reyalp on 08 / June / 2014, 15:08: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...
Logged
*

Offline srsa_4c

  • ******
  • 4430
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...
Logged
*

Offline philmoz

  • *****
  • 3356
    • Photos
Re: issues with open() and fopen() while recording video
« Reply #19 on: 09 / June / 2014, 18:18:19 »
Quote from: srsa_4c 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...

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.
Logged
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)
Pages: 1 [2] 3 4 5 6 7   Go Up
« previous next »
 

Related Topics