Storyline 360 - video replay's every time when we try to click on the seekbar in chrome

Hi,

Im working on a project where there are many video slides and few normal text slides. We have modified in such a way that the video slides has seekbar and i have enabled the seekbar so that the video can be moved back and forth. I have published the project for Scorm 1.2 and given to the client. The client had uploaded it in their LMS which is called as Success Factor. We are facing few problems when we run this project in chrome, IE 11 and Edge with Success Factor LMS.

1. The problem happens when the user tries to move the seekbar back and forth. When the user try and click any part of the seekbar, the video replays from starting. This problem happens only in chrome and the chrome version is "Version 67.0.3396.99 (Official Build) (64-bit)". 

2. In the project there are more than 1 video slides. Always the first video loads but the 2nd video doesn't load at all and we are getting a blank white screen and the seekbar moves. This also happens only in chrome.

3. Once the project is completed and when we try to review the entire project, the video gets loaded without any problem in chrome.

4. In IE 11 and Edge, if we try to click on the seekbar, the video doesn't replay but hangs for few sec and starts to play. But sometimes, the video gets frozen and couldn't able to move forward and this issue is random.

All the above issue happens only if the course is loaded from the client side LMS which is Success Factor.  I tried to upload the same course in scorm cloud and it worked perfectly in all the browsers.

So i need your advice on what will be the problem and how to solve it.

Regards,

Victor.

15 Replies
Alyssa Gomez

Hi Victor,

Thanks for reaching out and also for opening a case with our Support team!

You mentioned the content plays correctly in all browsers when you view the course in SCORM Cloud. When you click the seekbar to scrub the video, does the video then jump to the correct place? Are you seeing any freezing when you view the content in SCORM Cloud?

If everything plays smoothly in SCORM Cloud, then it sounds like the issue is related to SuccessFactors LMS. Have you had a chance to reach out to the SuccessFactors support team yet?

Leslie McKerchie

Hello Kathleen,

Thanks for reaching out and sharing what you are experiencing with your course.

I do see where we have a similar issue reported, but it is specific to publishing to Articulate Online and viewing the content in Google Chrome. Does that fit what you are experiencing as well?

If not, would you be able to share your .story file so that we could take a closer look? Just point us to the slide you're having difficulty with.

Leslie McKerchie

Thanks for chiming in and letting us know what you are experiencing as well Brett.

It sounds like you are running into the issue we have reported to our team, but I do not have an update to provide at this time. I will add this conversation to the report as we track users impacted and so we can share updates when we have them.

Steve Klingler

Tagging on to follow for a solution. This has come up in the past and been fixed but has re-emerged in the past few days, perhaps with the last update. Clicking anywhere on the seek bar causes videos to start over from the beginning and is then out of sync with other content on the timeline. This is impacting hundreds of users and making us and Articulate look pretty unprofessional.

Steve Klingler

FYI - From our testing it appears the 12/4 Chrome update broke the seekbar when the slide consists of an actual video and when the video is served over the network (works fine for "file://" references). It still works for the non-video content on the slide. They have been giving warning messages in the developer console for some time when playing Storyline content ... something about the December update will change how pages with audio will be streamed. I just blew it off as something that surely would not affect us... looks like I was wrong. Modern and Classic players are affected the same way. For now we added a browser detection to our site warning anyone running Chrome to switch to Edge or Firefox.

Steve Klingler

This one took me a long time to track down. I will try to keep the description short but let me know if you need more. It should be easy to replicate. We first noticed this when using Chrome following the Dec 4 patch. The platform is WordPress with LearnDash and the Grassblade xAPI Companion.

The problem manifests as mp4 videos embedded in Storyline restart at the beginning of the video when the user clicks anywhere on the seekbar/playbar if using the Chrome web browser.

After a lot of research we found that this is caused by the Grassblade Enable Content Security option. The fix is to disable that option (Grassblade / Settings / Content Settings / Enable Content Security). There are two reasons for this:

1) Function grassblade_security_check() returns the entire specified file without respect for the "Range" value passed in the HTTP request header, which is how video seeking works in HTML5.

2) This implementation uses an .htaccess file that is added to each xAPI module (Storyline project in this case) which rewrites the URL and causes Apache to apply caching rules and send HTTP response headers associated with .html files rather than the mime type of the requested file. Since default Apache applies "Cache-Control: max-age=0, private, no-store, no-cache, must-revalidate" to a collection of file types typically not cached (including .html) those headers are sent back for all file types including mp4. Edge and Firefox apparently ignore this and use the local cache anyway, and it seems Chrome did too until a recent update (perhaps the Dec 4 patch). If the client ignores the no-cache directive, then seeking happens locally without making a request of the server, which protects playback from being broken by item #1 above.

The bottom line is that in our case the issue is with Grassblade to fix and is not a Storyline bug. Others having this problem are likely affected by the same or similar cause.

Steve Klingler

In my opinion Chrome is actually the only web browser accurately respecting the Cach-Control header. When they "fixed" the browser it exposed a problem in our LMS (or more specifically the xAPI manager we use inside our LMS). If or when the other browsers comply they will behave the same way.

In our case the good news us that we found a work around and Grassblade has responded quickly with a fix I expect they will release soon.

Articulate could implement a simple test in the player or distribute a test project that easily tests for things like this and tells you if your server is misbehaving when playing their content, but otherwise the bug is not their problem to fix.