As a follow up to my last post....my Adobe Captivate 4 project contains 80 slides.
I experimented a bit and previewed the first 50 slides by selecting Preview defaults: 50 under the Edit and Preferences menu
- Both the "Advanced project compression" AND "Compress SWF file" buttons were checked,
it took approx. 18 minutes for the show to begin
- Both buttons unchecked, it took approx. 2 minutes for the show to begin
- "Advanced project compression" unchecked and the "Compress SWF file" checked,
it took approx. 15 minutes for the show to begin
When previewing the entire 80 slide project with both buttons checked, after 4 minutes, the project stopped generating "Progress: Writing SWF File Tags to Stream" and the message, "Error Your computer does not have sufficient memory resources to perform this operation. Do the following: - Check one or more options in the Externalize Resources list, and re-publish. - Close other applications open on your computer. You might have to close and reopen Adobe Captivate before publishing the file. <<I had no other applications open on my computer and I wasn't trying to publish this project, just preview it>>
When previewing the entire 80 slide project with both buttons unchecked, it took approx. 6 minutes for the show to begin
When previewing the entire 80 slide project with "Advanced project compression" unchecked and the "Compress SWF file" checked, after 15 minutes, the project stopped generating "Progress: Writing SWF File Tags to Stream" and the message, "Error Your computer does not have sufficient memory resources to compress the SWF file" displayed
I understood your concern.
The reason is " When you externalize resources, they reside outside the swf file and are referencedfrom within the file when published.
So what you need to do is
Click on Edit on the top file menu, then go to Prefernces> Project > Publish Settings (under PROJECT) > Externalize resources and select the third option FMR SWF. Click OK and then Publish
I hope it will work. Waiting for your reply.
Hi, I had the same problem and fortunately i had a meeting with the Captivate team that helped me to "fix" it.
If your computer is powerful enought, you should be able to finalise your project. Captivate 5 is not perfect (but still one of the best in the market so far), so when I work all day on the software, it becomes "lazy". When I'm about to finish a project, I always have to close Captivate and then re-open the all application with my project, then launch the export. If it does not work, I fixed it by retarting the computer. It's not the best way but it worked for me!
Vish and ChimenceSE,
Thank you for the quick replies.
I selected the third option of clicking on FMR SWF as Vish suggested and had both the "Advanced project compression" and "Compress SWF file" buttons selected. After 30+ minutes of clicking the "Preview" project button, this worked. It took much longer than I expected, but it worked. Should I always have the FMR SWF clicked as a best practice? Should I do this for Widgets and Animations also?
I then wanted to send it to my supervisor for review. When I clicked on "Publish" and then "Review" it began to precess but then froze up again with the message "Error Your computer does not have sufficient memory resources to compress the SWF file."
At this point I followed ChimenceSE's advice and completely shut everything down, booted up again with only Captivate running and was able to create the review files after 30+ minutes.
Although this moreorless worked, is there anything I can add hardware or software wise to my computer to make this happen quicker and while I'm able to do work with other software at the same time? Completely shutting down everytime I need to do this will cause many problems with other things I am working on at the same time.
Thanks again and please advise,
When you publish a project as a SWF file, a single SWF file is produced.
To reduce the size of the SWF file, you can choose to externalize some of its objects (skin, widgets, FMR SWF file, and animations).
After publishing, the externalized resources reside outside the SWF file, and are referenced by it.
SO what you can do is first Go to prefences, select the apprpriate option in EXTERNALIZE RESOURCES and then publish it. So you will not face this again in your future. For small SWF files even if you don't choose any option, its OK , however for large SWF files you need to choose FMR SWF option.
By doing this you will get rid of shutting all programs or rebooting etc...
1) When you need to preview/publish the file intermediately i.e. when you are mid-way authoring your project or want to send the project for review, follow this to possibly avoid this issue:
(i) In the preferences dialog at Project -> Publish Settings, check all the checkboxes under 'Externalize Resourses'.
(ii) In the preferences dialog at Project -> SWF Size and Quality, uncheck these checkboxes : Advanced Project Compression, Compress SWF File, and Compress FMR SWF file.
2) When you need to publish your project for the FINAL time i.e. for deployment, follow these steps to possible avoid this issue:
Re-start your machine - Make sure NO un-necessary programs are running (especially any back up generation software) - Launch Captivate and open your project. Now:
(i) First, in the preferences dialog at Project -> SWF Size and Quality, uncheck these checkboxes : Advanced Project Compression.
(ii) If you still see the issue then, in the preferences dialog at Project -> SWF Size and Quality, uncheck these checkboxes : Advanced Project Compression, Compress SWF File and Compress FMR SWF file ( if you have FMR swfs in your project).
(iii) If you still see the issue then, follow step (ii) and in the preferences dialog at Project -> Publish Settings, check all the checkboxes under 'Externalize Resourses'.
Do let me know if these steps helped you resolve your issue.
Has this been addressed in CP 6? I'm still restarting constantly with video heavy lessons... as well as bypassing compression. Seems pretty important that we get this worked out. Students like media.
Maybe you just need to make your video a little less 'heavy' to reduce load on the app.
Well... we're in an HD world now, and that's the compressor's job. As demonstrated by the recommended fix (disabling all compression), Captivate is currently great at making enormous uncompressed files, but a Shockwave file's main strength (in my opinion)- presenting low drag media, seems to be missing from Captivate when dealing with HD video for use in HD training projects.
If you're talking about HD video clips that you've added into a Captivate course, I think you misunderstand how Cp works.
Video files (FLV or F4V) in Captivate 5x are always externalised. So when you publish a Captivate 5 project, you're not compressing the FLV or F4V at all. You're only compressing the SWF containing whatever (non-video) objects you added to the stage.
So if you're adding HD video clips using Insert > FLV or F4V, or Insert > Slide Video, or Video > Insert Slide Video, it's ALL going to be externalised video that is unaffected by Captivate's compression.
What format are you publishing to? HTM/SWF or something else?
I’m creating SCORM 2004 packages. It seems strange that it will publish fine without .swf compression when large videos are present, but when I add .swf compression publishing fails… if the videos are always externalized. By that logic, the result should be the same whether I compress or no… since it isn’t really doing anything to the external video.
Your issue with the compression might have nothing to do with the videos. There may be something else in your project that is causing it to fail at publish time.
You need to try hiding slides and republishing with compression on to track down where the troublesome object/s are.
Nope…. I’ve published many many sessions for this client, and the few that have over 100 meg of video fail unless I turn compression off.
You mentioned that you are creating SCORM packages. Does this mean you have the Zip option turned on when publishing? Does publishing still fail without this option on? I'm wondering whether the failure is caused by attempting to compress already compressed files.
If you have 100 megs of video file, Captivate will attempt to copy these videos into the publish folder when publishing. The sheer size of these files might be causing something to malfunction. For example, if the files already exist in the same publish folder location from the initial publish action, then this might be triggering some issue (normally you'd be prompted to specify whether the existing files should be overwritten). What happens if you remove the previously copied video files from the publish folder so that there are no files there to be overwritten?
That’s an excellent point, Rod. By the way, I use nearly all of your products… Thanks for the excellent widgets.
Still, Zipping is a necessity for import into my LMS. Even if it works, the solution won’t do me any good. It would be good to know though. I’ll check soon.
What I'm suggesting is that if you find the Zip function is part of the issue, you can always zip the SCORM packages AFTER publishing so as to remove this problem from the equation. All you need to remember is that when you zip the SCORM package using Winzip (or whatever utility you prefer) you need to do it from INSIDE the SCORM folder created by Captivate, not just by selecting the published folder and zipping that. When you upload your SCORM zip to your LMS, the LMS will need to find your imsmanifest.xml file at the root level of the zip, not one level down inside another folder, otherwise it will reject the SCORM.
I have this problem and was told that it is a known bug that is being investigated. It is a little disheartening then, to see that this has been an issue since 2010. All kinds of solutions were offered to me, including upgrading to Cap 2017 with the caveat that I may lose my project so "back it up". Not a confidence builder. I discovered after a few hours, that I could make all my changes in the original PPT deck, save the changes, close PPT. Open Cap, attempt to update, get the error message, say okay and the update would successfully complete - but only in Cap 9, not 2017. I opened Cap 2017 by accident one morning and when I closed it and opted not to save, my system crashed - blue screen data dump. No harm done, but won't be using 2017 and will be looking for alternatives to Cap in the future.
I have a few questions for you:
- Are you launching Captivate with Run as Administrator privileges?
- Are you working on CPTX files that are stored on a network drive rather than your local C drive?
- Have you tried watching the RAM usage for Captivate.exe in the Task Manager to see if it is climbing when you are working over a number of hours? If so, it may be reaching a point where there is not enough RAM on your system and the OS self-protects by crashing Captivate.