Forum Discussion
Storyline / SCORM: How can I check whether the cmi.suspend_data limit has been exceeded?
Hello everyone,
I am experiencing an issue with course resume/progress data in a Storyline module published for SCORM.
As I understand it, the information required to resume a course is stored in cmi.suspend_data, then sent back to the course when a learner resumes an incomplete attempt.
I also understand that the maximum amount of data allowed in cmi.suspend_data depends on the SCORM version being used. If this limit is exceeded, progress may no longer be saved correctly, and the learner may have to restart the course from the beginning.
My question is: How can I check the amount of data stored in cmi.suspend_data for a Storyline course?
Is there a way to do this in Storyline, in the LMS, through browser developer tools, or with an external tool, in order to:
- view the content or size of cmi.suspend_data;
- confirm whether the SCORM limit has been exceeded;
- identify which elements in the course may significantly increase the amount of suspend data?
I am also interested in understanding any differences between SCORM 1.2 and SCORM 2004 regarding this limit and resume behavior.
Thank you in advance for your help and for sharing your experience.
My question is: How can I check the amount of data stored in cmi.suspend_data for a Storyline course?
You can check the amount of data stored in cmi.suspend_data by adding a JavaScript snippet to your Storyline course and passing the result into a custom Storyline variable for display anywhere you want.
You can also log the suspend data and its length in the browser console using Developer Tools. As JudyNollet mentioned, the data itself is not human-readable because Storyline serializes and compresses bookmarking, variables, learner progress etc., into an encoded string.
However, you can measure its size using .length and display that value in Storyline. This is useful for monitoring how close you are to the SCORM 1.2 suspend data limit (~4096 characters). Once exceeded, bookmarking and resume functionality may stop working correctly. This is much less of an issue in SCORM 2004, which supports a significantly larger suspend data size.
In the example demo below, the course is published to SCORM 1.2. The JavaScript successfully detects the SCORM version and continuously retrieves the current cmi.suspend_data value and its length as the learner progresses through the course.
7 Replies
There is a big difference between SCORM 1.2 and SCORM 2004 3rd or 4th editions:
There are more details here: Storyline: Exceeding SCORM Suspend Data Limits.
As that article says, the debug log isn't "human-readable." It does offer a few suggestions for decreasing the size of the resume data needed. But if you're using SCORM 1.2, just switching to 2004-edition 3 or 4 should fix the problem.
Thank you very much for your answer.
That helps clarify the difference between SCORM 1.2 and SCORM 2004. I understand now that the suspend data limit is much more restrictive in SCORM 1.2, and that switching to SCORM 2004 3rd or 4th edition may be the best solution if the course is reaching that limit.
I’ll also review the article you mentioned to better understand how to reduce the amount of resume data generated by Storyline.
Thanks again for your help!
You're welcome. Pay it forward when you can. 😊
My question is: How can I check the amount of data stored in cmi.suspend_data for a Storyline course?
You can check the amount of data stored in cmi.suspend_data by adding a JavaScript snippet to your Storyline course and passing the result into a custom Storyline variable for display anywhere you want.
You can also log the suspend data and its length in the browser console using Developer Tools. As JudyNollet mentioned, the data itself is not human-readable because Storyline serializes and compresses bookmarking, variables, learner progress etc., into an encoded string.
However, you can measure its size using .length and display that value in Storyline. This is useful for monitoring how close you are to the SCORM 1.2 suspend data limit (~4096 characters). Once exceeded, bookmarking and resume functionality may stop working correctly. This is much less of an issue in SCORM 2004, which supports a significantly larger suspend data size.
In the example demo below, the course is published to SCORM 1.2. The JavaScript successfully detects the SCORM version and continuously retrieves the current cmi.suspend_data value and its length as the learner progresses through the course.Hello Nedim,
Thank you very much for your detailed explanation.
This is exactly what I was looking for. The JavaScript approach seems very useful, especially for monitoring the current cmi.suspend_data length directly in Storyline.
Would you be able to share your Storyline project file that contains this slide and the custom variable setup? It would really help me understand how you implemented. This would also help me take the same measurements on my side and check the suspend data size in my own module.
Thanks again for your help!
Sure. Find the attached .story file. In the Slide Master, you'll find several Execute JavaScript triggers containing the scripts. Disable one or another.
The first script is generally safe because it uses the official SCORM API discovery method defined by the SCORM standards rather than relying on Storyline-specific objects. It searches parent frames and popup opener windows for either the SCORM 2004 API (API_1484_11) or the SCORM 1.2 API (API), handles cross-origin security errors gracefully, then reads cmi.suspend_data and stores both the data and its length in Storyline variables. Because it uses the standard API names that LMSs are required to expose, it is more portable across different LMS platforms and less likely to break if Storyline changes its internal JavaScript objects in a future release.
The second script is more direct because it relies on Storyline's SCORM2004_objAPI object instead of searching for the SCORM API in parent frames or popup windows. It simply retrieves the value of cmi.suspend_data, stores the data and its length in Storyline variables, and logs the length to the browser console. While this approach is simpler and easier to read, it depends on a Storyline-specific object and therefore offers less portability than the first script, which uses the standard SCORM API discovery method. It only works for SCORM2004.
Let me know if you have any questions. You can always tag me here or contact me privately at mailto:nedim.ramic@gmail.com.
I also had an issue with this recently in a project that had thousands of variables. The quickest thing you can do to help is reduce the number of variables you have and also rename them with shorter names if possible as the variable name itself counts towards the suspend data limit.
With my project I've moved to a more JavaScript based solution that writes data to one variable that is holding data that used to be dealt with by lots of other variables. It did require a lot of re-working of the project but now I'm left with around 100 variables instead of thousands.
