Skip Immediate repeats if done quickly (1 Viewer)

[Mat Walker]

Now, here's a thing.....

On my standalone machine the issue was really quite difficult to repro - I had to multitap very quickly. However, as part of investigating another issue I started to run the client in debug mode; which automatically selected a plugin-free TITAN skin. Now, the skip issue described above is very evident..

So it may be client/skin issue (IE. Not blocking a subsequent Skip-immediate until the current one has been fully processed - and a timeline pointed moved forward the appropriate value); which is interesting.

With this debug-mode (and TITAN) I can sit there with the remote quickly repeatedly hitting UP and have the TV stay at the same point playing 20-30ms constantly until I stop hitting UP and it continues playing.

 

[mm1352000]

I use the DefaultWide skin and a keyboard. I don't use any plugins. I was holding down the up or down key when testing. Not sure how I could get any faster than that...

 

[Mat Walker]

Not sure holding the Remote button down is a good repro; probably depends on the remote you are using. Some remotes, when the button is held, resend the main data bits but toggle one bit to indicate to the receiver that the button is actually being held down rather than user is tapping quickly (this is what makes some less-expensive Universal remote's 'learn' functions behave weirdly).

With Titan is it a lot more evident (which makes me think it could be more skin related).... I'll do a video if it'll help

I've started digging in the doc's to try and gain a better understanding the MP architecture and, more specifically, how the client communicates with the server - is there a specific document that defines and describes this (or is it easier to do a git pull and look there?)? (With MP2 poking the back of my mind as the future, is finding out how MP1 works kinda a waste of time? Or does MP2 build on MP1 and much of the underlying stuff is staying the same as 'why fix something that aint broke' )