Internet Explorer Issue

Has anyone ever seen this in his course:

This happens sometimes by opening a lightbox, but only in various version of Internet Explorer.

When the sign is shoping up, nothing else can be done. You have to close the WBT.

Does someone know what the sign means and how I can avoid this to come?

Using Storyline 1 Update 8.

 

 

81 Replies
Nicholas Spendley

Hello All,

Update from my side, I cut all our courses in half and am still seeing the same FLASH issues. Therefore, my only solution is to make every one of my trainees Disable Flash in Chrome and view my lessons in HTML 5 Format . It is very disappointing to have to take so many steps to view my coursework but the reputation of my Training department is on the line.

PLEASE find a solution and provide any updates that could improve this Flash / Storyline 2 performance and prevent he Grey Circle Exclamation Point of Death!

This email and its attachments may contain confidential information intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby advised that any disclosure, copying, distribution or the taking of any action on the contents of this information is prohibited. If you've received this email in error, please notify the sender.

Andrew Gee

Hi Nicholas,

I have had the same, chopping does not make a difference as I believe it is the way Storyline preloads upcoming data (I have communicated this previously to the Dev Team).  Also the fact that if you record at high res and then import as a step by step i think the course still treats it as a large video and uses up memeory accordingly.  I have one that runs fine until it gets to 1.5gig of memory usage and then crashes and releases the 1.5gig instantly. 

I have been using a tool called sIEve and it can be run as a portable app that monitors memory usage in IE and the course seem to chew memeory when preloading slides and does not relaese back to the previous usage and therefore the Storyline player software via IE constantly increases in meemory usage.

I have sent videos of this happening and hopefully as we are seeking a solution is found soon.

Also have you noticed any resolution degreadation when using HTML5 in Chrome.  I have noticed this but I cannot use Chrome as we use IE8 as default and will not be upgrading anytme soon.

Thanks

Andrew

Nicholas Spendley

Andrew,

As frustrating as this situation is, I have to say I am glad there is another individual with the same issues. Makes me feel less crazy!!

I will continue to look for solutions on my end and will most definitly keep you posted with anything I am able to uncover.

Cheers.

Nick.

This email and its attachments may contain confidential information intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby advised that any disclosure, copying, distribution or the taking of any action on the contents of this information is prohibited. If you've received this email in error, please notify the sender.

Christopher Cummins

Try this <-- It happens to us too. Check out Key Point 2 from the menu. Doesn't work in IE 11. This was published at maximum resolution within the publishing options using custom settings. Funny thing is, that's a Base Layer with no videos. If you open it in Chrome, you can access the different layers which are all video layers essentially mp4 files at 1280 x 720. Total project size is 1.01 GB and that's hefty.

 

So, we decided publish again using the standard publishing settings. The total project size is much smaller 136 MB. However, the same thing happens. Smaller Try this

 

For now, we're telling users to strictly use Chrome. Other thought were to re-encode all video files,  but after publishing at a lower resolution (Standard), I'm not sure it's necessary to go down that road.

Andrew Gee

Have we got a solution yet???????  or some kind of update?????

I am now at a point where I cannot use this software for the intended purpose of creating an instructional eLearning course to instruct learners on how to use a complex program that can result in lives being lost etc if used incorrectly. 

I have now reduced my screen recording resolution to 1747x1008 as this is the minimum I can record the program that I wish to instruct learners on.  Due to the fact the program does not reduce any smaller as the screen is at a static size and I cannot reduce any smaller without it going across screens etc if I drop my monitor resolution. (So do not suggest)

I cannot use Chrome as this is not our default software used by our LMS.  (so do not suggest)

I am forced to use IE8 and Flashplayer combination and am unable to change this (so do not suggest)

The course I have now with reduced recording resolution as well as trying to reduce as many memory hungry items such as breaking up all screen recordings into View and Try modes (which as stated earlier increase workload enormously), the course is still crashing and hogging memory.

