View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000878||OpenMPT||[All Projects] General||public||2016-09-25 07:30||2016-10-22 15:24|
|Reporter||StarWolf3000||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.27.00.* (old testing)|
|Target Version||OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)||Fixed in Version||OpenMPT 1.26.06.00 / libopenmpt 0.2-beta20.2 (upgrade first)|
|Summary||0000878: All files automatically looping in r7183|
I have disabled the global looping setting, and regardless of that, all files, regardless of type, are looped from the beginning in r7183.
Files with looping enabled or Bxx + Cxx/Dxx are correct looped (if the looping setting is activated).
|Steps To Reproduce|
The song will not stop when it reaches the end, instead restarting from the very beginning on the first row, but skips playing anything on the first row.
Also it shouldn't loop when there's no Song looping activated and no reverse jump commands (Bxx + Cxx/Dxx) are in it.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Used previously 1.27.00.07-r7019, not occured there|
|Tested code revision (in case you know it)||r7183|
libopenmpt appears to not be affected.
Didn't have a look yet, but most likely related to the issues described in https://forum.openmpt.org/index.php?topic=5729.msg43657#msg43657
Fixed in r7188. Please report any similar issues you might be encountering. I have recently changed some code which didn't technically break anything that wasn't broken before, but it made some broken behaviour more visible than it was before. The issue you encountered was one of those.
Technical background information: Previously, the internal order list size was always at least 256; now it is only as long as required, leading to some problems when touching the end of the order list - like in your case, when checking if there is anything left to play at the end of the song. These edge cases were so far only relevant for MPTM files (and some other import-only formats) because those could have an order list longer than 256 items, but apparently noone really ever stress-tested the order list behaviour in this case.
Note: This problem already existed in OpenMPT 1.26 when playing a song with an order list of maximum length (e.g. 256 items in IT format), hence the bugfix for this will be backported for OpenMPT 1.26.06.00.
|2016-09-25 07:30||StarWolf3000||New Issue|
|2016-09-25 07:44||manx||Assigned To||=> Saga Musix|
|2016-09-25 07:44||manx||Status||new => confirmed|
|2016-09-25 07:44||manx||Note Added: 0002671|
|2016-09-25 07:45||manx||Target Version||=> OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)|
|2016-09-25 12:25||Saga Musix||Note Added: 0002672|
|2016-09-25 13:47||Saga Musix||Note Added: 0002673|
|2016-09-25 13:48||Saga Musix||Note Edited: 0002673||View Revisions|
|2016-09-25 13:48||Saga Musix||Status||confirmed => resolved|
|2016-09-25 13:48||Saga Musix||Resolution||open => fixed|
|2016-09-25 13:48||Saga Musix||Fixed in Version||=> OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)|
|2016-09-25 15:04||Saga Musix||Note Added: 0002674|
|2016-09-30 17:37||StarWolf3000||Relationship added||related to 0000880|
|2016-10-01 05:06||StarWolf3000||Relationship deleted||related to 0000880|
|2016-10-22 15:24||Saga Musix||Fixed in Version||OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first) => OpenMPT 1.26.06.00 / libopenmpt 0.2-beta20.2 (upgrade first)|