Topic: 3.8 reports, queries and bugs

[FIX94]

Is the track info not appearing at all or is it just delayed? When adding new files to the playlist/library, only the file's format is checked (not its tags/etc), so that the files can be added more quickly.

The info is not appearing at all interestingly enough, you can still use the file I uploaded yesterday to see what I mean. Now you have to have in_mdx as plugin in the folder though for the file to be put in at all, it will be rejected otherwise, with plain 3.8.3 you were able to drop it in without that plugin so xmplay does seem to do some filetype check now, but somehow still initially pulls in the title wrong as you can see in the picture I attached. Also the tracks in that picture where the title does not appear were also the tracks that without a plugin in plain 3.8.3 you could drop in and made it crash when trying to play them back.

[Ian @ un4seen]

I don't seem to be able to reproduce the problem with the test file you provided; the title is appearing in the playlist without playing the file. Perhaps some other plugin is conflicting. If you remove all other plugins (except the MDX plugin), does the problem still happen then? If not, please try reintroducing the plugins one by one to find the culprit.

[FIX94]

I don't seem to be able to reproduce the problem with the test file you provided; the title is appearing in the playlist without playing the file. Perhaps some other plugin is conflicting. If you remove all other plugins (except the MDX plugin), does the problem still happen then?

Just tried it, made a new folder and only put xmplay.exe and in_mdx in, still has the same issue, interestingly enough this issue appears to only happen on my windows 10 installation, I just tried it in a xp and windows 7 vm and both of those had no issues, weird.

[Ian @ un4seen]

Ah, yes. Media Foundation on Win10 is detecting the file to be AAC/ADTS (the file does contain an ADTS syncword). XMPlay pre-checks the file's format (a bit more strictly) itself before trying Media Foundation when playing a file but not when scanning info. Here's an update that applies the same pre-checking during info scanning:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still see the problem happening.

[FIX94]

Ah, yes. Media Foundation on Win10 is detecting the file to be AAC/ADTS (the file does contain an ADTS syncword). XMPlay pre-checks the file's format (a bit more strictly) itself before trying Media Foundation when playing a file but not when scanning info. Here's an update that applies the same pre-checking during info scanning

Awesome, it seems to work perfectly now how it used to in 3.8.2, thanks a lot

[Dhry]

Loaded up XMPlay and updated to latest stuff version (3.8.3.2 at time of writing) to listen to the newest update of the HVSC using Fraggie's plugin. After playing a track, XMPlay froze up. I thought at first it could be because I was using WASAPI. Juggled a few settings, still had a problem. Switched to Directsound, still jacked. Went to the official release 3.8.3 and tracks play fine.

When it jams up it's right when a track has finished and it's about to load the next track.

Cheers
Dhry

[Ian @ un4seen]

That's strange. I guess it must be related to the update's crossfading tweak; do you have crossfading enabled, and if so, does disabling it stop the problem? I can't reproduce the problem here in either case, so perhaps it's triggered by a combination of settings. Please upload your XMPLAY.INI file to have a look at here:

   ftp.un4seen.com/incoming/

[sevendy]

OK, I tried to report this earlier, but since I could not reliably reproduce the problem, I deleted the post. New versions of XMPlay sometimes trigger Malwarebytes heuristic detection:

MachineLearning/Anomalous.100%, C:\PROGRAM FILES (X86)\XMPLAY\XMPLAY.EXE

whatever that means. I assume this is a false positive (?!), but see: https://forums.malwarebytes.com/topic/215911-malwarebyte-false-detected-my-software-as-machinelearninganomalous100/

[Andreasvb]

That's strange. I guess it must be related to the update's crossfading tweak; do you have crossfading enabled, and if so, does disabling it stop the problem? I can't reproduce the problem here in either case, so perhaps it's triggered by a combination of settings. Please upload your XMPLAY.INI file to have a look at here:

   ftp.un4seen.com/incoming/

I got the same issue I think. It locks and uses 25% of the CPU (4 cores), process is running even after you exit.
Works if unchecking Crossfade.

I've uploaded my xmplay.ini.

[Ian @ un4seen]

Thanks, I think I see what the problem is now. It happens when the Fade-out and Crossfade options are both enabled. Here's an update that should fix it:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still see the problem happening.

[Andreasvb]

Thanks, it works now.

[Ian @ un4seen]

Great. The update (3.8.3.3) is up on the XMPlay page now.

[DannyHdez]

I updated to the 3.8.3 version. When I runs the program appears an error and crashes. I can't open the program    Why this happens?. Please help me!. I love XMPlay!!!.

[Ian @ un4seen]

Do you have XMPlay 3.8.3 or 3.8.3.3? You can check the XMPLAY.EXE file properties to find out. If it's 3.8.3, you can get the latter by re-downloading the XMPlay package. If you still get the crash then, please upload a dump file for it, to have a look at. You can generate a dump file using the ProcDump tool. Shift+right-click in your XMPlay folder to open a command window, and run "procdump -e -ma -x . xmplay.exe". Then ZIP and upload the generated dump file to have a look at here:

   ftp.un4seen.com/incoming/

[Scott1]

Small bug i've encountered if i open a folder with xmplay that contains wav files and mp3 files xmplay will process the total time of the mp3 tracks but won't process the total time of the wav files until i click down the list of files then it will add the time of the wav tracks to the total time. Is there a fix for this please or am I missing an option or something?

[aspertyx]

xmplay 3.8.3.3 crash opening http://as-hls-ww-live.akamaized.net/pool_7/live/bbc_radio_three/bbc_radio_three.isml/bbc_radio_three-audio%3d96000.norewind.m3u8

