▲

[Ian @ un4seen]

The library window's "last play" column does always show "now" for the current track, but the stored value shouldn't change until after the "Count as played after x secs" period. If you close the track before then, you should see its old "last play" value again. Do you not?

Unfortunately, this no longer works. Every radio station, no matter how briefly it was played, immediately receives a new entry in the "last play" column. This still worked until version 3.8.5. Also "now" only appeared after x seconds in version 3.8.5.

That's strange, I'm not seeing a difference on this matter between XMPlay 3.8.5 and 4 here. In both cases, "now" appears immediately in the library's "last play" column when opening a track, and the original value reappears if the track is closed before the "Count as played after x secs" period. If you haven't already done so, please try the latest build, just in case the problem is something that's already been fixed:

   www.un4seen.com/stuff/xmplay.exe

If the problem persists, is it only affecting radio station streams (not local files), and if so, can you give an example affected URL to check? Also confirm your "Count as played after x secs" setting.

I've tried all the above, sadly 4.0.0.6 still doesn't do it for me. Not even after renaming the .ini and resetting the config. Also no difference when the tracks change.

Do you at least see the XMPlay icon in the system tray when you set it there? Please also confirm where you have the taskbar and tray positioned on the screen, in case that's making a difference.

[Sigma Seven]

I've tried all the above, sadly 4.0.0.6 still doesn't do it for me. Not even after renaming the .ini and resetting the config. Also no difference when the tracks change.

Do you at least see the XMPlay icon in the system tray when you set it there? Please also confirm where you have the taskbar and tray positioned on the screen, in case that's making a difference.

Yes the icon is shown in the system tray as soon as I set it, no problem.

Both the taskbar and systray are positioned in their default location, the tray at the bottom on the left, and the systray at the bottom on the right.

[Ian @ un4seen]

The title bubbles should appear just above the systray in the bottom-right of the screen in that case. To check if they're being covered by something else, please try minimizing everything so that only the desktop is showing. If you still don't see them, do you see title bubbles in fullscreen visualization mode? They'll be larger and near the middle of the screen then.

[Sigma Seven]

The title bubbles should appear just above the systray in the bottom-right of the screen in that case. To check if they're being covered by something else, please try minimizing everything so that only the desktop is showing. If you still don't see them, do you see title bubbles in fullscreen visualization mode? They'll be larger and near the middle of the screen then.

Yes I always tested it everything minimised, sadly no luck.

Regarding the other bit, oddly enough, I can confirm that the title bubble shows upon hotkey trigger in fullscreen visualization mode. Only in fullscreen though.

It's in the middle of the screen, in larger font.

[Ian @ un4seen]

OK, so the shortcut key and fullscreen title bubbles are working, but not the system tray title bubbles for some reason. I may need to send you a debug version to get more info on that. First, just to be sure, please confirm that the shortcut key is global ("global" is shown next to it in the shortcuts list) and that the "Tray title bubbles" option is enabled in the "Titles" options page.

[Sigma Seven]

OK, so the shortcut key and fullscreen title bubbles are working, but not the system tray title bubbles for some reason. I may need to send you a debug version to get more info on that. First, just to be sure, please confirm that the shortcut key is global ("global" is shown next to it in the shortcuts list) and that the "Tray title bubbles" option is enabled in the "Titles" options page.

Yes the shortcut is global and the tray title option is set.

[Ian @ un4seen]

I've sent you an email (to the address in your forum profile) regarding a debug XMPlay version. If you don't see it, please also check your junk/spam folder.

[Sigma Seven]

I got the email, thanks.

[kakuyoshi]

Is there a way to display the bit depth in WAV or WavPack?

[Ian @ un4seen]

Yes, that info is shown in the general info window's "Resolution" field.

[kakuyoshi]

I understand, thank you very much

[saga]

