Storyline file size

Really sorry for the trouble, Cameron!

A project file might not immediately shrink in size when you delete a video. Storyline keeps deleted assets temporarily after you delete them in case you need to click Undo to restore them. The good news is your project file will eventually shrink, usually after saving it a couple times. But you can also get it to shrink right away by saving and closing the project file, then re-opening it and saving it again.

I went through and tested the re-saving option on multiple files. I opened and resaved 6 times resulting in a file size that was no less than 2X the video file it contained. The only way to get it down to normal size was to import the scene into a new file, which is just too daunting of a task when you have 40 courses (all with individual story files/SCOs for each lesson) and a catalog of 100+ more courses on the docket to be converted out of flash.

I realize most companies will not have this large of a course catalog, but with companies that do, this is what we would call a "critical" or "game-ending" issue. And from what I can see this issue is 5 years old (according to other's posts).

We appreciate your given solutions, but as of right now they just aren't conducive to a large training department.

Wow Cameron, it sounds like you've been through the ringer to no avail.  As you mentioned, there have been a couple of other folks in this thread who've also found that the save-close-reopen-save trick didn't work for them.

The sticking point has been that we haven't been able to reproduce this behavior internally, and I can't see a record of where someone was able to share a file with us that exhibited these symptoms.

I understand you'd also rather not share your file, but since it's the best way for us to demonstrate the problem and document a defect, we'd happily accept a .story project shared here privately if you change your mind.

Our company conforms with export compliance laws and can't share data with foreign nationals (government contractor). Since we have no way of screening your employees, the best I can do is share a screenshot of the story file size and the video's size side by side.

Attached is a screenshot.

Thanks for that, Cameron.  The red exclamation point icon overlay is a little unexpected.  Is there a backup service monitoring your files?

You also mentioned that you are working out of a repository.  Does this mean that you are working from a network drive?  Does the problem persist if you try the save-close-reopen-save trick on your local hard drive?

I also wanted to share a link to our Trust Center, in case that might help with compliance concerns.  We have a mutual NDA that can be signed privately if you like.

Hi Justin. That exclamation point icon is just a TortoiseSVN marker saying the file is in a conflicted state (changed based on file size) . All the files are on local SSD's, and when we want to commit them to a network drive, we perform a separate upload. There is no network drive we are working off of or real-time syncing service being used. So when I say repository, its just files marked locally that we upload 1-3 times daily.

I will hand your white-paper, Security policies and NDA to our export compliance team, but without confirming citizenship of everyone who has access to where the files are stored, I doubt we will be able to send you any data. But, I will run it by them and see what they say.

This issue of Storyline (3/360) secretly keeping every deleted object and bloating the file size is difficult to deal with. It affects delivery quality (download speed). Working around it by carefully cropping files outside Storyline is time-consuming and annoying. Please develop an auto-purge of deleted objects at file save.  

Hi Tennille, 

Were you able to try the save-close-reopen-save trick on your local hard drive? I know that's what a few other folks have done to make sure all those assets were fully purged before the final save and publish. 

Hi, similar problem though happening from a different angle, I guess.

I've been focused on minimising the size of a specific output file when you publish for HTML5 (paths.js) as in testing the size of this file (and hence the unexpectedly long download time) was causing the course launch to time out within strictly managed networks.

So after publishing I habitually check the paths.js file. What I noticed was that when I imported all the slides into a new empty course (to shake off some file corruption that seemed to be creeping in - "this project is locked by another process") that paths.js file had dramatically increased in size from 3.2MB to 5.6MB even though nothing content- or navigation-wise had changed.

It's almost as if the import brought some large component of the existing information with it then "forgot" it had it and re-created it again. Digging a bit deeper I found some sub-files within the .story container itself that definitely contained "historical" content that was no longer in the course - specifically summary.xml within docProps. Further, that historical content was more than a few save, close and restarts ago, in fact it predated the import, so should presumably have been purged a while back?

Another interesting wrinkle is that the summary.xml file showed my slide and navigation count as 440 - exactly double the number of slides I thought I had!

Any thoughts?

Thanks

Matt

Hi Matt, 

That's quite the investigative work you've done! I appreciate you sharing here. I'll be sure to add it to the existing bug report that was filed in connection with your Support case.

Thanks, and we'll keep you posted with any developments on this! 

A pleasure Ashley - I have my courses pared down to a functional size now but if your team can figure this out and issue a fix I'm sure the courses could be even more responsive. Happy clients are the goal!

Matt

Just a thought in case it helps: a large chunk of the course I'm currently working on was originally part of another course created in Storyline 2, upgraded to Storyline 3, then imported into this new project so I didn't have to rebuild it. So it's a mixture of old, upgraded, SL2 slides and brand new ones.

Is it possible that there are enough differences in how SL2 handled publishing content for HTML5 (particularly text as that seems to be the root of my own situation) and SL3's upgraded handling that SL3 doesn't "know" what to do with the legacy SL2 information, so just leaves it as junk code in these files?

For a small course I can see that having a bit of unused code floating around that doesn't interact with anything wouldn't have any impact, but for very large, text heavy courses like mine it might start to manifest as a problem.

Matt

Hi Matt,

That's another good thought - and the HTML5 publishing methods from SL2 to SL3 (or SL360) were a total rewrite to support a broader HTML5 output. I wouldn't have thought that it'd carry over that old code too - but I'm far from a programmer or coder! I did share the update here with my team, so they'll use that info as they continue to investigate. 

Let us know if you stumble on any other tidbits! 

Hi Ashley,

A further tidbit as requested!

It's been happening for a while, but I hadn't made the (possible) connection to the current issue, where every time I open one of my courses for editing I get a warning about a missing font. Fair enough except the font it's warning me about is not used at all in these current courses! It was however used in some slides I imported from another project many moons ago before I changed the fonts to match the rest of the content.

It's got me thinking of two things:

1. This would seem to support my guess that SL3, at least in my case, is dealing with some historic data somewhere that isn't clearing properly. Unless there's another reason the programme might pop up that warning?
2. Is there anything SL3 does when it thinks there are uninstalled fonts that might be contributing? Perhaps it collects/generates more information in the paths.js file about the attributes of the text objects as a precaution - given the amount of text I have across the course even a small amount of additional code per line of text would multiply up rapidly.

Regards,

Matt

Hi Matt, 

There was an earlier issue where that messaging would appear in error, such as when the fonts weren't used, but that has been fixed in an earlier update of Storyline 3 and Storyline 360. 

I can't remember if we've checked that already, that you're on the latest update of Storyline 3? It would be update 4. 

I can definitely share the other tidbits with the team, and we'll keep you posted here. 

Hi Ashley, before embarking on the latest round of testing I uninstalled and reinstalled with the May 8th SL3 update so I'm on update 4: 3.4.15731.0

Matt

Thanks for the additional information Matt.

Hey Ashley, sorry my notifications for this thread were somehow turned off. Yes I can share a file, but I have tried ALL of the suggestions above and still no reduction.

Regards,

Justin

Hi Justin! We'd be happy to take a peek at your file. Click here to start a case, and be sure to let us know your case number so we can follow along. 

Hi, not sure if you are still having issues but i found the quickest way to reduce files size is to create a new, storyline project, and then using the Import function to import the old large project.

This just recently reduced a 50MB file for me down to 33mb.

I figure its only importing the used images etc and not keeping the ones I may have replaces or changed  (The same way deleting unused objects in Adobe Captivate works)

Hi Flynn,

That's really great to know! Thank you for taking the time to teach me something new about Storyline through the help post.

Wishing you great health,
David Brick
Sr. E-Learning Specialist
Stanford Children's Health

CONFIDENTIALITY NOTICE: This communication and any attachments may contain confidential or privileged information for the use by the designated recipient(s) named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or the attachments is strictly prohibited. If you have received this communication in error, please contact me and destroy all copies of the communication and attachments. Thank you.

Hi David, 

I'm glad that Flynn's share was able to help you out as well. I appreciate you popping in to share.

It looks like your email signature came through when you replied via email. You can remove that if needed by clicking ‘Edit’ beneath your response. Here’s a quick Peek video if you need help.

I am currently experiencing this issue. I have a file that unfortunately increased to over 200 mb! And now I cannot seem to reduce it.

I found that I had mistakenly imported three very large images (ca 80 + 50 + 50 mb). To tro to fix it, I used the "replace image" function in the media library, and replaced them with the smaller versions of these images. This however seems to only have increased the file size up to 207 mb in total! I used "save as", and a different version name - so I have both files to compare.

Then I also found tips here about starting a new file and importing the storyline-slides to, but that file also turned out to be 207 mb.

It seems these images (or something else) is stored and hidden in the file. I cannot keep working with it even, because it is so large and lagging the software.

What more can I try to fix this?

All .story files are saved on the local hard drive because it's best practice.