View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001206||OpenMPT||Playback Compatibility||public||2019-02-28 11:00||2020-11-28 19:44|
|Reporter||Slender||Assigned To||Saga Musix|
|Target Version||OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)||Fixed in Version||OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)|
|Summary||0001206: Odd behavior when seeking through this module in libopenmpt|
When seeking through sta pikku klooni.s3m by Bisqwit, http://modland.com/pub/modules/Ad%20Lib/Screamtracker%203%20AdLib/Bisqwit/sta%20pikku%20klooni.as3m, it seems that the module doesn't seek forward properly, and jumps to a weird section of the file, somewhere around 4:35 in to it, rather than skipping forward as expected. This only seems to happen when seeking forward by a small interval, such as five seconds, and only at the beginning of the file, and skipping forward by a larger interval such as 30 seconds seems to avoid the problematic section.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)||r11402|
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).
|2019-02-28 11:00||Slender||New Issue|
|2019-02-28 20:40||Saga Musix||Relationship added||related to 0001146|
|2019-02-28 20:46||Saga Musix||Note Added: 0003874|
|2019-03-01 04:16||Slender||Note Added: 0003875|
|2019-03-01 07:47||Saga Musix||Note Added: 0003876|
|2019-03-01 09:50||Slender||Note Added: 0003877|
|2019-03-01 22:17||Saga Musix||Note Added: 0003881|
|2020-10-23 23:44||Saga Musix||Assigned To||=> Saga Musix|
|2020-10-23 23:44||Saga Musix||Status||new => assigned|
|2020-10-23 23:46||Saga Musix||Note Added: 0004488|
|2020-10-23 23:46||Saga Musix||Target Version||=> OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)|
|2020-10-25 14:22||Saga Musix||Status||assigned => resolved|
|2020-10-25 14:22||Saga Musix||Resolution||open => fixed|
|2020-10-25 14:22||Saga Musix||Fixed in Version||=> OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)|