Animated GIF--Loop Just Once?

I suppose that this bug currently remains unfixed?

Too bad.

Hi Greg, 

It is still an open bug with our team, so I don't have a update to share at this time, but the current workaround for a GIF that is set to not loop (where Storyline doesn't respect that setting) is to convert it to an MP4, and use that version in the meantime. 

Once we have additional information to share we'll include that update here. 

Hi Joseph,

It is reported as a bug, and I keep the team updated when new users weigh in here - but if Greg would like to be notified more directly about a resolution he's welcome to submit it as a support case so that our team can email him directly once there is additional information to share. 

Ashley, I'm really lost with how this works.

Thanks for the reply Ashley, unfortunately the MP4 workaround doesn't do the trick for me as the animation requires a transparent background.  Off to look for another way of achieving this - or just remove that aspect of the eLearning entirely.

Hi Jose!

I know that the original posting here is a bit dated. You are welcome to reach out to Bob directly if needed via the 'Contact Me' option on the user profile if you wish.

From using GIFS within storyline, I have noticed that the quality of the GIF deceases dramatically when publishing. I believe that SL breaks it down in order to make a SWF then re-encodes the GIF, this seems to be where the looping is added back in.

To get around this, once published find the GIFs in the mobile folder and replace them with the original, renaming them to match the output. When doing this make sure that the gif you put into SL is the same size you intend it to be (not tested if it will resize bigger/smaller).

This does seem to fix the issue this thread is looking at, plus others not mentioned. It is a bit of a faf if you have a large ammount of GIFs but it does seem to work.

Thanks Nick for sharing that here and I also wanted to link to a recent reply I posted in this forum thread in regards to the issue and our teams continued investigation. 

I am on the most updated version and this BUG is still persistent.  

I am curious as to what BUGS get prioritization over feature requests.  It would be nice to have some sort of site where we can look at to say, "Oh I have this same issue." click here and that number increases by 1.  At the end of the day, look at the ones with the higher number and close those.

Kinda simple process to follow but I'm not making the decisions.  

Hopefully, Storyline will start separating themselves from the pack and get these completed. 

Hi Walt,

The two issues connected to this forum discussion that were fixed in Update 10 were:

• Fixed issue where a non-looping GIF would unexpectedly loop in Storyline
• Fixed issue where an animated GIF wouldn't always start playing at the beginning of the animation in Flash output 

So for the one above, it's only fixed in the Flash output - not the HTML5. If you're still running into issues with the Flash output it's something our team would want to take a look at and you can reach out to them by uploading your content here. 

As far as bug and feature request prioritization, I know a few other forums members have asked about a public facing chart of these. It's not something we currently offer, although a regular discussion internally for considering it. When our team takes a look at bugs they are trying to identify the impact, breadth of users impacted, customer pain, the involvement of a fix and any other areas of the program it could alter. A similar process is true for feature requests in terms of current set up, ability to accomplish it using a different method, and understanding more of the problem experienced vs. just the solution shared by users.

I hope that helps clarify, and again our team would be interested in seeing any files you have using Update 10 that are not working with the animated GIF fixes as mentioned.