Due to continual spamming, forum registrations are now by Invitation Only. Hopefully this will be only a temporary measure to combat spammers.

If you want an invitation contact forumapplication @ camstudio . org

Sorry for the inconvenience.

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

Comments

  • Chris,

    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
  • I'm about to go into work and check that out. But I have a questions. Is the raw file the same as the temp file? I mean, the HDs have double digits gbs of space free.

    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.
  • Same issue occurred using xvid codec (recorded only 30mbs)

    Also, there are 60gbs available on the HD
  • LordAcoustic,

    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
  • @LordAcoustic

    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)
  • Hi,

    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
  • I managed to get a debug version of the Recorder built and I ran it with the debugger attached. After reproducing the problem several times, it looks to me as if the function CreateCompatibleDC, which is used in several places, is returning an error code just prior to the problem occurring. I'm not knowledgeable about the use of this function or areas related to it, so take what I'm saying here with some caution, because I may be misinterpreting what I'm seeing. But I thought I'd at least share what I think I'm seeing just on the off chance it might give someone else an idea that leads to a solution.
  • Hi @rfavero

    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)
  • I just looked in the code and, no excuse, but this appears to be a issue from the innitial version.
    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.
  • @Janhgm,

    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.
  • edited September 2010
    Thought this might help since I'm having a time-based crash at 589 seconds almost consistently. I'm running it on a Windows 7 machine with over 600GB free in the HD. I'm using CamStudio 2.6, Build on SVN release: r264.

    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.
  • @Janhgm,

    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
  • mlt
    edited September 2010
    It might be related to the fact that screen DC is never released at the end of Screen.cpp . See bugs 3075791 and 2548122 on sf.net
  • @mlt,

    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
  • Bugs fixes applied as r271
Sign In or Register to comment.