Forum Discussion
end-user gets stuck, corrupt suspend data
Was hoping to hear from Articulate. Maybe they'll see this eventually and offer something. Suspend data length and SCORM 1.2 is not the issue; it is way, way under 4000 characters. I tried to figure out a way to inject the bad suspend data into a cloud.scorm.com session with the same course but I just couldn't do it; it is beyond my browser-developer-tools skills; I know how to do it with my LMS ;-) Add another plea to the pile: Articulate, please give us tools to work with the suspend data. Add it to the pile of the thousands of requests you've already gotten :-)
I'm not sure what you expect Articulate to be able to offer at this point. As you stated, "this is a random occurrence for the occasional user, for an occasional course. For almost all users this does not happen for a given course." I helped Macromedia isolate an obscure stack overflow bug in Authorware which had plagued them through 3 versions, over as many years, because the problem would only appear under very specific circumstances. It was only because I was unwittingly pushing the tool in that direction were they finally able to see the bug manifest itself reliably. In other words, blind luck.
You have likely eliminated the suspend data length and SCORM 1.2 as culprits. The fact that you have back-end access to your LMS' database introduces the possibility of different culprits, including your own internal network; how users are credentialed; how sessions are created, managed, and destroyed; and communications integrity between the LMS application, the course, and the database. Does IT employ network packet-sniffing/traffic-logging tools which could be impacting the data stream? A friend introduced me to the Charles Web Debugging Proxy, which can provide reams of useful data. There are other packet analyzers including Fiddler and Wireshark which could also contribute useful information.
We haven't even touched on how your course is developed, what Storyline functions and features you either are or are not using (and what you're replacing those with), file-naming conventions, the use of JavaScript, or how the output is stored on the LMS. We also haven't touched on your affected users' configuration. Are they on-site or remote? What OS? Desktop, laptop, tablet, or mobile? What other applications are they running when a course locks up? Any VMs in that mix? Are there cloud-based apps (like Teams, Citrix, Box, OneDrive, etc.) competing for network bandwidth?
Have you been fortunate enough to have the debugger running when this issue manifests? What do you see in that file?
