4.0 reports, queries and bugs

[Rah3D]

Hey again, I think I found a small bug:
If "Interface > Show in:" is set to either "tray" or "taskbar and tray", info bubbles will always be shown on a song change, even when they're turned off. I also tried with a fresh xmplay.ini, same behavior. Version is 4.0.0.1.

[Ian @ un4seen]

The new advanced drag&drop in XMPlay 4.0 can be quite useful at times, but I feel that most of the time it hinders my playlist editing. If I wanted to move a track a long way across the playlist, for example, I could just drag it way outside of the XMPlay window, which would then move it in the playlist very quickly. Now, dragging it outside of the window does something completely different.

Here's an update for you to try, which will scroll more quickly when hovering closer to the top or bottom edge of the list:

    www.un4seen.com/stuff/xmplay.exe

If compatibility already needs to be broken anyway, maybe it would be an opportunity to design new field extensions in a way that would remain backwards-compatible using key/value pairs, assuming that older XMPlay versions would then keep unknown keys in the library even when modifying it?

Yeah, perhaps something like that. I'll have to think about this some more before making any library format changes.

Hey again, I think I found a small bug:
If "Interface > Show in:" is set to either "tray" or "taskbar and tray", info bubbles will always be shown on a song change, even when they're turned off. I also tried with a fresh xmplay.ini, same behavior. Version is 4.0.0.1.

Are you seeing the new song's title appear by the tray? If so, please confirm whether you have "Tray title bubbles" disabled in the "Titles" options page. The tray titles aren't affected by the "Show info bubbles" setting in the "Interface" options page, so that the info bubbles/tooltips and tray titles can be controlled separately. There's also a separate setting for fullscreen vis titles.

[saga]

Here's an update for you to try, which will scroll more quickly when hovering closer to the top or bottom edge of the list:

This works a bit better, but it still feels a bit unnatural that e.g. dragging the cursor slightly outside of the playlist panel (e.g. into the window title area right above) doesn't allow the dragging to continue. Maybe the auto-scrolling could continue while the cursor is still above window elements of XMPlay itself that wouldn't allow the song to be dropped into anyway?

[Rah3D]

Hey again, I think I found a small bug:
If "Interface > Show in:" is set to either "tray" or "taskbar and tray", info bubbles will always be shown on a song change, even when they're turned off. I also tried with a fresh xmplay.ini, same behavior. Version is 4.0.0.1.

Are you seeing the new song's title appear by the tray? If so, please confirm whether you have "Tray title bubbles" disabled in the "Titles" options page. The tray titles aren't affected by the "Show info bubbles" setting in the "Interface" options page, so that the info bubbles/tooltips and tray titles can be controlled separately. There's also a separate setting for fullscreen vis titles.

Ooooooh, that's it. I haven't changed this option in decades, literally - I forgot it even existed! I assumed it must be the "Info Bubbles/Tooltips" option since it also changes the text size of the title bubble. Usually I just copy my existing XMPlay directory when setting up a new computer, but this time I started from scratch, re-enabling that option. Thanks for reminding me! It's not a bug then, sorry!

[Hal]

Hey, what happened to the "Show filenames in extended list" option? In 4.0 it's gone. It's the main reason preventing me from using 4.0.

[Ian @ un4seen]

That option is now in the playlist's right-click menu ("Display columns" submenu) and can be enabled in either the main or extended playlist. A "List - Show filenames" keyboard shortcut can also be set for toggling it.

[saga]

The first time I switch to the visuals view, there is usually a multi-second delay, which hasn't always been there (could coincide with the 4.0 update but I really don't know anymore). It happens regardless of whether I use the 3D spectrum or the pattern visualizer. In the latter case, an initial frame is drawn, then the pattern contents don't update for several seconds, after which the pattern vis finally continues scrolling.

[Ian @ un4seen]

This works a bit better, but it still feels a bit unnatural that e.g. dragging the cursor slightly outside of the playlist panel (e.g. into the window title area right above) doesn't allow the dragging to continue. Maybe the auto-scrolling could continue while the cursor is still above window elements of XMPlay itself that wouldn't allow the song to be dropped into anyway?

