Large file freezes Storyline
Feb 19, 2013
I have a training program that requires 19 scenes each with from 60 to 100 slides. The final file size is 565 MB. Storyline got slower and slower as I added slides. At the finish it would take about 7 minutes to save and about 25 minutes to publish.
However, last week the file stopped opening. It would open partially and the scene folders would have the "mini" slides in them flashing randomly. Fortunately I had most of the scenes saved as separate files and was able to use the import feature to capture the rest out of the old file.
Is there any settings on my computer or in storyline that can help my system handle these large files? I have two more training programs after this of similar size I need to create.
7 Replies
Hi Stephen,
First, you may want to make sure you're working with only local files. If the files are located on any external sources, you may run into some trouble.
If you are experiencing unexpected issues using Articulate software, here are some tips for managing your files which can help prevent issues.
1. Work on your local drive (your C: drive). Working on a network drive or a USB drive can cause erratic behavior, including file corruption, loss of audio, and other unexpected behavior.
2. You should also make sure the directory path to your project files and your published output is less than 260 characters (for example C:\Articulate).
3. Avoid using special characters, accents or symbols in your file names.
Additional information regarding "Naming Files, Paths, and Namespaces" in Windows operating systems can be found in the following Microsoft article.
If the files are local, it may be an issue with the installation or the system, itself. You may want to try to make sure that there aren't a lot of programs running in the background. Can you give us a little information about the machine you're using (operating system, RAM, etc.)? Take a look at this knowledge base article on the minimum system requirements for authoring and viewing Storyline content.
Hi Stephen - I had this exact problem. I don't believe Storyline is capable of handling projects of our size, even following all the best practices that they suggest. There is no stated file size limit, but this has been my extremely difficult experience in practice - it just can't handle it. I ended up breaking things up so that each 'scene' was its own .story, and I used web objects in one overarching 'menu' .story to open each one as I needed it.
These are great thoughts as I'm beginning to experience similar issues with a .story file at 370,000kb (approximately 100 slides).
Nathan, FWIW, I ended up switching from web objects to JumpToURL, so I could use relative links. I lost some Table of Contents functionality, but it was worth the trade-off.
I know I'm reviving this thread, but have a related question...
Currently, I'm working on a project that has around 25 modules and 80 slides total, but the .story file is 1.25 GB. (lots of video)
I don't really anticipate needing to exceed more than 35 scenes and 150 slides total in any class, but we're soon making the switch to 720p HD video feeds. Thus, I do anticipate a huge increase in the file size... maybe even as large as 5-7 GB.
Has anyone else had experience with .story files of this size and any problems?
In these forums, I've found a few threads that note problems arising from very large numbers of scenes or slides in a single project, but not much regarding problems directly relating to file size.
Thanks for any input, just trying to anticipate any future problems to avoid loss of work
Hi Alex! That is a large file and hopefully you will hear back from others in the community on their opinions and experiences. There is also another thread here that discusses best practices for large files.
Hello, chiming in here because I'm working on a Storyline file that clocks in about 4 gig - and saving it currently takes about 15-20 minutes. (There are under 40 slides, but each slide contains video). Working within the Storyline file is sluggish (click and wait for screen to catch up) but doable. Clearly I need to do more compression on the video itself or use Rebecca's suggestion, because this is a major drag on efficiency.
This discussion is closed. You can start a new discussion or contact Articulate Support.