This forum software has now been archived into static HTML page (i.e. it does not function as a working forum anymore, so you cannot login.)
In due course a new forum will be available to help support newer CamStudio versions.
Sorry for the inconvenience and thank you for your patience.
In due course a new forum will be available to help support newer CamStudio versions.
Sorry for the inconvenience and thank you for your patience.
Possible Time Issue with Crashing
Hello All,
I'm using CamStudio (Beta) on two monitors under the following conditions (as recommended by Nick :) ):
Encoder: H.264
FOURCC: H264
Mode: one pass - average bitrate
Bitrate: 900 kbps
CamStudio Settings:
Quality: 70%
Set keyframes: every 30 frames
Capture frames every: 50 milliseconds
Playback: 20 frames per second
It seems like once the file size reaches 40mbs (around 30 minutes), the program crashes. The error message is the basic - CamStudio has encountered an unexpected error... blah blah blah... send error report?... blah blah blah...
I don't know what the issue is, but does anyone have any insight on what could be happening here?
Thanks,
Chris
I'm using CamStudio (Beta) on two monitors under the following conditions (as recommended by Nick :) ):
Encoder: H.264
FOURCC: H264
Mode: one pass - average bitrate
Bitrate: 900 kbps
CamStudio Settings:
Quality: 70%
Set keyframes: every 30 frames
Capture frames every: 50 milliseconds
Playback: 20 frames per second
It seems like once the file size reaches 40mbs (around 30 minutes), the program crashes. The error message is the basic - CamStudio has encountered an unexpected error... blah blah blah... send error report?... blah blah blah...
I don't know what the issue is, but does anyone have any insight on what could be happening here?
Thanks,
Chris
Comments
Everything seems to be set perfectly correctly!
My FIRST guess is that perhaps the hard drive where the raw files are being recorded to is running out of space (this is usually the Program Files>>Camstudio.xxx folder unless you have changed the recording folder in Options>>Program Options.)
Take a look there at the free space and let me know what's up (also check the drive where you are saving the final).
Terry
We've tested it a couple of different ways. Let me give some examples and context to our tests and our results.
The context:
We are running three separate instances of CamStudio on three different computers with dual-monitors. These computers are not connected to the internet, but I installed vcredist_x86.exe. We've set the hot keys of cntrl-option-shift F8 to start recording and cntrl-option-shift F9 (Don't think that matters too much). We have the program minimizing when recording starts and it automatically saves the file when the recording stops in accordance with the date/time.
Test 1:
Recording on all three computers stops simultaneously around the 40mb point. It gives the "CamStudio has encountered an unexpected error/send-don't send error report" error.
Test 2:
Recording on one computer stops at the 30mb point with the same error.
Test 3:
Recording on all three computers, but only one computer gives that same error message.
Also, there are 60gbs available on the HD
This is very mysterious! I have never seen this crashing at 30-40MB effect before.
Allow me to summon my fellow wizards for a consultation about this one.
"Oh, fellow wizards?! Could you take a look at this one for me? I'm completely stumped!"
There. That should do it. We should have your solution very soon now.
Just one question: Have you tried this with the Camstudio Lossless codec or even the "built-in" MS Video Codec?
Terry
Just out of curiosity, what are your audio settings and what pixel area are you recording, dimension-wise?
And I'll second Terry's question whether you've had this happen with MS Video 1 and CamStudio Lossless codecs ...
Cheers
Nick :o)
Just wanted to add my experiences to this discussion. I've experienced the same (or similar) problem. I've found it very easy to reproduce. The point at which the failure occurs is not consistent, but the crash occurs after many minutes of recording (5 -15 minutes). I've had it happen with both MS Video 1 and Xvid. The disk where I'm having the temporary files written has many Gbytes of free space, and my biggest file when this occurred only got to about 534 Mbytes. I tried to download and build the Recorder yesterday from the SVN source on SourceForge, but there seemed to be some #defines missing and maybe some other things, so I gave up. I was hoping to build a debug version that would generate .pdb file(s) so I could run the Recorder with a debugger attached to see if I could figure out what is wrong. If someone could build a debug version for me and make the executable(s) and .pdb(s) available as well as a zipped copy of the source code used for the build, I could try running under the debugger and see if I can uncover anything.
Thanks.
--Rob
Thanks for posting your results, I'll pass this over to Jan to see if he can take a look at it.
Cheers
Nick :o)
We have to improve it.
It appears that there is no solution in place in case CreateCompatibleDC fails.
The required code change is to add a few defensive code lines on many places:
HDC hdcMem = (HDC )0;
hdcMem = CreateCompatibleDC(yyy);
if (!hdcMem)
{
DWORD err = GetLastError();
}
Also we should check if it call DeleteDC to drop the virtual device memory. Don't know if that is always done either.
@Rob,
"but there seemed to be some #defines missing and maybe some other things"
Which ones did you missed, I thought I had solved them all a while ago.
The defensive code lines are necessary, as you point out, but by themselves I don't think they will take care of the problem. Of course they may be a step toward solving the issue. My assumption is that earlier versions of the Recorder did not reach a point where CreateCompatibleDC was failing, so the lack of the defensive code did not matter. But of course, that's only a guess.
Also, It did look to me as if DeleteDC is properly being called when necessary (that's one thing I did end up checking). There are two versions of CreateCompatibleDC. One is a global function, which requires a corresponding call to DeleteDC once the created DC is no longer needed. The other is a member function of an object, and when the object goes out of scope, the destructor of the object takes care of calling DeleteDC. At least that's my understanding.
When I finally got a debug build to work, the only things missing were some #defines, and then also there was 1 #define that had a value that was the same value as another and they collided, because they were used in the same "context". I did not keep a list, so I'll have to regenerate that information. Hopefully I can get that on Monday.
Here's the recording settings that show up in CamStudio right when it crashes (I have a screenshot but can't post it here):
Start recording: 20100919_2341_07
Limited recording: Off.
Current Frame: 117809
Current File Size: 332.28 Mb
Actual Input Rate: 16.74 fps
Time Elapsed: 589.05 sec
Number of Colors: 32 iBits
Codec: CamStudio Lossless Codec v1.5
Dimension: 640 X 385
I use that dimension since I read that YouTube is going (or has gone) to that as their default 16:9 size. Also, I have it set to record audio from my microphone, but the mic is off, so no audio was being recorded at the time. I have not tested it using audio recording as well.
As it is, I have to use CamStudio 2.0 to get things recorded, but it doesn't give me the feature of highlighting clicks which I would love to have.
The thing that seemed to be missing was #defines for the build of Recorder. I was using revision 269 to do my build. I had to define the following to build successfully:
IDC_BUTTONLINK3
IDC_BUTTON_XNOTECAMERADELAYMODE
IDC_BUTTON_XNOTEDISPLAYCAMERADELAYMODE
IDC_BUTTON_XNOTERECORDDURATIONLIMITMODE
IDC_BUTTON_XNOTEREMOTECONTROLMODE
IDC_EDIT_XNOTERECORDDURATIONLIMITINMILLISEC
IDC_FORMATTIMESTAMPPREVIEW
IDS_STRING_MOVEFILEFAILURE
ID_CAMSTUDIO4XNOTE_WEBSITE
IDS_STRING_FILECREATION2
Also, when Recorder.rc tried to build, it complained of duplicate values. I found that the following 2 #defines in resource.h were present with the same value:
#define ID_OPTIONS_NAMING_ASK 32903
#define ID_XNOTE_RECORDDURATIONLIMITMODE 32903
I changed one of them to a different value and the build then worked.
--Rob
Good catch! I've made the change you describe in bug 3075791 in the copy of code on my machine, and the problem has disappeared on my machine. I've run Recorder without your change multiple times today, and with the settings I'm using, the process crashes in well under 10 minutes. I've also run multiple times with your change in place, and the process has not crashed, even though I recorded for over an hour in one case and for over 30 minutes in another.
Since this was a memory leak, the length of time it would take to manifest probably would vary considerably from one machine to another, depending on the amount of memory on the system and how much else was running on the machine. I draw this conclusion, because the documentation for GetDC says, "The number of DCs is limited only by available memory." Of course, running Recorder under similar conditions on a given machine would have resulted in failures occurring after about the same amount of time into a recording, which is consistent with the title of this forum thread.
This was a serious problem, so this is good news.
--Rob