View Issue Details

IDProjectCategoryView StatusLast Update
0001337OpenMPTPlayback Compatibilitypublic2020-06-06 15:41
Reporterdjbarnes Assigned ToSaga Musix  
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT / libopenmpt 0.5.0 (upgrade first) 
Target VersionOpenMPT / libopenmpt 0.5.1 (upgrade first)Fixed in VersionOpenMPT / libopenmpt 0.5.1 (upgrade first) 
Summary0001337: .mod file, EE + E6 = infinite loop.

.mod file, EE + E6 = infinite loop.
I believe it is because there is also a EE (repeat row) on the same line, however my understanding is this shouldn't impact it, and the mod plays ok on other players, eg. xmplay.

Example module:

Pattern id: 10, Line (row) causing issue: 31
Has both a EE3 and a E64, this appears to cause the issue.

EE3 I believe means repeat this row 3 times, I am not an expert, but i believe this means the row should repeat 3 times, then do the E64 (jump to the E60), and once the E64 has triggered 4 times it should continue on its way, not keep looping the E64 forever!

About 30 seconds in (in pattern id 10) you will reach the infinate loop caused by the loop between line 29 and line 31,
the loop should only loop 4 times, and plays fine in other players (eg. xmplayer)

It loops forever instead of 4 times.

Steps To Reproduce
  • Open above file in OpenMPT
  • go to Pattern ID 10
  • Click play pattern
TagsNo tags attached.
Has the bug occurred in previous versions?Just downloaded and tested on 1.28.x and it occurs on that version also.
Tested code revision (in case you know it)


Saga Musix

Saga Musix

2020-06-06 09:52

administrator   ~0004364

OpenMPT interprets E6x like ProTracker would, and the infinite loop behaviour is correct in that case. Sadly there are many different trackers used to write MOD files, all with different behaviours and it's technically impossible to find out which one was used to write a MOD file. I guess we could disable ProTracker behaviour for E6x in case the file has more than 4 channels but that will require a lot of testing if it breaks other modules.

Saga Musix

Saga Musix

2020-06-06 15:40

administrator   ~0004367

I have modified some playback behaviour for MOD files in r12985 so that they behave more like XM files if the MOD file is not a 4-channel file within the Amiga limits. Hopefully it doesn't break other multi-channel MODs! The new build can be downloaded within a few hours or so from

Saga Musix

Saga Musix

2020-06-06 15:41

administrator   ~0004368

PS: A single module not being played correctly is never a reason for setting the issue priority to "high" or severity to "major". Those would be applicable if e.g. the application crashes when playing a module, but not for a playback error that only affects a handful of files.

Issue History

Date Modified Username Field Change
2020-06-06 08:56 djbarnes New Issue
2020-06-06 08:56 djbarnes Description Updated
2020-06-06 08:57 djbarnes Summary .mod file, E60 + E64 infinite loop. => .mod file, EE + E6 = infinite loop.
2020-06-06 08:57 djbarnes Has the bug occurred in previous versions? Just downloaded and etsted on 1.28.x and it occurs on that version also. => Just downloaded and tested on 1.28.x and it occurs on that version also.
2020-06-06 08:58 djbarnes Description Updated
2020-06-06 09:52 Saga Musix Note Added: 0004364
2020-06-06 10:50 Saga Musix Priority high => normal
2020-06-06 10:50 Saga Musix Severity major => minor
2020-06-06 15:22 Saga Musix Description Updated
2020-06-06 15:36 Saga Musix Assigned To => Saga Musix
2020-06-06 15:36 Saga Musix Status new => assigned
2020-06-06 15:40 Saga Musix Note Added: 0004367
2020-06-06 15:40 Saga Musix Status assigned => resolved
2020-06-06 15:40 Saga Musix Resolution open => fixed
2020-06-06 15:40 Saga Musix Fixed in Version => OpenMPT / libopenmpt 0.5.1 (upgrade first)
2020-06-06 15:40 Saga Musix Target Version => OpenMPT 1.?? (long term goals)
2020-06-06 15:41 Saga Musix Note Added: 0004368