MediaPlayerStateChanged should fire only on real state change

[jaruba]

MediaPlayerStateChanged does not trigger for the buffering state. See this demo:

http://editor.webchimera.org/c/1429781968

[RSATom]

hm... strange, it should (I've checked the sources). Ok, will look close a little later. Thanks!

[jaruba]

then maybe it's something with .state? could it be it doesn't change to 2 (buffering)? or maybe .state is changed to 2 after the buffering event is triggered?

[RSATom]

I think .state could skip some state if change was happen very quickly, since state event not tied strong with .state value. And there could be some delay in .state update. Events in this case are more reliable.

[RSATom]

The reason is I emit MediaPlayerStateChanged not when .state value was changed (I have no control over it), but when some related event arrive: https://github.com/RSATom/QmlVlc/blob/master/QmlVlcPlayerProxy.cpp#L50

So if you get MediaPlayerBufferingevent, after that you will get MediaPlayerStateChanged since one triggers another.

[jaruba]

Does MediaPlayerStateChanged also pass the new state to the callback function?

[RSATom]

Don't sure I understand what you mean.

[jaruba]

If something like MediaPlayerStateChanged( state ) is possible. so it would pass the new state when the event is triggered.

[RSATom]

no, since I have only async access to state. I.e. it will have the same problem.

[RSATom]

but stop, you are right, I can deduce current state from original event. Good Idea.

[jaruba]

There is one more problem with MediaPlayerStateChanged that I've found. I guess it should trigger only when the state has changed (ie: is different from the previous state), but I added a console.log() to the event and it's triggering a lot more times for the same exact states in a row.

[RSATom]

Yes, I didn't store previous state value