Resume Presentation in LMS not always working

Hi Brian,

Thanks for the reply to my posting!  I'm in the process of checking with my LMS, but I have a feeling that SCORM 2004 is not an option with them . . . otherwise I'd try your suggestion.

I'm a real idiot when it comes to this technical stuff . .  so my apologies.  But I have the option of pulling suspend data from my LMS and all of them that I pull. even for my longest presentations are relatively short.  Here's an example of one that I pulled: 

Hi Steven,

Suspend data won't necessarily be long based on the number of slides. What can throw a lot of information into the suspend data is Engage interactions and Quizmaker quizzes, especially the quizzes. So what you would probably want to do is figure out exactly where someone who is having a problem exited the quiz and see if you can repro.I would also suggest testing your content outside of your LMS in SCORM Cloud so you can really drill down on the debug logs that SCORM Cloud provides.

http://www.articulate.com/blog/9-ways-to-troubleshoot-articulate-lms-issues/

If you want, feel free to send us your project files with as much detail as possible here:

http://upload.articulate.com

If you want, let me know what your case number is and I can personally take a look for you and see what I find.

I have this exact issue. One thing that I notice in the suspend data string when this occurs is that the front part of the string retains the "viewed=" information but the back part of the string overwrites the completion status (represented by a series of the number "7".

In the case of your data string, it is showing 19 slides viewed, slide 9 as the last viewed (when exited or as currently in the course), a 9# representing the count of slides not showing up as not yet viewed (the numbers after the ## - remember "7" indicates the slide has been completed, the 15 represents some sort of progress made on that slide, and if you count the sevens and the 15 you come up with 9 slides), the ones ("1") represent the slides marked as not yet viewed. Question is, how can this be if the front part of the data string shows they have been viewed?  This is where I am perplexed and need to know how these slides' status is changed and how we can fix it so that these end of string numbers are not overwritten with ones ("1") as this is what the LMS reads to put a student back to a point in the course. In this case, I would bet that the student in the string below would be taken back to slide 9 rather than where they wish to be on slide 19, right?

viewed=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19|lastviewedslide=9|9#1##,7,7,7,7,7,7,7,7,15,1,1,1,1,1,1,1,1,1,1,1,1#0##-1

Any help in fixing this is much appreciated! As terrible as this issue has been, it's comforting to know that I'm not the only one to have experienced this.

Hey Aaron,

If you have a 19 slide quiz, you view all 19 slides, then navigate back to slide 9 and exit, on resume of the course we will return you back to slide 9, but that shouldn't affect the view states of any of your other slides.  We return you to slide 9 because that is where you left off the presentation, but on resuming it will show you visited all 19 slides.

I wouldn't look too much into the meaning of what is after the lastviewedslide=9 part because that more has to do with the state of the navigation elements (like if a level should be expanded and what not).

So if you have a course where the resume isn't resuming properly consistently, here is what I would do

1. Upload your course to http://cloud.scorm.com

2. See if the same thing happens

If it doesn't, my guess would be that the LMS isn't returning the same data it was sent for suspend_data.  Unfortunately we see this sometimes from learning management systems, and it can be any number of things, like the LMS not supporting the minimum SCORM standard for suspend data (4096 characters), or any other number of things.

If it does also happen at http://cloud.scorm.com as well I would create a case with our support department and have them look into it more or log a bug.  We should be able to figure it out.

-Dave

Thanks, Dave.

I have gained the same understanding that “lastslideview=” does, in fact, mean the slide that the user was on when they exited, not a representation of the furthest point along in the course that the user achieved. The problem is, that upon exit and resume, somehow the status of the slides viewed is being affected.

Even in a 19 slide course where the user exits on slide 19, the end data in the string (the stuff that you are stating shouldn’t be looked at too closely) is changed from a status of “7” (repeated 19 times) to “1” (repeated 19 times) and the "lastslideviewed=" changes to a "1" as well.  This results in the user starting over at the beginning of the course, despite exiting on slide 19 and the “viewed=” data showing the furthest progress at slide 19.

Why does this data change from "7" to "1" and how can this be stopped? I believe that the end part of the string is what the LMS is actually looking at, not the number displayed after "lastslideviewed=" but either way, the lastslideviewed=" seems to be pulling its information from the tail end of the string as well and it is the tail end of the string that is different in every case where this occurs. Where a student is successful in resuming, these numbers are always "7", where they are not, these numbers are always "1". And in both cases, the beginning of the data string correctly shows the "viewed=" as a series of numbers that increase in increments of 1 up to any point in the course, including the final course slide.

Our LMS does support the 4096 character limit for SCORM 1.2 and the SCORMFunctions.js file has been modified so that it compresses the data to within the 4096 limit on courses that are longer in duration and which would normally exceed the limit (resulting in the lastslideviewed= always returning the same response once that point in the course is reached, regardless of the additional slides viewed).

Any more thoughts?

Regards,

Aaron

Hey Aaron,

Ok, so it sounds like you can reproduce it consistently?  If your LMS does support up to 4096 characters that is good to hear, we just ran across a case earlier this week where the users LMS was only supporting 256 characters and a similar issue would happen.

I would be really hesitant though to modify the SCORMFunctions.js to further compress our data...unless I guess you are uncompressing it when it returns?  Reason I say this is our player relies on the data being the exact same as what is sent, otherwise we don't know how to properly resume.

I would still try to see if you can repro it on http://cloud.scorm.com, and if you can, great, log a support case and we can dig into it further.  We will probably want to get your project files here so we can debug.

>I believe that the end part of the string is what the LMS is actually looking at, 

I am a bit confused at this though...what do you mean the LMS is actually looking at?  The suspend_data needs to be returned EXACTLY as it is sent (the entire string) for it to resume as it should.  If it doesn't then all bets are off.

Also, just so I am clear, your issue is that:

1. A user takes the course

2. User goes to through entire course to slide 19

3. user launches course again and selects to resume

4. User isn't returned to the correct spot?

-Dave

Hi Dave,

I really appreciate your attention to this issue.  You are correct in your clarification of our issue but it's not always the same spot in the course where this issue occurs.  Here's a clearer picture.

The user takes the course

The user goes through the course to a point where they determine they want to exit and resume at another time (could be slide 19, 153, 260, etc.) - the course where this most frequently occurs is 262 slides in length and contains 21 separate quizzes.

The user launches the course again and selects to resume

The user is returned to slide 1 (not the incorrect spot - i.e. not slide 12 if they were on 53 or not slide 92 if they were on 184 - it's always 1).

We do compress our data and it is decompressed when it is returned so that when the student reenters the course, it will take the student to the correct spot in the course (for 98 percent of our students). For some reason, some of our student's data has the tail end of the data string overwritten with "1" rather than the "7" that exists prior to their exit. We can track their progress through the course and see that the data string shows a "7" as the course advances from slide to slide. This all changes when they exit and results in a resume from slide 1.

Thanks,

Aaron

Hi Dave,

I forgot to answer your first question regarding reproducing the issue consistently. We are not able to reproduce this issue consistently at all.  It's a very spotty and random occurrence.  Here's the general process that occurs.

1. Student contacts us to let us know he/she was in the course and exited at slide ### but resumed at slide 1.

2. We check our LMS to confirm the student's progress and find that the student has, in fact, viewed slide ### as stated.

3. The suspend data string also shows a slide status of "1" for all slides (despite the viewed= showing slide ###).

4. We login as that student and response "Yes" when prompted to resume.

5. We are taken back to slide 1.

6. We can painfully and slowly work the student back to slide ###, exit and resume on slide ### (the way it's supposed to work).

7. We contact the student and they are then able to resume the course from slide ###.

We were concerned that the students were selecting "No" upon resume but have tested this with our students and they are correctly selecting the "Yes" option.  Furthermore, we noticed that the selection of the "No" option when prompted to resume clears all suspend data (including the "viewed=" information. So there's something going on that is causing the viewed= information to be retained but the slide status to be reset to "1" when some students (about 1 or 2 out of 100) select "Yes" to resume. For all other students and administrators this all works seemlessly and makes it difficult to reproduce. But, with over 100 students in the course each day, we are getting 1 or 2 of these every day and would like to find the cause and solution sooner than later.

I hope this additional information is helpful.

Thanks,

Aaron

Hey Aaron,

Thanks, I haven't had time to dig into this yet as I have some meetings this morning.  My schedule will hopefully open up this afternoon and I can revisit.

We also got your support case, but the delay in responding to that is on me right now as well.

I'll get back to you ASAP.

-Dave

Hi Dave,

I ran across this article regarding the cmi.core.exit data and it has a different process than we use when we replaced the SCORMFunctions.js file with our version that allows for suspend data compression (I was not the one that made the modifications to the SCORMFunctions.js file so not clear as to what changes occurred in the script).

The article may be found at: http://www.articulate.com/support/presenter09/kb/?p=1022

The last piece of this article reads,"To work around this issue, do the following:" and is a different process than we use to replace our SCORMFunctions.js file when we publish.

Our process is to publish the course and, prior to zipping the file, I navigate to the file path where the course was published, locate the "lms" folder and replace the existing SCORMFunctions.js file with the updated version that fixes the 4096 character limitation by compressing the data. Then I zip the file into the same directory where I published. I then upload the zip from this location into our LMS and in all testing this worked out just fine.

The process outlined in the article above, though not exactly our issue, states to backup the SCORMFunctions.js file from three locations (Presenter, Engage, Quizmaker) and replace with the new SCORMFunctions.js file that fixes the bug in Moodle 1.9.5 (not our version but neither here nor there since our new SCORMFunctions.js file is not attempting to resolve that issue).

Could the process I use to replace the SCORMFunctions.js file have something to do with this?

May I need to follow the steps outlined in the article to avoid the process that I go through - so my version of the SCORMFunctions.js is the version stored in the Articulate directory on my local drive? Effectively this might allow me to just publish and zip the course into a directory without having to replace the SCORMFunctions.js file on each publish - saving time for sure and perhaps having a positive affect on our resume issue.

Thoughts?

Thanks,

Aaron

Hey Aaron,

Ok, there are several issues here, so I'll try to address them one by one.

1. Student re-launches course and selects "YES" to resume, and is taken back to slide 1, if this isn't where they are left off.

If this is happening, then it definitely sounds like a bug.  In order to confirm that the bug is on our side though, we would definitely need to get a reproducible case using an unmodified SCORMFunctions.js file without your compression changes.

Here is how you can try to do that:

1. Find a student that experienced this problem
2. Look at the suspend_data for this attempt in the LMS
3. It should show you the slides that were viewed, and the last slide that was exited on
4. See if you can reproduce the issue by viewing the same slides they did then leaving off on the same slide mentioned in the suspend_data

My guess is at this point you will be able to reproduce it.

Next:

1. Try to reproduce it again without using the modified SCORMFunctions.js that contains your compression
2. If you can reproduce it great, get us the file and we can try to reproduce here
3. If you can't, my guess is the compression scheme is causing the issue

2. >We were concerned that the students were selecting "No" upon resume but have tested this with our students and they are correctly selecting the "Yes" option. Furthermore, we noticed that the selection of the "No" option when prompted to resume clears all suspend data (including the "viewed=" information. 

If a student launches a course and selects No to resume, we will wipe out the previous suspend data, because you chose not to resume.  In this version of studio we don't have a "Forced resume" option, but it will be coming in future products.

3. >The article may be found at: http://www.articulate.com/support/presenter09/kb/?p=1022

Yep, if you follow the steps in that article you will always publish with the modified SCORMFunctions.js file, so you don't need to replace after each publish.

Could the process I use to replace the SCORMFunctions.js file have something to do with this?

The process that you are using to replace the file wouldn't cause any issue.  Essentially when you publish to SCORM, the file is copied from C:\Program Files\Articulate to the output folder, we don't modify it at all.  The fact that you are replacing it might be causing an issue though.

But if you follow my instructions above for issue 1 we can at least try to eliminate that as a possibility.

Ok, I think I covered everything, let me know if I missed anything.

-Dave

Hi Dave,

Here's what I was able to do, though not exactly in line with your steps. Because the course is being accessed by numerous students at this time, I am not able to republish, post and have a student access and experience this issue. Furthermore, we have already identified that with the original SCORMFunctions.js file, the resume data would timeout at 4096 characters and this affected ALL students. The course would only record the student's suspend data up to a particular point in the course and nothing beyond. This was our entire reason for the new code. So, with the new code in place and a student that experienced the issue, here's what I've found. Doesn't it seem strange that I would be able to get to the same slide the student did and the LMS would properly record and read the suspend data without making any changes to the SCORM? Would it be helpful if I provided you with the SCORMFunctions.js file that I am using?

I hope the testing below proves helpful. Thanks again for your time!

Using our SCORMFunctions.js file that compresses the suspend data so that we are able to resume on our longer courses, I am providing an example of the data string at various places in the course to demonstrate how the data string changes along the way from the point where I am notified of the student’s issue.

Suspend data prior to entry into course where student has reported issue. Notice the viewed=141 and the “1” sequence at the end.

cmi.suspend_data => viewed=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141|lastviewedslide=1|0#1##,11,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1#1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1##-1

Suspend data after reaching slide 59 while logged in as student and manually moving student through course. At this point in the course, my computer froze up and I was forced to exit (but I had another admin login as the student while I exited and re-entered so as not to lose my progress). Notice the viewed=141 and the “1” sequence is changing to “7”.

cmi.suspend_data => viewed=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141|lastviewedslide=59|59#1##,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,15,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1#0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1##-1

Suspend data after reaching slide 108 while logged in as student. Notice the viewed=141 and the “1” sequence now represents accurately the number of completed slides in the course.

cmi.suspend_data => viewed=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141|lastviewedslide=108|107#1##,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,11,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1#0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1##-1

Suspend data after barely reaching slide 121 while logged in as student. My computer froze no more than a couple seconds in – probably the reason the data string is reporting lastviewedslide=120 – and I was forced to exit (but, again, I had another admin login as the student while I exited and re-entered so as not to lose my progress). Notice the viewed=141 and the “1” sequence now represents accurately the number of completed slides in the course.

cmi.suspend_data => viewed=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141|lastviewedslide=120|119#1##,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,11,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1#0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1##-

Upon reaching slide 141 under the student’s login, I exited the course and then went back in to resume, selected “Yes” when prompted to resume and it correctly took me to slide 141. I then exited again to capture what the suspend data string displayed. Here’s the display that correctly shows the lastviewedslide=141 followed by a sequence of “7” totaling 140 and then the sequence of “1” representing the status of the slides not yet completed. From here, and all along the way, the suspend data string was accurately capturing the course progress, but it remains unclear why the "7" was overwritten with a "1" to cause the issue.

cmi.suspend_data => viewed=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141|lastviewedslide=141|140#1##,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,11,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1#0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1##-1

Hey Aaron,

Yeah, unfortunately it doesn't do me too much good knowing that the problem occurs with the modified SCORMFunctions.js if I can't prove that it happens with an unmodified one.

Also doesn't do me much good to know that the value of the suspend_data string somehow gets muddled and therefor resuming doesn't work if I can't tell how the suspend_data gets hosed.  I would expect resume not to work if the suspend_data wasn't being recorded properly.  On our side with the unmodified version if I went through a course, and viewed the same number of slides, and exited on the same last slide the suspend_data should be the same.

If it isn't the same for two people that viewed the same slides, and exited at the same point you might want to check on OS/Browser/Flash Player to see if maybe that is the cause.  Like if someone viewed 141 slides, exited on slide 59 and it didn't resume properly it might be worth trying to follow the same steps in the same browser.

Also it is troubling that the course is freezing so much, as that could also cause the suspend_data not to be recorded properly....

But yeah, might be worth checking someone who has had the problem, and see if you can reproduce using the same browser/os/flash player version....

-Dave

Hi Dave,

I can tell you that with the unmodified SCORMFunctions.js file the course would always stop retaining resume data once it reached the 4096 character limit (I cannot remember what slide that was on) but we cannot revert back to the unmodified SCORMFunctions.js file or we will have hundreds of students without the ability to resume from a slide beyond where the course reaches its character limit. This was the entire reason that we went to the new file. We're better that 1 or 2 out of every 100 have this issue than to have all students experience an inability to resume beyond a certain slide.

What you are suggesting to determine is "does the suspend data change from a "7" to a "1" in the unmodified data"? I might assume that this does/can occur based on the original post by Steven Stark. It appears that his data did the same thing (notice the view=19, lastslideviewed=9, and there is not a series of 19 "7"s that follow. There are only enough to bring the student back to slide 9. (http://community.articulate.com/forums/p/2905/15987.aspx#15987)

I'm not sure if you are on to something with the OS/browser/Flash. We know and communicate the requirements for viewing files published in Articulate to our students. Are you aware of any combinations of OS/browser/Flash that may cause such resume behavior? Based on the requirements published by Articulate, our clients are meeting every requirement and yet, this issue still occurs. When we work the student back to the spot in the course where they were previously, they are then 'magically' able to finish the course from that point. Why would that occur? They continue the course where we leave them (such as on slide 141) just fine using the same computer as they did the time when the issue arose.

I hope that with Steven Starks example from above, this suggests that the experience using an unmodified version of the SCORMFunctions.js or a modified version is not the source of the issue. Rather, that the "7" can be overwritten with a "1" in either version and presents a problem with resume.

So what's the cause of the overwrite from "7" to "1"? If we can find that answer, I think we can get this resolved. Unfortunately, I cannot replace our current course with a course that we know fails for resume beyond a certain slide 100 percent of the time. We're better off with a couple students per day needing to get back to a certain point in the course (and not sure why we can get them there and it works fine for them to resume after that) but there's definitely something happening with ones and sevens.

Hey Aaaron,

>I can tell you that with the unmodified SCORMFunctions.js file the course would always stop retaining resume data once it reached the 4096 character limit (I cannot remember what slide that was on) but we cannot revert back to the unmodified SCORMFunctions.js file or we will have hundreds of students without the ability to resume from a slide beyond where the course reaches its character limit. 

On this course it doesn't look like there is any Quizmaker Quiz is there?  Right now you are at 1,061 characters, and unless you have about 600 slides you shouldn't get to the 4096 character limit...

>What you are suggesting to determine is "does the suspend data change from a "7" to a "1" in the unmodified data"? I might assume that this does/can occur based on the original post by Steven Stark. 

With all the testing here that we have done I haven't ever seen it happen, so I am not sure what happened in Steven's example.

>Are you aware of any combinations of OS/browser/Flash that may cause such resume behavior? 

I am not, and I haven't ever seen it occur here on any of the LMSs we test on.  But if you view the course in the same manner as the person that reported the problem and you can't reproduce there has to be some other variable that causes it to happen.

>When we work the student back to the spot in the course where they were previously, they are then 'magically' able to finish the course from that point. Why would that occur?

Not sure I follow.  What is it that you are doing?

>So what's the cause of the overwrite from "7" to "1"? If we can find that answer, I think we can get this resolved.

Yeah, that is what is going to be difficult for us to figure out without a reproducible case...I have to guess that it isn't totally random, that is why my thinking would be to try and reproduce the steps as closely as you could to one that exhibited the problem and see if you can get steps.  The things I would look at are:

1. Slides viewed by the user and last viewed slide
2. Browser
3. Flash Player version
4. OS
5. Anything else special that the user remembers about the session.

But yeah, what is really important is finding the reproducible case to find out why it happened.  Even if you can't try without the unmodified SCORMFunctions.js, but can find the repro case with the modified SCORMFunctions.js we can probably try it on SCORM Cloud with the unmodified version as it doesn't enforce the Suspend_data limit.

-Dave

Folks,

I ran across a problem this week from one of our clients that looks a bit like this. When the user selected "Yes" to restart where she left off, the course started at slide 1. When slide 1 was completed, she was notified that she could not advance until completing a last quiz that she had already passed.

I did find this old article: http://www.articulate.com/support/presenter09/kb/?p=3785 . Turns out that this is a problem with Presenter '09 and shows up when a user exits a course on the slide immediately following a quiz. This does seem like a natural place to take a break from a long course.

I found that the workaround suggested in the article caused more problems than it solved. I finally inserted a blank slide after each quiz and imported a very short (<

Don't know if this is the case here (I'm not an expert on SCORM), but thought I'd speak up in the event that this could be helpful.

Manny

Hi Manny,

Thank you so much for sharing what you found.  I have lots of quizzes throughout my courses so will follow your example with inserting the blank slide after the quiz. 

The problem still occurs, however, even when a student has exited the presentation and it's not immediately following a quiz.  It happens randomly which makes it even harder to troubleshoot.  I'm watching the discussion between Dave M. and Aaron A. closely to see if they have any luck finding a solution.  In the meantime, I've started gathering  examples so I can maybe have Dave take a look at them at some point in the future.

Thanks again for taking the time to pass this along!  I know there's a reason why we're having this problem with resume presentation, but it appears that it's not going to be easy to solve!

Take care,

Steven

Hi All,

Nice to see some others in this conversation as the more minds on this, the sooner a solution might be found. I have seen the article regarding the slides immediately following the quizzes and have not found this to be the case with what I'm experiencing. There was an instance where the slide after the quiz resulted in the inability to resume, but all of the others (about 2 or 3 per day for the past several weeks) have not been on a slide following a quiz. Like Steven, the locations in the courses where this occurs seems completely random and it does not impact all students. For example, I am able to enter a course and login as the student, and though I have to start at slide 1 (since that student has experienced the resume issue), I am able to work through the course and exit and resume successfully as frequently as I wish and on each and ever slide that has ever been reported as the location of the "last slide viewed". Why would this work for me and for 98 percent of our students but not for a couple each day? I think if a cause were found for how it's possible to overwrite the value "7" with a value "1" we may be able to find a permanent fix. I am under the impression that this string is write only - so how would it be overwritten? If this is not the case, how can we manipulate the string to change the "1" back to a "7"?

Hi Folks,

Looks like my reply was truncated. The blank slide that I added after each quiz has a very short (less than one second of silence) audio clip so that the slide completes very quickly. It goes unnoticed by the user then on to the next content slide.

We have not seen the offending behavior when the user exits the course on a slide other than the first one after a quiz --- yet. I'll keep an eye out for that one.

Manny

Hi Aaron, 

It sounds like you and I are having the same exact problem.   From this point on when I have cases of the resume feature not working, I'm going to get more data from the student about what happened, browser and version, etc.  I'm also actively working with my LMS on this issue, but as you and I already know, it's not easy to figure out what the problem really is.  It's so hard to troubleshoot this stuff when it only happens randomly. 

As a temporary workaround, I wish there were someway to make up a fake suspend_data file and insert it in the LMS to prevent folks from having to repeat something they've already done.  But I'm guessing that can't be done. 

I'll keep you posted if I discover anything noteworthy on our issue. 

Thanks,

Steven

Hi Steven,

I think our issues are identical and wish that there was a way to manipulate the suspend_data file as well. I'm not sure what allows this file to be overwritten (aside from selecting "No" when prompted to resume). Like you, I am finding that this file is entirely overwritten when "No" is selected and only half of it (the part that really seems to matter) is overwritten when some unknown, random thing occurs. Maybe this data on the end of the suspend_data string can be made to never be overwritten except in the case of a "No" selection? I'm not sure who could/would program that into the code but that may solve the issue as well - though I'm about as far from a programmer as one could get.

My thought is, for example in MS Excel, you can code a field or value as "=IF" and that this suspend_data string could be coded similarly as "overwrite end of suspend_data string 'if' response = "No" on resume prompt". Then, no matter what else occurs within Articulate/LMS, this data would stay put and always allow the student to return unless the criteria for "if" is met. Any false return would keep the suspend_data as hard coded and unable to be overwritten.

Are there developers/programers that can see the logic in this and can figure out a way to do it? 

I think Steven and I (and probably some others out there struggling with the same) would be forever thankful for your efforts!

Aaron

Hi All,

I just found this article regarding compatibility with IE9. I'm currently working to see if this is the cause of the issues that about 2 percent of our customers are experiencing and why I can take the same course and resume at any point in the course (I'm using IE8) and they are not able to.

http://www.articulate.com/support/presenter09/kb/?p=3693

If anyone else has this issue and found this to be the solution, please post this as a fix.

Thanks,

Aaron

As an FYI, the IE9 issue mentioned in that KB is likely not the issue.  That issue, in LMSs that are affected by that would cause any tracking not to work, not just resume, and the suspend_data wouldn't be sent at all.

That issue has three potential fixes:

1. Upgrade the user to Flash Player 11
2. Ask the LMS vendor to put in the meta tag referenced in that KB article
3. Tell the user to use IE9 in compatibility mode

-Dave

Hi Aaron, 

Are you still having problems with resume presentation not always working for your users?  When one of our users returns to a presentation that they've already started, the LMS prompts the user to choose whether or not they would like to resume the presentation where they left off.  If they answer 'Yes,' they're supposed to be taken to the last slide viewed in the presentation.  On the other hand, if they answer 'No,' then they are forced to start over from the beginning again.  The problem is that often times, even when the user answers 'Yes' to this prompt, they are still forced to start from the beginning again. 

I'm currently trying to get the LMS provider to remove the prompt entirely and just automatically have the user start where they left off.  The hope here is they we can weed out situations where perhaps the user is clicking 'No' rather than 'Yes.'  That said, I don't think the problem with resume presentation is because users are clicking the wrong button, but it's one more variable that can be removed from the presentation.  My feeling is that it might be something such as a browser setting that is causing the problem for some users.  I only say that because sometimes when they report the problem, I then log into their account using their login credentials from my own computer and the resume presentation works just fine.

Anyways, I was wondering if you have a similar setup with your LMS.  Also, have you found any solutions to your problem with resume presentation or do you still experience the problem as well?

Looking forward to hearing from you! 

Steven