procDump Crash details:
[03:25:38] Exception: 000006BA
[03:25:48] Exception: C0000005.ACCESS_VIOLATION
[03:26:16] Unhandled: C0000005.ACCESS_VIOLATION
[03:26:16] Dump 1 initiated: .\xmplay.exe_180111_032616.dmp
[03:26:16] Dump 1 writing: Estimated dump file size is 118 MB.
[03:26:16] Dump 1 complete: 118 MB written in 0.3 seconds
[03:26:16] Dump count reached.

Dump uploaded to ftp server

[aspertyx]

More info on the xmplay crash.
It appears related to the Real Alternative plugin. Removing the Real Alternative stanza from xmplay.ini allows xmplay 3.8.3.3 to work properly. Strangely xmplay 3.8.3.0 works fine with the Real Alternative stanza included in xmplay.ini.  The crash occurs opening any xmplayable
file.

The RealAudio stanza in xmplay.ini looks like this:
[REALAUDIO]
CodecPath=C:\Program Files (x86)\Real Alternative\Codecs\
LoaderAcceptVideo=0
LoaderLoadLastStream=1
LoaderLimitBufferingOnLiveStreams=1
DisplayStatus=1
DisplayComment=1
DisplayLogicalFileInfo=1

[Ian @ un4seen]

Small bug i've encountered if i open a folder with xmplay that contains wav files and mp3 files xmplay will process the total time of the mp3 tracks but won't process the total time of the wav files until i click down the list of files then it will add the time of the wav tracks to the total time. Is there a fix for this please or am I missing an option or something?

Is the problem that the WAV file lengths aren't being scanned by XMPlay or just that their length isn't included in the playlist's total time display? If the former, I think I see something that could cause a WAV file's info to not be scanned sometimes. Here's an update for you to try:

   www.un4seen.com/stuff/xmplay.exe

If you still have the problem with that... if you open the folder with the extended playlist window open, is the length of the WAV files shown in the length column there? Note the lengths won't appear immediately, as that info is scanned after all of the folder's files have been added to the list.

More info on the xmplay crash.
It appears related to the Real Alternative plugin. Removing the Real Alternative stanza from xmplay.ini allows xmplay 3.8.3.3 to work properly. Strangely xmplay 3.8.3.0 works fine with the Real Alternative stanza included in xmplay.ini. 

Oh yes, I can reproduce that with the XMP-RA plugin installed. The update above should fix it. Let me know if you still see the problem happen.

[Scott1]

Small bug i've encountered if i open a folder with xmplay that contains wav files and mp3 files xmplay will process the total time of the mp3 tracks but won't process the total time of the wav files until i click down the list of files then it will add the time of the wav tracks to the total time. Is there a fix for this please or am I missing an option or something?

Is the problem that the WAV file lengths aren't being scanned by XMPlay or just that their length isn't included in the playlist's total time display? If the former, I think I see something that could cause a WAV file's info to not be scanned sometimes. Here's an update for you to try:

   www.un4seen.com/stuff/xmplay.exe

If you still have the problem with that... if you open the folder with the extended playlist window open, is the length of the WAV files shown in the length column there? Note the lengths won't appear immediately, as that info is scanned after all of the folder's files have been added to the list.

The problem was the the length wasn't included in the playlist's total time display the WAV files scanned ok and were added to the list have tried your update and it has fixed the problem thanks very much Ian

[Dhry]

Thanks, I think I see what the problem is now. It happens when the Fade-out and Crossfade options are both enabled. Here's an update that should fix it:
   www.un4seen.com/stuff/xmplay.exe
Let me know if you still see the problem happening.

Sorry it took a while to get back. Confirmed, the problem is gone now with 3.8.3.3. Thanks Ian!

DRS

[tails__]

I'm not sure this should even be supported, but it works in SDL protracker port  :
https://a.uguu.se/6e48z5LcVI0l_groo_-_the_ultimate_beeper.mod

[Dhry]

Trying to use v1.10 of Yukitty's in_org.dll (Organya module player). If it's in the plugins folder, XMplay dies without even starting. Tried 1.09 and 1.08, same deal. Edit: Just noticed, 1.07 works.
https://github.com/Yukitty/in_org/releases

It's supposed to be for Winamp and compatibles. It's the only Winamp plugin I've tried that doesn't work with XMP. Low pri - just wanted to listen to some Cave Story mods is all. I'll go look for an alternate (I'm surprised that with all the plugins I already have, none of them play that format!)

Cheers
DRS

[Ian @ un4seen]

There are a couple of issues with the plugin's "init" function:

   https://github.com/Yukitty/in_org/blob/master/src/in_org.c#L509

The 1st issue is that XMPlay will call the "init" function before the XMPlay window exists, so the "hMainWindow" value will be 0 there. The 2nd issue is that the IPC_GETINIDIRECTORY message isn't currently supported by XMPlay. I will check if something can be done about this.

[saga]

I guess this is not really a bug but a bit of a design limitation...?
I have a saved setting for an empty path, which resets all the MOD-related settings and other stuff to defaults, so that modules sound the same everytime I play them, no matter if the previous module was using non-default interpolation settings, etc.
However, I would like to extend those to xmp-openmpt as well, and it is not possible to create another path settings for an empty path. XMPlay won't let me do that. So what I'd need is the ability to specify my default settings for more than just one decoder.

[Dhry]

There are a couple of issues with the plugin's "init" function:
   https://github.com/Yukitty/in_org/blob/master/src/in_org.c#L509
The 1st issue is that XMPlay will call the "init" function before the XMPlay window exists, so the "hMainWindow" value will be 0 there. The 2nd issue is that the IPC_GETINIDIRECTORY message isn't currently supported by XMPlay. I will check if something can be done about this.

Thanks Ian! I also posted a bug report on his github. I'll update my post with your findings above, hopefully he can fix that since it was working fine in 1.07.

DRS