I find that the fact that when playing the course the memory used is constantly going up (yes there are some small amounts of memory released as slides are finished) is a real concern as this is not what I had in mind for an easy to use package.

Please advise as I am getting very frustrated with this product not delivering what was intended.

Andrew

 

Justin Grenier

Good Afternoon, Andrew.

Thank you for uploading your project file via your Case Number 00485880.  We have reviewed your project file and we were able to duplicate your issue.  We have submitted your case to our Quality Assurance team for their review, although we cannot offer a time frame for when or if this issue will be resolved.

Since the problem seems to be related to high-resolution screen recordings, I'd like to share some best practices here for the benefit of the community.  Andrew, I'm sorry to hear that your specific environment will not be able to adopt these recommendations:

For high-content screen recordings, my recommendation is to

  1. Determine, based on your audience, the average/target screen resolution of your learners.
  2. Set your Story Size to something slightly less than that, to allow for browser toolbars, status bars, and so on.
  3. Set the Player Size to Lock player at optimal size to prevent scaling
  4. Perform Screen recording on a machine whose screen resolution is set to something slightly less than the Story Size selected above, to allow for the Storyline Player.

For example, if I needed to show screens containing lots of content at high resolution, and I knew that my learners would be using a Screen Resolution of 1920x1080, I might do the following:

  • Set my Story Size to 1600 x 900
  • Disable scaling
  • Set my Screen Resolution to 1366 x 768 before recording.

It's possible that the target audience is using a screen resolution so low that it is not practical to perform screen recording at a significantly lower resolution, or is unknown.  However, with very busy screencasts, the goals should be to

  1. Avoid performing screen recording at a resolution that is significantly higher than that of your learners or your story size
  2. Avoid scaling screencasts to something other than their recorded size.

There are also some good discussions on Story Size, Screen Resolution, and Screen Recording within the E-Learning Heroes Community Forums:

We will post updates on this issue here as we have them.  Thanks!

Andrew Gee

SOLVED!!!!!!!!!  Well it is a workaound but works for me and feel free to use it.

Articulate - the invoice is in the mail ;)

It now uses one 10th of the memory and no crashes even when skipping thru slides.

As below:

After 2.5 days of frustration and alot of rebuilding etc as well as hearing the same issue being expereince by others - I was very close to chucking in Storyline and going back to the more complex but reliable Captivate when I have found what i believe is the issue.

Storyline outputs 2 video file types MP4 and FLV.  (I have never worried about this as I have managed to avoid the crash by reducing amounts of data etc in previous courses as a workaround but this has only been achievable for small courses.)

So I decided to go back to original when this issue was not present with Storyline 1 and the only output was MP4.

I first tested and removed the MP4’s from the story_content folder to make sure I was on the right track – COURSE STILL CRASHED.

I then reversed the idea and removed the FLV video files and reinstated the MP4 video files.  (so I only have MP4 video files listed in the story_content folder.)   - SUCCESS.

Course ran beautifully, only used one tenth of the memory (previously crashed at 1.5gig – now only uses up to 120MB).

I am theorising that Storyline produces the 2 formats to ensure streaming of either is achievable.  The only problem is that Flash Player will default to the FLV and this uses much more memory as we have experienced.

I have not noticed any degradation in resolution as the res is still the same but MP4 has always had better compression than FLV.  And also the file sizes are very different as well.

Suggestion – get rid of the FLV output or advise everyone of this issue immediately and the workaround.

Thanks and until next time.

Andrew

 

 

 

Justin Grenier

Thanks for sharing your workaround, Andrew.

Generally speaking, published .flv files are not duplicates of your published .mp4 files, but instead serve a different purpose altogether, so I worry that deleting these files may impair the functionality of the content.  More specifically, you may find that step-by-step screen recordings in Try Mode may not function properly if you delete your .flv files.

I can't confirm this since it seems that the "MON Final.story" project file that you shared with us previously does not produce any .flv files in its published output.  However, if you'd like to share your current .story project file with us, we'd be happy to see if we can figure out the purpose of those specific .flv files.  Thanks!

