next »

[Ian @ un4seen]

If you scroll above the volume bar, the new version steps 3 units. Maybe it's related to the system default scrolling.
I know I am cantankerous, but I liked 5 units/step version better. Is there any xmplay.ini command, which I can use for set it back?

Here's an update that adds a "VolStep" XMPLAY.INI option to set the size of the mouse wheel volume adjustment...

   www.un4seen.com/stuff/xmplay.exe

Just associated XMPlay with MP3 files, 'Play all' starts WMP. Associated XMPlay with M3U as well, 'Play all' then loads the mp3s and the m3u in a single XMPlay (or the current one, if available).

Do the MP3s still get loaded in WMP, while the M3U gets loaded in XMPlay? If not, what happens if you remove the M3U association (via XMPlay's Integration options), eg. do the MP3s still get loaded in XMPlay?

The "latching-on" of 25% of my cpu was caused by the Library monitoring in combination with some other plug-in, I believe it's SNESAMP but I can't be sure.
While testing, this even caused some crashes too. I have no idea why, XMPlay just closed for no reason. No "This program has quit unexpectedly" or anything....

Easy fix though, turn off any monitored directories.

Was the initial scan completed, or was it still scanning the directory for tracks? You can confirm whether scanning is in progress by looking for "scan" in the "Entries" column in the Library options page. If the directory contains a lot of files (particularly archives), the initial scan could take a while, but once complete, it should subsequently only scan new files as they appear.

[Dotpitch]

Just associated XMPlay with MP3 files, 'Play all' starts WMP. Associated XMPlay with M3U as well, 'Play all' then loads the mp3s and the m3u in a single XMPlay (or the current one, if available).

Do the MP3s still get loaded in WMP, while the M3U gets loaded in XMPlay? If not, what happens if you remove the M3U association (via XMPlay's Integration options), eg. do the MP3s still get loaded in XMPlay?

I must add I used a folder with MP3s and an M3U, that does seem to make a difference.

• If only MP3s are present, the program which is associated with the MP3 extension is launched are gets all the MP3 files in the folder when clicking the 'Play all'-button.
• If an M3U file is present, the program associated with M3Us is launched, irrespective of the association for MP3. The program gets the M3U and all of the MP3 files.

The order of applying the association doesn't matter. In all cases where XMPlay is launched, only a single instance is activated, not one for every file.

[saga]

http://amp.dascene.net/downmod.php?index=25393
truncated xm file. XMPlay used to play it, now it just refuses to do so.

[oddiophile]

There's a bug with the visualisations in the latest 'stuff' build (3.6.0.5):

If you close XMPlay while a visualisation is selected / active , the next time you run the player, visualisations won't work (you must select 'No visualisations' before closing XMPlay or you'll get a black screen on the next run).

[EDIT] 'Allow multiple instances' is unchecked

[Chinese Sausage]

No such thing in my XMPlay settings (3.6.0.5). My visualizations do work even if I close XMPlay with the visualizations in.
Do you have "Allow multiple instances" checked under "Miscellaneous" options?

Cheers!

[saga]

As indicated in the 3.7 thread, i'm having the same problem with broken visualisations, allow multiple instances is disabled.

[bronth]

I'm not sure if this is a XMPlay or Windows bug, but sometimes when I load a CD not all tracks are being added to the playlist. Sometimes the number of loaded tracks may correspond to the previously played CD. Reloading the current CD usually fixes the problem. (Also it seems that the problem doesn't occur with a fresh "installation" of XMPlay, but I might be wrong...)

[Dotpitch]

Changelog for XMPlay 3.6  Go here...

[Chinese Sausage]

When changing skins, the Extended Playlist/Library window keeps shrinking in size. Is it possible to fix this in 3.6, or better yet, have XMPlay remember the settings for each skin?

Thanks in advance!

Sounds like you have "Auto-resize" ticked (top left of the playlist). Remembering the size for each skin would be new though.

I suspect it may actually be with "Auto-resize" disabled. XMPlay will try to retain the info window size then, but that may not be possible while keeping a whole number of playlist/library entries displayed. Here's an update that should at least not always favour shrinking the window over expanding it in that case...

There is a similar problem with the Extended Playlist/Library window width, as it tends to grow in size when changing skins (with "Auto-resize" disabled).

[Pike84]

It seems that often the track's name changes well before the actual track change, and this also affects the queue. For example, just now I manually stopped a track a little less than a second before the track change (the timer showed -0.7 at the time), but the following queue item was already gone.

I'm not able to reproduce this consistently, but it seems to happen often, and has done so for a long time. The last time it was a normal mp3 track.

