Author Topic: 3.8 reports, queries and bugs  (Read 278658 times)

saga

  • Posts: 2551
Re: 3.8 reports, queries and bugs
« Reply #825 on: 24 Sep '21 - 14:31 »
You'll need the MMCMP plugin because the file is compressed.

Metro28

  • Posts: 4
Re: 3.8 reports, queries and bugs
« Reply #826 on: 24 Sep '21 - 15:26 »
You'll need the MMCMP plugin because the file is compressed.
Thanks! ;D
It is difficult to find an XMPlay bug >:(

saga

  • Posts: 2551
Re: 3.8 reports, queries and bugs
« Reply #827 on: 29 Oct '21 - 14:18 »
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

  • Administrator
  • Posts: 23997
Re: 3.8 reports, queries and bugs
« Reply #828 on: 29 Oct '21 - 18:00 »
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

  • Posts: 2
Re: 3.8 reports, queries and bugs
« Reply #829 on: 31 Oct '21 - 08:28 »
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

  • Posts: 2551
Re: 3.8 reports, queries and bugs
« Reply #830 on: 31 Oct '21 - 11:47 »
Quote
If you call GetDriveType on your drive, what does it report?
It returns 3, just like for the system SSD.

Quote
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

  • Administrator
  • Posts: 23997
Re: 3.8 reports, queries and bugs
« Reply #831 on: 2 Nov '21 - 18:00 »
Quote
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

  • Posts: 2551
Re: 3.8 reports, queries and bugs
« Reply #832 on: 2 Nov '21 - 18:27 »
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

  • Posts: 2551
Re: 3.8 reports, queries and bugs
« Reply #833 on: 3 Nov '21 - 15:02 »
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

  • Posts: 26
Re: 3.8 reports, queries and bugs
« Reply #834 on: 28 Nov '21 - 14:14 »
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.
« Last Edit: 28 Nov '21 - 23:06 by Jo Li KMC »

saga

  • Posts: 2551
Re: 3.8 reports, queries and bugs
« Reply #835 on: 28 Nov '21 - 18:24 »
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

  • Posts: 26
Re: 3.8 reports, queries and bugs
« Reply #836 on: 28 Nov '21 - 23:05 »
Huh.  So it does.  Thank you very much!