This project is read-only.

SeekAsync issue


We are seeing a bug with the Player Framework v2.0 (for Windows Store) where seeking becomes unresponsive until the application is restarted. We are able to reproduce it by quickly calling player.SeekAsync() twice. It seems that calling it a second time (before the first fully completes) puts the framework into a state where it will never seek again. The same behavior is seen when setting player.Position() instead of SeekAsync. We are able to issue other types of commands like play / pause, change the source url ect but it will not ever seek again.

Putting a mutex around await player.SeekAsync() helped the problem but it seems like SeekAsync() returns before the seek is truly finished. Is this a bug in the Player Framework or is there some work around we can do in our app?


AEONSoft wrote Aug 11, 2015 at 9:13 AM

We have numerous users reporting the seek bar becomes unresponsive and we aren't making any calls to SeekAsync(), but it must be triggering the same stuck state mentioned here through the player controls alone. I haven't been able to reproduce it myself, but we have received dozens of support requests from our users regarding this issue.

unleashed85 wrote Aug 11, 2015 at 6:15 PM

I see this bug if we call possition() or seekAsync() before the seek really finishes. I had to hack in a lock to make sure only a single seek is issued at a time. That made it much much better but it still happens to our customers. Its really annoying because the player becomes unusable until you restart the whole application. I know it happens with smooth streaming but I'm not sure if it also happens with dash content.

Sparkyish wrote Sep 15, 2015 at 4:06 AM

I can confirm this bug still exists in Player Framework V3

Rexobias wrote Jan 19, 2016 at 4:10 PM

@unleashed85, how did you implemented the hack?

I'm facing this problem when abandoning the Player Page while the seek is not finished and I was trying to prevent it with a flag.

I couldn't do it because I really miss a SeekStarted method or a IsSeeking property (I didn't even understand why we don't have at least one of them) ...

Thanks you.

unleashed85 wrote Apr 11, 2016 at 5:15 AM

The problem is that SeekAsync isn't thread safe. If you have multiple threads calling it at the same time it will loose track of the pending seek operation and it wont seek again without restarting the app. You can see the issue just by looking at the code. They really need to add a mutex or lock to it.

I put a lock around my code paths that call SeekAsync and that helped a ton. However it still happens sometimes.