Unfortunately this is a well documented problem with the Live API.

I was one of the people working on the Live Clip Chopper app for monome and launchpad, moving the playing position when hitting pads so you could chop up samples live.

Development pretty much stopped as the move_playing_pos function is pretty unreliable. Also as I was you are using the playing_postion of a clip to decide when or what value you use for move_playing_pos.

The problem is, I think, that the playing_position information can only be gotten or observed at scheduler rate and then the move_playing_pos function can also only be called at scheduler rate, not at audio rate like live.remote~.

So you just can’t get the data quick enough and at sample accurate speed meaning the calls to the move_playing_pos function aren’t accurate enough to jump with precision. You get random variance in the amount it jumps.

Putting the audio clip into RAM enable mode helps, and so should lowering your Audio Buffer size in Abletons preferences.

For the moment it seems move_playing_pos isn’t really usable. A few people, including myself, are working on solutions using max objects such as play~, wave~, and groove~ to build work arounds. Basically building your own little sampler that functions like an audio track in live, allows you to jump to any point in the sample, to reverse the audio, or change the playback speed of the sample independent of the master tempo without having to use the mouse.