When scanning for missing files, XMPlay seems to take both the filename and the known filesize into account. A while ago I have recompressed a large part of my FLAC collection, and XMPlay wasn't aware of the new smaller filesize, so I believe that this is the reason why XMPlay managed to locate some missing files after moving them, but others it didn't manage to locate, even if I pointed it right at the directory containing the files. In the general case this design makes sense, but I think it would be nice to have the option to scan for missing files ignoring file size mismatches.

[piovrauz]

Here's an update that extends the "%USERPROFILE%" support (in playlists) to tool and encoder command-lines:

    www.un4seen.com/stuff/xmplay.exe

Taking your example, %USERPROFILE% would be "C:\Users\secretusername", so you could use "%USERPROFILE%\AppData\Local\ocenaudio\ocenaudio.exe".

Thanks a lot, it's doing exactly what I wanted/needed.
Took me a while to come back and check, things happened.

Oh, and the now site / forum is beautiful.
Essential and to the point, just how like it - too bad the rest of the web doesn't care.

[Knurek]

Would it be possible to add Amiga style sufix.prefix filenames handling to priority filetypes?

I'm using the Delix plugin to play some of the exotic Tracker types, and have mod as priority extension set to Delix.

If I take, for example, mod.level1 from Premiere game rip and try playing it with XMPlay, it's detected as a Generic MOD and played (extremely incorrectly) by the XMPlay PT routine.
But if I manually rename the file to level1.mod (and have the mod priority filetype in Delix set), it gets passed on to Delix and is played correctly.

Would it be possible for the module to play without having to rename it?

[Ian @ un4seen]

Would it be sufficient for XMPlay to only recognise "mod." prefixes and no others? I'm not very familiar with Amiga filenaming conventions but from what I see on download sites it seems like prefixes generally aren't used for other file formats? I'd like to minimize false filetype detections, eg. on a MIDI.TXT file.

[Knurek]

Would it be sufficient for XMPlay to only recognise "mod." prefixes and no others? I'm not very familiar with Amiga filenaming conventions but from what I see on download sites it seems like prefixes generally aren't used for other file formats? I'd like to minimize false filetype detections, eg. on a MIDI.TXT file.

I'm not 100% sure, but I think having it be restricted to mod.* should be enough...
Other formats use their own prefixes, but aren't usually structured like ProTracker modules internally, so don't cause problems from what I could gather.

[Ian @ un4seen]

I'm not 100% sure, but I think having it be restricted to mod.* should be enough...

OK, here's an update for you to try then:

    www.un4seen.com/stuff/xmplay.exe

Let me know if you have any trouble with it.

When scanning for missing files, XMPlay seems to take both the filename and the known filesize into account. A while ago I have recompressed a large part of my FLAC collection, and XMPlay wasn't aware of the new smaller filesize, so I believe that this is the reason why XMPlay managed to locate some missing files after moving them, but others it didn't manage to locate, even if I pointed it right at the directory containing the files. In the general case this design makes sense, but I think it would be nice to have the option to scan for missing files ignoring file size mismatches.

Yes, XMPlay will usually also check that the file size matches (when it's known), but the update above adds an "Ignore file size" option to the "Scan for new locations" folder selector to disable that.

[Alex Mortar]

When XM started some artifacts from other windows appears on skin. This things is only when application started. On previous versions there was never such problem. Suspect it is because of new skin color transparent engine

[Ian @ un4seen]

I haven't seen that problem so far. Is it a skin-specific issue, ie. it only happens with some skins? If so, please give examples of affected and unaffected skins to see if there's a pattern. Also, does it happen every time you start XMPlay or only sometimes? And does it also happen when switching skins? Please also confirm what Windows version you're using.

[Alex Mortar]

There is no problem with standard 4.0 skin. I tested MMD3,WAmodern and Escape and this problem appears on all of them.

https://printskrin.ru/i/snapshot-1.eBulwk


It happens every time but only when started, when switch there is no problem. I use  win 10 x64