Order Now AdSolution Sign Up | Login » Bits on the Run Sign Up | Login »

Forums

/

Seek stops the video

13 replies [Last post]

hi
I have a plugin which loops the end of the video.
The video duration is 51.7 seconds. At 48.8~ (i m using the time event fro this) i m sending a "seek" event to 45.8. this usually works, but from time to time suddenly the seek event causes the video to stops:

MODEL: TIME (duration:51.7,position:48.8)
Fired event goto_clip_time.
VIEW: SEEK (position:45.80299999999999)
CONTROLLER: SEEK (position:45.80299999999999)
MODEL: TIME (duration:51.7,position:0)
MODEL: STATE (newstate:COMPLETED,oldstate:PLAYING)
State: COMPLETED

any idea y this happens?

It looks like the seek sometimes advances to the next keyframe instead of the previous one. That's the endframe, pausing the video.

Is the issue still there when seeking 0.1 second earlier? Or having a video with more keyframes?

well, i played with it and realized that the closer the point in which i send the seek event (not the point i m seeking to) is to the end of the video, the more chance the seek command will failed. it's not consistent... and hard to debug.
i've tried writing a "fixer" plugin that waits for a "seek" event, and then make sure it doesn't get a "complete" state event. if so - it tries to send the "seek" event itself again. The problem with this is that sending the "seek" event so close to the "complete", causes unexpected behavior so sometimes it works and sometimes not. and of course, u can see the back screen and the play icon for a few milliseconds between the "complete" and the "seek"...

do u have any other idea?

thanks
Yair

Finally found the problem.
I tried writing a new swf with just the NetStream and an interval that does stream.seek at one second before the end of the video. It worked fine each loop and never stopped. so i started suspecting the player code.

The NetStream object sometimes sends a STOP event after a seek, but it will still does the seek command. The problem is that the player gets the STOP and shutdown the whole playback. When i removed the "if (evt.info.code == "NetStream.Play.Stop"...)" code from the player (VideoModel.as), the loop worked excellent.

Of course this makes videos without a loop freeze at the end because the player doesnt know it stopped...
But at least now i know what is the problem and i can deal with it.

I dont think u can do anything about it - u are not supposed to make sure there is no SEEK command sent when u get a STOP event - but it is good to be aware of it.

thanks
yair

Please can you confirm this ?
We are using bitsontherun player framework and have such kind of problems.

Not about looping the video, but about SEEK mistaking the seconds !

Please help or furnish any useful information!

Bump.

This bug is still persistent in version 4.4, 4.5 and 4.6. I can't believe it still around and causing me headaches 1 out of 5 seeks near the end of the video. The player jumps to the COMPLETED state for no apparent reason.

I am fearing the worst for this bug...

Helllooooooo is there anybody out there?

THIS BUG IS ALSO PRESENT IN THE 5.x PLAYER!!!! Please fix it in the 4.x branch FIRST THO!

Some more info... its usually when you seek to the fringe of the buffered video.

Correction. . . .

This bug always happens when you seek between the play head and the buffered video. It happens more often the closer you get to the amount of buffer it "thinks" its buffered.

Perhaps that it? JW Player thinks its buffered more than it really has, then when you go to seek to the supposed buffered portion there is nothing there and the player jumps to the COMPLETED state?

@Kevin -

Do you have any specific ideas for how the player should handle this? Yair BM pointed out that stopping the player on the Netstream.Play.Stop event causes the issue when seeking near the end of the clip, but it is necessary for the player to properly detect the end of the video.

As for seek -> complete, this is not the case. A seek command sets the NetStream's position if the player determines the requested position has been buffered. It doesn't go into the COMPLETED state unless the playback position exceeds the item's duration.

@PabloS

I have not been looking into the NetSteam commands or compiling JW Player my self. I've been using the pre-compiled versions direct from LongTail.

Your first comments are correct however the second is not. Seek does result in a completed state, no doubt about it. The way you describe it, this might not be the same bug as my earlier posting on 4.4, 4.5 4.6+ seeking stops the video.

The only thing I can do is wait for LongTail to officially fix this. Its a shame they keep adding such frivolous features, tickle me pink that and bounce around that and don't fix a more serious issues in a timely manner.

Same problem here. It is caused by clicking past the buffered download of the video. It causes a COMPLETED event to be fired (which screws up the design/functionality of the site).

I thought I would be able to get the duration and the current position (which is working), but when the COMPLETED event fires the current position is set to zero. So, I can't test whether the the video has actually finished or not.

This is a showstopper for us. How can this get fixed?

-Rob

I have a similar problem. Manual seeking sometimes completely stops the video. It happens either on progressive download or with lighttp streming. I'm using 5.1.854 (from trunk), but it already happend with older V4-Players.