Timeline lagging when editing/viewing

Hi Shaun,

It sounds like you're describing an issue similar to the one in this thread, where using the timeline scrubbing effect to go to particular parts of the slide is much slower and doesn't show the actual slide point in SL2 as detailed in that thread. It was an issue reported to our QA team earlier this fall, and I don't yet have any updates to share. If that matches the issue you're describing I'll add this thread to the existing report so that our team is aware of another user being impacted and so that I can provide any additional updates here. 

If I'm misunderstanding what you're describing, could you share a bit more information or even we're happy to take a look at the .story file to see if we can replicate the behavior. 

Thanks for getting back to me Ashley. This thread is similar to the issue I have. I had it on both my computers and experienced it in both SL1&2. The movie I have was a screen recording done with SL1, so this should output to the timeline fine, should... I actually think the real issue is with the effects. The processor goes through the roof when it gets to zoom effects and I think it just snowballs from there. The more I try to adjust the effects, the worse it seems to get. Being an instructional video, I am using a lot of the zoom feature. The more there are, the worse the problem seems to get. I have the issue, but not as bad, in shorter videos with less of these effects used. When playing, the timeline almost looks as though it is in slow motion at times. It jumps through the time in the timeline too, rather than seemlessly playing through and the slide reflecting what the playhead is actually playing.

I spoke to the sale rep in Australia from Microway, Simon. In discussion he mentioned it might be graphics related and my card might need the drivers upddated. I have done this with no change. I expect though it may still be processor/graphics related, even though the machines both have at least the minimum specs or above. I don't want to have to spend more money on a new machine or upgrading the laptop, is was a drama just getting the laptop in the first place, but I guess the software just won't do what I want or need it to do effectively without the machine have high end specs? I'll have to edit it in other software and bring it back at the moment, I've lost so much time on something that should take be less than 30 secs to do. I'll explore the hardware issue further.

Thanks, any immediate result would be great, even if it's user error...

Hi Shaun,

Thanks for sharing some additional information here. It sounds like you're running into a bit of the issue I mentioned, but that's specific to Storyline 2 and how the timeline scrubs with a video. Since you're seeing it in SL2 and SL1, and it seems to behave differently with videos of a different length? How long are the videos that you're seeing this behavior on? Also, have you confirmed that you're working on local project files as detailed here? You mentioned updating your graphic cards as well, and you may want to look into what other programs are running while you're working in Storyline , as it may be an overall memory issue. I'd suggest closing down other programs and applications to see if that helps with performance. 

Shaun,

It is not a problem with your equipment, nor with your video.  When you try to start preview from the timeline when you are editing (a VERY handy and NECESSARY ability), if you start with the playhead anywhere besides the beginning, the timing of objects is significantly off. That really negates the idea of previewing from the time line and setting cue points on the fly. If the timing is off, the cue points are useless. I have personally experienced this on a large variety of computers and setups.

Ashley, please PUSH the QA people. This needs to be fixed, as the only way to check a timing or interaction between objects is to preview the entire slide from the beginning.

Hi Stacia,

I continue to share information here in the forums in regards to number of users being impacted and new threads in regards to this particular issue - so I'll make sure to share your comments as well.

Once there is additional information to share we'll post an update here. 

Hooray. Well kind of. I thought this was a unique issue to me as there has been no feed back to date nor obvious others with the problem. I have tried liaising with other Articulate support staff from Australia and one suggestion was to re-record the project using Replay. I originally did it via Articulate's screen recording option. So I will test this option also to eliminate the capturing method, but needless to say this has put some heavy breaks on the project as I do get the same issues with other sessions that use the same captured material.

Thanks Shaun for sharing additional information here and I'm happy to hear you were able to get your course working as expected. 

No worries with sharing the extra info Ashley, but this project is far from working as expected, as mentioned, it is likely I may have to re do the recording in Replay and then test if this is the reason for the issues, the screen recording asset that is. Unfortunately, this project hasn't been a good nor seamless experience...

Hi Shaun,

Are you still working with our Support team? I'd be happy to follow up on your case and see if there is any additional information we can glean from there. 

Hi Shaun,

If we're unable to look at the project, it's hard to say for certain what is happening, how to fix it or try and replicate the behavior - but the previous thread I shared was close in terms of similar behavior and that has been reported to our team. Could you create a sample project that does not include your sensitive information to share so that we could take a look at it? If you're able to share the file privately, we can also take a look by sending to our support engineers here.