Topic: 3.8 reports, queries and bugs

[saga]

You'll need the MMCMP plugin because the file is compressed.

[Metro28]

You'll need the MMCMP plugin because the file is compressed.

Thanks!
It is difficult to find an XMPlay bug

[saga]

It seems like there's an issue with the ReadAhead setting; I've set it to 64, so I'd expect to see XMPlay reading a large chunk of data when e.g. playing a FLAC file and see its memory consumption rise accordingly. Yet, playing a FLAC file using latest stuff version, XMPlay seems to stay at its usual low memory footprint (about 1.5MB when minimized here), and I see constant disk access at about the bitrate of the FLAC file (around 130KB/s) in Task Manager (see attached screenshot). Pausing playback, the usage goes back to 0KB/s. From my understanding, I should see a read burst of 64MB at the beginning instead? Playing the file a second time, the disk usage stays at 0KB/s, I'd assume that the Windows cache is doing its job in that case though.
In case it may be relevant, the disk itself is a SATA SSD attached via USB - it's not a system drive, only containing music files, so XMPlay was the only application accessing the drive at that time.

[Ian @ un4seen]

The "ReadAhead" process gets the file into Windows file cache rather than allocating extra memory for it, so you indeed shouldn't see XMPlay's memory grow. But if the file is still being read from disk at normal playback rate then that looks like it might not be in effect, perhaps due to the detected drive type. If you call GetDriveType on your drive, what does it report?

[Ferb]

XMPlay is still one of my favorite music players of all time, Thanks for your hard work Ian!

I was curious about the "random" shortcut. Currently, it doesn't seem to include sub songs. I know there's the random playback order setting but the idea of having a random song button is really cool and it would be neato if it dropped me into a random sub song as well.

Related, but in trying to set up binds on keyboard keys I don't have bound to anything else, I noticed that if you bind shortcuts to F13-F24 it'll show as 0x80 or 0x7c for example. A minor gripe but it's something worth pointing out.

[saga]

If you call GetDriveType on your drive, what does it report?

It returns 3, just like for the system SSD.

I was curious about the "random" shortcut. Currently, it doesn't seem to include sub songs. I know there's the random playback order setting but the idea of having a random song button is really cool and it would be neato if it dropped me into a random sub song as well.

If you want subsongs to be playable individually, you can right-click on a song with subsongs and select "Separate subsongs". Then each subsong will have its own playlist entry and can be played randomly.

[Ian @ un4seen]

If you call GetDriveType on your drive, what does it report?

It returns 3, just like for the system SSD.

The "ReadAhead" option should apply then. Note the "ReadAhead" setting is a file size limit in MB - if a file is larger than that then no reading ahead will be done. So if you've set it to 64 then the file would need to be under 64MB. Is that true for your FLAC file?

[saga]

Oh! The files I tested were all slightly above that (I thought it would apply for any file). I'll try to set the limit to a higher value then and try again tomorrow.

[saga]

Indeed, raising the limit solves that issue. That makes me wonder though if there's still a way to reduce constant disk access for large streamed files, in particular if it's a very long file (like a continuous DJ mix or so) on a hard disk. From the name of this option, I kind of assumed that it would cache x MB from the current read position, so if I have a 70MB file and a 64MB buffer, I'd see some disk activity while the fist 6 MB are read, and after that the device would co back to idling. Not really all that relevant for my own use case as all my music is on SSDs, but from what I remember, this feature was specifically requested to reduce disk access on regular HDDs.

[Jo Li KMC]

Edit: Easy fix.  Just set MOD playback mode to FT1 in the "MOD" settings.  Thank you, saga!
–

Here's a fun one I discovered the other day.

While playing the ProTracker Module "Sunglasses at Night" by JazzCat, composed in 2014, the mixer hard-pans the module to the extreme left.  This happens around the 1 minute, 20 second mark, just after the cymbal crash at the start of Pattern $0A.  This doesn't happen in ModPlug Player, OpenMPT – and the OpenMPT plugin for XMPlay – or FastTracker II (which plays in mono anyway…?), but it does happen in Scream Tracker III and slowly happens in Impulse Tracker (and presumably Schism Tracker).

From what I can tell, this happens because there's some ProTracker commands in the module which happen to have the same command shortcut as panning options in Scream Tracker III.  I wouldn't think this would be a problem, normally, but this even happens regardless of whether "FT2 Panning" is enabled or disabled in XMPlay.  And that leads me to believe that this is a bug.

I'm using v3.8.5.23 with no mixer plugins enabled, by the way.

[saga]

Setting the MOD playback mode to PT1 should fix that. OpenMPT automatically tries to detect if 8xx/E8x commands are likely meant to be used as panning commands, that's why it automatically disables the panning commands in that track.

[Jo Li KMC]

Huh.  So it does.  Thank you very much!

[saga]

Trying to play this module may crash XMPlay (sometimes takes a try or two): https://modarchive.org/index.php?request=view_by_moduleid&query=194881
Which is a bit ironic given that it appears to be the output of UNMO3.

[Ian @ un4seen]

I don't seem to be able to reproduce that here, so to find out what's happening, can you provide a dump file for it? Please use this latest build (from today) when doing that:

   www.un4seen.com/stuff/xmplay.exe