Here's an update for you to try, which allows jumping to other playlist positions by dragging over the scrollbar:

    www.un4seen.com/stuff/xmplay.exe

The first time I switch to the visuals view, there is usually a multi-second delay, which hasn't always been there (could coincide with the 4.0 update but I really don't know anymore). It happens regardless of whether I use the 3D spectrum or the pattern visualizer. In the latter case, an initial frame is drawn, then the pattern contents don't update for several seconds, after which the pattern vis finally continues scrolling.

That sounds strange. There could be a small delay opening the vis window for the first time, as the vis plugins are all checked and their names got. But I'm not sure what could be causing a delay after a frame has already been drawn. Do you have any vis plugins installed? If so, does it still happen if you remove all of them? Please also check whether it happens after replacing the EXE (ie. in the same folder) with the 4.0 release version or 3.8.5, to perhaps narrow down when the problem was introduced. Also check with a different skin, in case it's something skin-specific.

[saga]

I don't have any vis plugins installed (except for those offered by input plugins). Intererestingly it doesn't happen every time, which makes it harder to analyze. For example, just now restarting XMPlay three times in a row, it didn't happen. I'll report back if I find any more reliable reproduction steps.

[Rah3D]

I don't have any vis plugins installed (except for those offered by input plugins). Intererestingly it doesn't happen every time, which makes it harder to analyze. For example, just now restarting XMPlay three times in a row, it didn't happen. I'll report back if I find any more reliable reproduction steps.

I think I had Windows Defender interfere with visuals before. When Defender took too long to scan during vis startup, XMPlay just dropped the vis and could not load it until I restarted XMPlay.

[saga]

As said, there are no vis plugins, they all come from input plugins which are loaded when XMPlay starts up, so interference with Defender seems unlikely.

[alystair]

Registered specifically to submit this bug. See attached - since 4.0 my favorite skin ("HeavyDuty" by Tero Niemi, 2007) has been bugging out sometimes where the side panel when kept closed hides the main area.

I haven't been able to reproduce that so far. Are there any particular steps to make it happen? Please also confirm what Windows version you're using.

Maybe it's specific to this skin? Latest Win 11 on beta stream (26120.5733). It's intermittent, for additional context I usually keep the playlist section open.

[Lomaxx]

I can't drag the XMPlay window to the 2nd monitor. If I try and move it (slowly for testing) XMPlay is shown about pretty much exactly halfway on the 2nd monitor, but as soon as I move it any further it jumps back to the main-monitor while the mouse-cursore continues to move correctly on the second monitor.

I'm running on Windows 11 without an 32"-4K-Mainmonitor and an old 17" 1280x1024 2nd-Monitor. GFX-Card is a Geforce RTX 4070 Super.

As far as I remember XMplay is the normal installation with a few decoder plugins maybe and one addition skin (XMPlay 3 default), but it also happens with default skin. Windows scaling is set to 150% and mouse cursor-size is also increased.

If you need more info or testing let me know, but for now i leave this report as it is.

[Ian @ un4seen]

Strange, I'm unable to reproduce that here. To see if it's related, please try resetting the Windows scaling and mouse cursor-size, and see whether that helps. Also confirm the monitor layout that you have set in the control panel, and whether changing that helps.

I don't think there have been any changes that would affect this, but you could still give the latest XMPlay build a try:

   www.un4seen.com/stuff/xmplay.exe

[Cosworth]

By the way, I previously noticed that XMPlay had a slow start when loading all components (skins, plugins, etc.).
I discovered that the issue was caused by the Antimalware Service Executable.
It was difficult to disable it permanently.

But once I finally managed to disable it, XMPlay started immediately, just as it should.

[Lomaxx]

Yep. It's Windows Scaling that has an incompatiblity with XMPlay (or the other way round). I just tried setting scaling to 100% and I had no problems to move the app to the 2nd monitor.

Not that much of helpful info, but anyway: If i set scaling to 100%, move XMPlay to 2nd monitor and then set scaling to 150%, then XMPlay stays on the 2nd monitor. If i then try to move it back without changing scale, it doesn't work too.