Andrew Gee

Hi All,

SORRYY - jumped the gun with previous post as deleting the FLV files did removed the video playing as per each View or Try scene - hence the excitement of using one 10th of the amount of memory.  It wasn't loading the videos. 

Which means I am still wasting my time trying to have Storyline achieve what it claims it can do.

And this has now put us back to where we are with the memory issue and now raises more questions.

Firstly I have tried the following with no effect - COURSE STILL CRASHES. I thought I would try some different things just to see why there are 2 video file formats being produced.

Removed all FLV files and renamed MP4 to FLV extensions - STILL CRASHED

Removed reference to FLV files in imsmanifest.xml file and removed FLV files only - STILL CRASHED

Removed reference to MP4 files in imsmanifest.xml file and removed MP4 files only - STILL CRASHED

QUESTIONS:

Justin, if "published .flv files are not duplicates of your published .mp4 files, but instead serve a different purpose altogether" then why are there exactly the same number of FLV and MP4 files with exactly the same name eg 1 FLV and 1 MP4 file for each video?  

And for what purpose are the MP4 files used for?

Also why are the FLV's now being  produced when previously they were not )i have a course published in March with only MP4's and then it seems after the Version 4 upgrade it now produces FLV.  It may have been even an earlier version (i assume you wil have this information).

And just to clarify the issue - Why is this software consuming so much memory and retaining it?  Why does Adobe Captivate have the ability to record and play high res screen recordings without using anywhere near the memory when used in either full video, View Mode and Try modes alike?

Finally I cannot supply my .story file as this course is full of sensitive and confidential data as I work for a Government Agency.

Please have your testing/development team(s) design a course with size 988 x 641.  Then import 24 screen recordings (each recording should be no longer than 45 sec)  using Storyline's built in recorder at res 1747 x 1008.   Then have 18 of recordings inserted as View Modes and 6 as Try modes with some data entry.  Then publish with player locked at optimal size (prevent rescaling).  You should aim for some other slides in the course as well containing some basic animations and text, images (but only about 10 slides).  You are looking to have approx 160 slides all up.

