This module contains lots of pattern loops, which complicates seeking a lot. In particular when trying to seek into the middle of a pattern loop, OpenMPT will think, when repeating the loop, that it already played the repeating rows (which is true!) and thus concludes that it has already reached the end of the song (and thus skips to the next subsong in this particular example).

This might be fixed by a related bigger change that should help with keeping track of pattern loops in a better way, at the expense of using more memory.

This fix seems to have introduced a rather long delay when seeking through the problematic section, I assume that's the memory usage issue you're talking about?

No, the proposed fix is not something I'd write down in a single evening. While I did add a small fix that will generally improve the playback after seeking has finished, it should not harm seeking performance in any way.

This seems to be happening, at least with xmp-openmpt.

I cannot notice any obvious performance difference introduced by r11408. And as said, it would be weird if there was one because the only thing it does is refreshing some state variables to be used during playback. It does not modify the seeking algorithm in any way.

There will be some improvements in the next libopenmpt 0.5 update (r13692) that should prevent weird jumps to random positions or stopping song playback altogether.

However, the biggest issue, precise seeking inside pattern loops, will only be resolved in libopenmpt 0.6 (see related issue 0001146).