And I noticed that while being on the 4k monitor XMPlay-size is affected by changing scaling (normal behaviour), but XMPlay-size is NOT being affected by changing scaling, when on the 2nd monitor. Only when I try to drag it back to the mainmonitor with scaling set to 150%, then the XMPlay-window jumps away from mousepointer-position AND is scaled larger than before until I stop holding the mousebutton.

I hope this isn't too confusing, but helpful instead. It's hard to describe accurately and I am tired too. ^^ Let me know if you want more info, or some crappy smartphonevideo of the behaviour (I doubt, that screenrecording this works). Then I create a forum account somehow exchange info-data that way.

[Lomaxx]

oh, little update: I just found out that I can change scaling individually in the windows-settings by selecting the specific monitor. Didn't even know that. xD If i set scaling of the 2nd-monitor to 150% too (so both monitors have that scaling), then I also can move XMPlay over without problems

[Ian @ un4seen]

By the way, I previously noticed that XMPlay had a slow start when loading all components (skins, plugins, etc.).
I discovered that the issue was caused by the Antimalware Service Executable.
It was difficult to disable it permanently.

But once I finally managed to disable it, XMPlay started immediately, just as it should.

"Antimalware Service Executable" checks for viruses in files that you open, so it's probably not a good idea to totally disable that (unless you have another antivirus installed). If it's delaying XMPlay's launch too much then you could just whitelist XMPlay's folder (add an "exclusion" for it).

Yep. It's Windows Scaling that has an incompatiblity with XMPlay (or the other way round).

Ah yes, I'm able to reproduce the problem too when the scaling is set differently on each monitor. I'll look into it and hopefully come back with something for you to try.

[Ian @ un4seen]

Yep. It's Windows Scaling that has an incompatiblity with XMPlay (or the other way round).

The problem is related to the fact that XMPlay isn't DPI-aware. That also causes things to become blurry when scaling isn't set to 100%. So here's a DPI-aware update for you to try:

    www.un4seen.com/stuff/xmplay.exe

The scaling setting should no longer affect the skinned windows, but still affect the options/etc windows. Let me know if you encounter any problems with it.

[yoba]

So here's a DPI-aware update for you to try

Which is now incompatible with XP because of the manifest:

Syntax error in the manifest or the policy file of "xmplay.exe" in the line 9.
Element "application" is a daughter of the element "urn:schemas-microsoft-com:asm.v1^assembly", which is not supported in this version of Windows.

Surely there is another method to add DPI-awareness

[yoba]

And until there is a fix, temporary solution for XP users - external manifest.
Just create a file named xmplay.exe.manifest next to xmplay.exe, and paste the following:

Code Select Expand

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="XMPlay" version="1.0.0.0" processorArchitecture="*"/>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/>
</dependentAssembly>
</dependency>
</assembly>

Looks like XP is not support <application> section in programs' manifests, so that just identical but without

Code Select Expand

<application>
<windowsSettings>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
</windowsSettings>
</application>section

[bauxite69]

The problem is related to the fact that XMPlay isn't DPI-aware. That also causes things to become blurry when scaling isn't set to 100%. So here's a DPI-aware update for you to try:

    www.un4seen.com/stuff/xmplay.exe

The scaling setting should no longer affect the skinned windows, but still affect the options/etc windows. Let me know if you encounter any problems with it.

Awesome! My setup is maxed out at 250% on a 55" 4K screen and finally, nothing is blurry anymore.

Thanks !!!

[Ian @ un4seen]

So here's a DPI-aware update for you to try

Which is now incompatible with XP because of the manifest:
...
Surely there is another method to add DPI-awareness

Oops! The DPI-awareness only applies on Windows 10/11, so it won't have any effect on XP but XMPlay should still work there. Here's another update to fix that:

    www.un4seen.com/stuff/xmplay.exe

[TheLomaxx]

Just saw your replies and tried out the .exe. Dragging between monitors works flawless so far. I will report anything unusual I discover. Thanks a lot for the effort.

[saga]

It appears that the "last play" logic that differentiates between the previous last play and "now" broke. For example, I just started playing a tune and checking the library immediately after it started playing, it says "Now (Sat Sep 13 20:18:00 2025)", while it should be "Now (<date whenver it was last played>)".

Edit: Doesn't seem to happen at all times? Not sure yet what's triggering it...