Long save/preview/publish times

I've noted some people describing lengthy times with Storyline 2 for saving, previewing, and/or publishing.  We are experiencing the same problem, but ours seem much greater than what others are reporting.  I timed a save yesterday, and it took twelve minutes and twenty-eight seconds to complete (completion being the point at which the save message and blue bar disappear, and control of the program is returned to the user).

Noting the system requirements for SL2, we meet or exceed all requirements.  When performing a save/preview/publish operation, SL2 seizes considerable system resources, to the point that it is impossible to even switch to another open application until it is done.  Resource monitoring shows that, even with physical memory still available to the program, hard disk I/O operations during a save go through the roof.  Hard disk fragmentation is at 0%, so that can likely be eliminated as a cause.

This is not a very large project, only 34 slides across six scenes.  Of possible note is that this project was converted from SL1, but similar Community posts make our times seem extreme.  Has an issue been identified here?

8 Replies
C. L. Norman

We did try importing a slide into a new file, but we were still seeing delays (my supervisor tells me she is accustomed to a two to three minute delay with any project saved).  The delays were much lesser with smaller projects, obviously, but as we added slides and assets to the file, the delay grew exponentially.

I did review the "Unexpected or Erratic Behavior in SL2" post earlier in the week.  We've tried all but the third option—we didn't pursue that one since we're seeing the same problem on different computers/operating systems.  While working on repairing one project today, I've noticed that changes seem to be also adding to the application response time (ribbon items are slower to change, image crop previews are taking longer to update, etcetera).  This would make me think memory leak, so I'm going to try to keep my eye on that as I continue working.

Mike B.

Well that sounds like it's probably your problem then.

I just created a test project and dropped in a video (we normally embed from a streaming service instead). Saving the file to my super-fast solid-state harddrive took 25 seconds, and the resulting file size was 360MB. Keep in mind that I'm running on a very high-end PC that cost $4K about 2 years ago.

Embedding videos from a streaming service prevents all that data from being saved inside the project file. You might have to upgrade your PC, or figure out a different way to create your projects, unless there is something else going on that I'm not seeing.

C. L. Norman

I don't believe use of a streaming source for videos is allowed with our particular LMS (and frankly, I'm not sure our management would be comfortable with our proprietary information being in the hands of a third party).  As our media assets are already optimized, I don't know that we could improve on that optimization enough to make a significant difference.

May I ask what size and type the source video you placed in your test project were?  Any other technical details (compressor, muxing method, etcetera) would be most appreciated for comparison against ours.

Mike B.

You might look at the Wistia streaming service. They do let you lock down your content so that it can be accessed from only specified domains. They have a free trial, if you have time to check them out. Just keep in mind that you may have to make changes to your course as a video embedded this way does not lock to the SL timeline, which can be a good thing depending on what you're doing. :)

I had dropped in a 1 hour, 1GB, .wmv file, 640x360 @15fps, rendered out from Sony Vegas Pro. Let me know if you need any other details.