[Lunatixz]

hmm...

If that was the case, why does it only effect movies and not tvshows?

Have you tried last nights development build? it didn't fix your problem with seeking?

can I see the logs where seek is called before playback? thanks

You can see it in the log I posted earlier at http://pastebin.com/XzsAVVgB. Seek is called on lines 434, 2635, 3148 and 3471 - the "switching to normal playback" debug is on lines 431, 2633, 3155, 3457 - the one which reset to the beginning was the one with the seek on 3148 and the playback on 3155.

I didn't say it was movies only - this log was for tv show channels. But as you mention it, movies were especially prone to the problem - perhaps because they are larger files and therefore take slightly longer for xbmc to start playing.

As for the development build, I tried that and it didn't fix it. (Even tried it on the latest build of helix but it segfaulted.)

I appreciate you looking into the problem, but this isn't a new bug... and while fresh eyes can sometimes break ground... the suggestion you mentioned isn't a solution.

There is only one seek bug, and it has to do with the subtitle service. It pretty much only affects Movies (most likely because its rare to use subs with tvshows).

One major thing you are missing in your log and is the reason seek is called and ignored...

Code:

DEBUG: ffmpeg[2217C700]: [mpeg4] Invalid and inefficient vfw-avi packed B frames detected

Looks like your file isn't encoded properly or at least ffmpeg thinks so... Your "fix" may overcome issues with poorly encoded media, but I'm not sure it will always work? if a file isn't encoded properly xbmc.player might not seek at all.

Last nights development build fixed an unrelated problem that could have affected seeking...

If another user running GOTHAM ( I do not support Helix) and latest development branch show similar logs I'll investigate the possibility of it being unrelated to encoding...