My sound card is currently Sound Blaster X-Fi Go!, and according to my memory, it's also been a basic X-Fi (Xtreme Gamer) and Audigy 2 for the time this has been happening.

[raina]

Could it be related to cross-fading?

[Cris]

It's reated to the buffer size (Options -> Output). The next file is loaded when the current one has less time left than the buffer size.

[Pike84]

Ah, now I remember it's been discussed before... Can it be "fixed" though? I mean, it may be useful to have some buffer available, but I don't think it should affect the track change point.

[Ian @ un4seen]

I suspect it may actually be with "Auto-resize" disabled. XMPlay will try to retain the info window size then, but that may not be possible while keeping a whole number of playlist/library entries displayed. Here's an update that should at least not always favour shrinking the window over expanding it in that case...

There is a similar problem with the Extended Playlist/Library window width, as it tends to grow in size when changing skins (with "Auto-resize" disabled).

Did you happen to have the window set skinny? If so, it could be that it was too skinny for some skins; each skin has a minimum window size determined by the size of its bitmaps. If the problem is happening even with the window set wide, please give 2 skins that demonstrate the problem when switching between them.

It seems that often the track's name changes well before the actual track change, and this also affects the queue. For example, just now I manually stopped a track a little less than a second before the track change (the timer showed -0.7 at the time), but the following queue item was already gone.

I'm not able to reproduce this consistently, but it seems to happen often, and has done so for a long time. The last time it was a normal mp3 track.

To achieve gapless playback, the next track needs to be ready to go before the current track finishes playing. So once the current track has finished decoding, XMPlay will close it and open the next one. That allows the next track to take up to the length of the output buffer to become ready without introducing a gap. That transition won't normally be obvious because the title/etc display won't be updated until the next track is actually heard (you can see it in the playlist though), but if you press stop during it, then the display will be updated immediately to reflect the new current track.

[tails_]

Um. What changed in 3.6.0.8 version?

[Dotpitch]

Read here.

[tails_]

Oh and about rsn format (RARed SPC tunes). In older version (3.4 iirc) they were opened with rar unpacker and all tunes was visible in playlist but now i get only 1st tune from archive with rsn extention (so it looks like unpacking handled by input plugin).
Btw can be "priority filetypes" added like for input plugins?

[Pike84]

To achieve gapless playback, the next track needs to be ready to go before the current track finishes playing. So once the current track has finished decoding, XMPlay will close it and open the next one. That allows the next track to take up to the length of the output buffer to become ready without introducing a gap. That transition won't normally be obvious because the title/etc display won't be updated until the next track is actually heard (you can see it in the playlist though), but if you press stop during it, then the display will be updated immediately to reflect the new current track.

Thanks for the explanation. I'm not sure I understand all of this functionality, but still...

Can it be "fixed" though?

I'd like the track change to always occur exactly when the timer/title change says so - I don't even care if the next track would have to be completely preloaded into memory or something like that, I just want it to be spot on, regardless of the buffer setting. The problem I described earlier is still there.

[Chinese Sausage]

I suspect it may actually be with "Auto-resize" disabled. XMPlay will try to retain the info window size then, but that may not be possible while keeping a whole number of playlist/library entries displayed. Here's an update that should at least not always favour shrinking the window over expanding it in that case...

There is a similar problem with the Extended Playlist/Library window width, as it tends to grow in size when changing skins (with "Auto-resize" disabled).

Did you happen to have the window set skinny? If so, it could be that it was too skinny for some skins; each skin has a minimum window size determined by the size of its bitmaps. If the problem is happening even with the window set wide, please give 2 skins that demonstrate the problem when switching between them.

The window is not set in what I consider skinny, it has a considerable good size for the info being displayed. I only noticed this problem when switching to the Aiwa skin. There is a change in size with some of the other skins (WMP 10, A-Round), vertically, although not as much as it used to be.

[Ian @ un4seen]

I'd like the track change to always occur exactly when the timer/title change says so - I don't even care if the next track would have to be completely preloaded into memory or something like that, I just want it to be spot on, regardless of the buffer setting. The problem I described earlier is still there.

OK, here's an update that adds a "NoPreload" XMPLAY.INI option to disable the preloading of the next track (unless crossfading is enabled)...

   www.un4seen.com/stuff/xmplay.exe

Note that it will also prevent gapless playback.

The window is not set in what I consider skinny, it has a considerable good size for the info being displayed. I only noticed this problem when switching to the Aiwa skin. There is a change in size with some of the other skins (WMP 10, A-Round), vertically, although not as much as it used to be.

The minimum width of the Aiwa skin info window is 580 pixels, which is pretty wide. Did you have it skinnier than that before switching to the Aiwa skin?

You can tell whether the info window is as small as it can be by trying to make it smaller