You can upload the dump file here:

   ftp.un4seen.com/incoming/

[saga]

I have uploaded the dump as xmplay.exe_220127_205723.dmp.7z. I was on an older version (.28) but even with the latest version it still happens, although it took a few more tries this time.

[Ian @ un4seen]

Hmm... there seems to be something wrong with the dump file. How was it generated? Please try again with the ProcDump tool, like this: procdump -e -ma -x . xmplay.exe

[saga]

Hm, I used ProcDump without the -ma flag on the previous dump, not sure what could have been broken about it. Anyway, a new dump has been uploaded as xmplay.exe_220128_172701.dmp.7z (using the options provided by you).

[Ian @ un4seen]

Thanks, the new dump file is loading fine. I'll look into it and hopefully find what's causing the crash. In case it's triggered by something in the config, please also upload your XMPLAY.INI file.

[saga]

I uploaded the INI file as xmplay.ini saga.7z. I was able to reproduce this on two different machines (both Windows 10 x64) with different XMPlay configurations. As mentioned, it may require reloading the file several times in a row to trigger the crash, so it smells a bit like a silent heap corruption.

[saga]

This module has some funky stuff going on with pattern jumps and loops, and while the song length detected by XMPlay seems to be about right, it starts fading out at around 16 seconds in here, so the playback engine apparently concludes it already reached the song end.

[Ian @ un4seen]

I uploaded the INI file as xmplay.ini saga.7z. I was able to reproduce this on two different machines (both Windows 10 x64) with different XMPlay configurations. As mentioned, it may require reloading the file several times in a row to trigger the crash, so it smells a bit like a silent heap corruption.

It turns out the problem is triggered by a very particular set of conditions: there needs to be combined portamento and offset commands, with the offset being beyond the end of the sample, and the sample currently playing in the reverse phase of a bidirection loop. That's all occurring in channels 7/8 at various rows in order 13. When it does happen, XMPlay will end up trying to access beyond the end of the sample's memory, which will result in a crash if there is nothing else beyond it.

Here's an update that should fix the problem:

   www.un4seen.com/stuff/xmplay.exe

This module has some funky stuff going on with pattern jumps and loops, and while the song length detected by XMPlay seems to be about right, it starts fading out at around 16 seconds in here, so the playback engine apparently concludes it already reached the song end.

Yep, that's a funky file. It's the E63 command at 14.0 that's causing the confusion for XMPlay's end detection. I've make a little change in the update above that seems to get this file working properly, but there's always a chance that fixing things for one funky file will break things for others, so please let me know if you do find any others are now broken.

[saga]

It turns out the problem is triggered by a very particular set of conditions: there needs to be combined portamento and offset commands, with the offset being beyond the end of the sample, and the sample currently playing in the reverse phase of a bidirection loop.

That's very specific indeed... And I can confirm that the new version is no longer crashing, even after several tries.

Yep, that's a funky file. It's the E63 command at 14.0 that's causing the confusion for XMPlay's end detection. I've make a little change in the update above that seems to get this file working properly, but there's always a chance that fixing things for one funky file will break things for others, so please let me know if you do find any others are now broken.

I have recently completely changed how OpenMPT approaches song length calculation and loop detection, which may be interesting for XMPlay/BASS as well. It takes a bit more memory for the bookkeeping of already-played rows, but by construction it will always terminate and can even detect those tricky infinite SBx/E6x loops.
In a nutshell, instead of just storing a boolean value for each row whether it has been visited or not, the current state of all E6x/SBx loop counters is stored as well. With this extra data, a row will only be considered to be the same as a previously visited row if both the boolean value is true and the loop states for all channels match. To reduce memory consumption and speed up the comparison, it's possible to hash the loop states instead of storing them explicitly (I chose the FNV-1a hash for its simplicity). This approach will double the reported length of this module (because of the E6x commands that don't actually do anything during regular playback) but it won't think that it has reached the end of the module in random places.

[saga]

The latest "stuff" versions seem to have changed something about the hover effect in the playlist. While it still seems to look fine in the default skin, it now darkens instead of brightens the hovered item when using the Neutron skin, as can be seen in the attached screenshot. This makes the text rather unreadable!

[Ian @ un4seen]

Yep, recent builds have included some skinning tweaks, to improve and simplify a few things. That Neutron skin dodginess is due to simplifications

Previously, the scaler_lit/pressed skinconfig settings have been inverted when applied to playlist text (unless the scaler_listtext option introduced in 3.8 is used), eg. if a scaler normally brightens then it would darken the text instead. As of the update, the scalers are never inverted. The reason for this change is that the inverted scalers can make the text less readable, because the text and background colours end up moving towards each other, eg. bright text gets darker and a dark background get brighter, or vice versa. Initially, an exception was made for skins with black backgrounds because they may rely on the inverted scaler to make a track's status visible (scalers have no effect on the black background), but that exception was removed in the last build because exceptions like that are messy and complicate things for skinners. Better to update any adversely affected skins instead, I think. That should generally just involve adding a scaler_listtext setting to the skinconfig. Here's such a Neutron update:

   www.un4seen.com/stuff/Neutron.zip

Please let me know if you spot any other skins that are adversely affected.

[saga]

Thanks, that looks much better.