Once published with HTML5 output ticked copy the Stroy.html file and paste it into the following program (download it from http://home.online.nl/jsrosman/) and you will see Storyline taking amazing amounts of memory and given only a portion back.  As per video already supplied with Case Number 00485880.

So in short removing the FLV files did affect functionality,  MP4 videos seem to serve no purpose (other than taking up space) and my faith in Storyline is now waning as I cannot produce what was intended using Storyline software which simply does not live up to it's claims.

I am unable to produce any further courses using Storyline until this is resolved as I will not supply sub-standard course material to my clientelle with blurry - low res screen recordings and/or static screenshots and if i did have to revert to this I might as well use Powerpoint as it will acheive the same thing and no other software purchase is required as I already own it ....NOT HAPPY!

 

Justin Grenier

Hello again, Andrew.

Let me try to respond to your questions and comments:

Q:  Why are there exactly the same number of FLV and MP4 files with exactly the same name?

A:  Within the published output folder for an example Storyline project that contains step-by-step Screen Recordings, I do not see exactly the same number of FLV and MP4 files with exactly the same name.  If you'd like us to take a look at a project that does exhibit this behavior, please share it with us.

Q:  For what purpose are the MP4 files used?

A:  In general, Articulate uses the .mp4 file format for video files that require no transparency, whereas we use the .flv file format for video files that require transparency.

Q:  Why are the FLVs now being  produced when previously they were not?

A:  Video files in .flv format have been produced by all versions of Storyline, dating back to the initial release of Storyline 1 in May 2012.  Not all .story project files will produce .flv files, depending on the requirements of the project.

Q:  Why is this software consuming so much memory and retaining it?

A:  To be clear, the Storyline published output is not an application, and is not consuming RAM.  However, when playing Storyline content that contains very large screen recordings, the combination of Adobe Flash Player and Microsoft Internet Explorer do appear to consume quantities of RAM that are many times the size of our published output.  Is it possible that Articulate could take steps to produce published content that is more palatable to Flash & IE?  Perhaps, and we have submitted your case to our Quality Assurance team for their review.  This review will occur in the long term, not in the short term.

Q:  Why does Adobe Captivate have the ability to record and play high-res screen recordings without using anywhere near the memory when used in either full video, View Mode and Try modes alike?

A:  Articulate has no visibility into Adobe's development practices or product architecture, so it would be unfair for us to comment on your findings.

Q:  I am unable to produce any further courses using Storyline until this is resolved as I will not supply sub-standard course material to my clientele with blurry, low-res screen recordings and/or static screenshots.

A:  Andrew, you have indicated that you wish to avoid creating poor quality screen recordings, but the surest way to guarantee reduced-quality screen recordings is to perform the recordings at a resolution that is different from your slide size.  You have indicated that you are performing 1747 x 1008 screen recordings and inserting them into a .story project file that is 988 x 641.  In doing so, not only are you forcing Storyline to scale the video upon publish (which reduces quality), but you are producing video files that are roughly 3x the size they need to be.  The large size of these video files will certainly contribute to high memory utilization in any browser.  I would recommend taking a different approach to your screen recordings (reducing screen resolution, capturing less than the full screen, breaking the content into multiple courses, or using another browser to view the output).

Have a great weekend, Andrew!

Andrew Gee

Hi Justin,

I did have a great weekend, thanks!

I have responded to your responses as per bleow.    I have also attached a docuemtn as per referecnes below:

Let me try to respond to your questions and comments:

Q:  Why are there exactly the same number of FLV and MP4 files with exactly the same name?

A:  Within the published output folder for an example Storyline project that contains step-by-step Screen Recordings, I do not see exactly the same number of FLV and MP4 files with exactly the same name.  If you'd like us to take a look at a project that does exhibit this behaviour, please share it with us. 

As stated I cannot share any of my current course content as it contains sensitive information.  I have however uploaded a Word Document Story_Content 18062015.doc which shows the exact same file names and number for both FLV and MP4 – I am seeing this every time.  I will endeavour to get some content that I can share but I am reserved to waste any more time testing this.

Q:  For what purpose are the MP4 files used?

A:  In general, Articulate uses the .mp4 file format for video files that require no transparency, whereas we use the .flv file format for video files that require transparency. 

I can see the FLV’s are produced when the View/Try modes are used.  This still does not help with the memory issue and does create extra data for projects (2 video files for the same video- as per document attached.)

Q:  Why are the FLVs now being produced when previously they were not?

A:  Video files in .flv format have been produced by all versions of Storyline, dating back to the initial release of Storyline 1 in May 2012.  Not all .story project files will produce .flv files, depending on the requirements of the project.

As above.  Shame the same memory issue is present when using either MP4 or FLV.

Q:  Why is this software consuming so much memory and retaining it?

A:  To be clear, the Storyline published output is not an application, and is not consuming RAM.  However, when playing Storyline content that contains very large screen recordings, the combination of Adobe Flash Player and Microsoft Internet Explorer do appear to consume quantities of RAM that are many times the size of our published output.  Is it possible that Articulate could take steps to produce published content that is more palatable to Flash & IE?  Perhaps, and we have submitted your case to our Quality Assurance team for their review.  This review will occur in the long term, not in the short term. 

That is great, but does not help me in the short term and I expected the Storyline product to do what it said – Maybe there should be some type of warning of limitations of the software regarding high resolution video being used in production of courses. 

Q:  Why does Adobe Captivate have the ability to record and play high-res screen recordings without using anywhere near the memory when used in either full video, View Mode and Try modes alike?

A:  Articulate has no visibility into Adobe's development practices or product architecture, so it would be unfair for us to comment on your findings. 

Agreed, but it does so Articulate does have a way to go to competing in this arena of high resolution video usage. 

Q:  I am unable to produce any further courses using Storyline until this is resolved as I will not supply sub-standard course material to my clientele with blurry, low-res screen recordings and/or static screenshots.

A:  Andrew, you have indicated that you wish to avoid creating poor quality screen recordings, but the surest way to guarantee reduced-quality screen recordings is to perform the recordings at a resolution that is different from your slide size.  You have indicated that you are performing 1747 x 1008 screen recordings and inserting them into a .story project file that is 988 x 641.  In doing so, not only are you forcing Storyline to scale the video upon publish (which reduces quality), but you are producing video files that are roughly 3x the size they need to be.  The large size of these video files will certainly contribute to high memory utilization in any browser.  I would recommend taking a different approach to your screen recordings (reducing screen resolution, capturing less than the full screen, breaking the content into multiple courses, or using another browser to view the output).

I agree with you regarding the slide res and the recording res difference but this simply does not help me as I have tried to record at high res with Storyline and output at high res and the product simply falls over.  So high res video on a smaller slide and then being output to a monitor at high res does not affect quality much if at all in regards to reduced video quality.  Unfortunately as previously stated I have a particular piece of software that cannot be reduced in resolution as the fantastic development team who designed it made sure it stays at a static size 1747 x 1008.  If I reduce res on monitor software item just enlarges off the screen.    As far as breaking them down, I have used the in-house view mode and reduced the amount of recording down to 10 sec blocks in some cases and they still crash.    So only option as per your advice to get quality recording is to record at 1747 x 1008 and then have story size the same but then Storyline falls over as it cannot instruct Flash/IE or whatever instruction is happening in the background to preload content to manage this and the memory required, as well as release it when no longer required. 

I guess this is a case of deciding whether to continue using Storyline as our sole eLearning prodcution tool or reserve it for the easier content that doesn't rely on large amounts of memory to play back.

Thanks and will await further response and/or solution/advice etc.

Andrew

 

Justin Grenier

Thanks for the information, Andrew.

When I tested my project, I neglected to publish for mobile.  .mp4 versions of all .flv files will be published when including mobile output, since most mobile devices cannot play back .flv files.

I understand that your requirements dictate that you perform Screen Recordings at a very high resolution and that as a result, you may not be able to use Storyline at this time.

I'm sorry for the trouble, and we will post updates on this issue here as we have them.

leslie blahnik

We are having the very same issue with screen capture and the Grey Circle of Death.   This did not happen until we upgraded to SL2.  I have opened a case and a support call, but would appreciate an update as the last message on this was 16 days ago.   The same file with screen capture loads fine in SL1, but unfortunately, as my entire team has upgraded to the new version, we are stuck.  Our clients are using IE 11 and the latest version of Flash.  Please advise.  I hope the answer is not that we won't be able to use Storyline at this time, because it is a little late for that. 

Nicholas Spendley

No update received here. We had to cut our lessons down to about 10 min sections. Highly disappointed in the product and support of articulate. My company will be looking at design alternatives beginning this fall.

The learner is the one impacted the most.

This email and its attachments may contain confidential information intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby advised that any disclosure, copying, distribution or the taking of any action on the contents of this information is prohibited. If you've received this email in error, please notify the sender.

leslie blahnik

Hi Ashley/Emily,

Ashley, you are correct.  I opened a case yesterday, but one of our designers had a while back.  The 16-days comment was in regard to this discussion.   We have been monitoring these discussions looking for a resolution and had not seen any updates.   

Emily - thank you for the updates so far.  

Leslie

Jack Fabian

I just feel I need to chime in here to say that I have the same GCOD issue, and I'm not using any screen recordings. I do have a number of low-res videos and a few sound files. On Andrew's advice I used sIEve to monitor the memory usage of IE when running my course. The usage slowly builds up as I move between screens until it hits the magic 1.5GB threshold, then bang! Circle of death. 

Sounds like the QA department needs to work on this in the "short term", rather than the long, as I think there's going to be more and more users hitting this issue. It's dangerous, and the only thing I can do with this course that needs releasing soon is hope that users don't hang around for long enough to hit the memory threshold, which is far from ideal!