Were those CD tracks already in the playlist? If so, please try removing them and then restarting XMPlay. Track info is also retained for playlist entries (not only library entries), so XMPlay wouldn't need to re-request that from the CD plugin if it already exists there.

Regarding the sometimes working and sometimes not issue... I just noticed yesterday that the musicbrainz.org server is now reporting inexact matches (rather than exact matches), although they do still seem to be exact matches. The CD plugin isn't expecting to see that, and it's treating them as an error (no matches). So if you were using the musicbrainz.org server, perhaps that would explain it. Here's an update to try, which will display the CDDB selector whenever inexact matches are reported by the server...

   www.un4seen.com/stuff/xmp-cd.dll

Ian, thank you for the update, have been playing with it for more than a week, and some things have become clearer now. There's indeed probably nothing wrong with the player or plugin themselves (as well as with firewall or Windows settings), and the problem lies in the quality/stability of the info retrieved from FreeDB and Musicbrainz. Somehow it changes depending on the time of day, and for some albums (mostly the recent budget re-pressings of the common remasters) the situation is even worse since there seem to be no single 100% exact match, so the retrieved values are produced via approximation of sorts (i.e., as you should know, there's the multiple choice window with only one matching entry, although so far it's always been a correct one). BTW, did you add the "forced multiple choice" behaviour for Musicbrainz only? A couple times there was no any info at all, and, IIRC, both times I had the FreeDB server set as the default one.

To realize all the aforementioned I tried and re-tried different settings, I even tried to delete the playlist, library and ini files (in addition to removing tracks from playlist), and so far the results have been pretty consistent.

Is that even after closing XMPlay? The cache is only written to disk (if enabled) upon closing XMPlay.

I've finally got how the cache file works. Let's assume I have a "virgin" xmplay install. If there's no matching info from a database the playlist displays only CD track numbers. And if I quit the player the cache file doesn't appear. It appears only after the first true data retrieval.

[BUT.]

What version of xmp-cd do you have? Does the CD contain CD-TEXT? Have you added the tracks to your library?

Rev. 10b that is bundled with the latest zip distributive. As for CD-TEXT - probably not (but I'm not 100% sure - there may be CD-TEXT discs without any actual info containing only track numbers).

What CDDB server do you have set in the CD plugin's options, and does changing that make any difference?

I switched between the two default ones - nothing seemed to help. As well as enabling/disabling CD-TEXT and cache.

Strangely, today track info is back again - and this time I didn't do anything, just loaded another CD in a usual way via right click (I never add CD's to library). And info for all the tracks was loaded at the same time - i.e. almost immediately. BUT. Then I tried to load the previous "problematic" CD (it's the standard latest remaster of Mingus "Ah Um"). The first track started playing and the track info also appeared but only info for this track, not others (those tracks continued to look like "002 2.cda", etc. - not sure, what that "002" does stand for, maybe it's a case of the aforementioned "empty CD-TEXT"?). When the second track started, the second track info appeared, and so on, so you probably got the picture. Ticking/unticking xmp-cd options didn't affect anything, but, at least, this time I got all the info in the playlst by the disc's end. Why this scenario doesn't work every day is beyond my comprehension (provided there's no problems with server connection and all other factors are unchanged as well).

BTW, there's still no new cache file in the xmp directory (it doesn't matter if cache is enabled or not).

The problem with displaying freedb track titles is back. Now nothing seems to help (tried to add xmplay.exe to the Windows firewall manually), moreover, I don't see the cache file anymore (even when caching is enabled). Could anybody help me please?

Not sure if this bug has been discussed. Some time ago (I didn't notice when it exactly happened, perhaps a couple days ago or so) XMPLAY stopped displaying freedb and musicbrainz track info. At first I decided that there's something wrong with my firewall or the servers may be down, but I didn't change any connection options and both sites seemed to work. Switching the servers in the plugin options didn't help, so I decided to delete the CD cache file, and, voilà, the track info is back.  

EDIT: Just noticed that if I play a CD in a usual way (i.e. via right click) then I get track info only for files that are actually being played, not for the whole CD. Strange.
 

Jimmy, yes, I was aware of the "secret" option (as I actually mentioned) but I would strongly prefer to stop/pause using a single click, not to close/restore. It's a very common practice and it's much more fast/convenient than using the context menu via right click.

Not sure if it has been already suggested, but I definitely miss a simple feature found in many other players - a customizeable single-click behaviour of the tray icon. It would be really nice to get the extremely useful "Play/Pause" functionality (other options may be added later) from this common action instead of duplicating the double-click action which opens/restores the main program window. Ian, could you please add this?

Hope it will be finally released. This is one of the cutest skins around.

Is anybody going to finally release this beauty?!

Love this one (esp. the both LCD versions) and use it on a daily basis, although I usually don't choose ported skins.

But here are a couple of small "con's" regarding the current versions. First, the interface logic suggests swapping locations of the left and right 3-button columns, since it's quite absurdish to open the EQ panel located at the right with a button located at the left (of course, alternatively, the EQ panel may be moved to the left).

Also, the time counter looks too small on larger monitors, which are rather widespread nowadays, so I would suggest increasing its size (and probably making the LCD font a bit bolder).

And the last small gripe: the shadow on the LCD display looks a lot better in the Chinese Sausage request, where it's slightly rounded, not straight, and doesn't somewhat decrease readability of the time counter.

Otherwise, almost perfect skin, thanks and best regards to the author(s).

[screams]

My Top 5:
1. Rated (esp. Wood, but the standard one and Carbon are fine too)
2. Vintage Radio (a lovely retro feel and very clear interface, but needs update!!!)
3. A-Round (usually I don't favor ported skins, but this one is pretty functional and nice, with a couple of small gripes, which I'll mention in the related thread)
4. Acidian Fire (a sleek, truly "xmplayish" design, but also needs update)
5. Flat II (the best among the compact ones, but also needs update)

Other 5 notable picks:
Clarity (screams for an official release, can easily make it into my Top 5)
XMP Underground Radio (the funniest concept ever? needs to be updated)
LiteA
Section (a simple and lightweight, but why no 9-band EQ in the updated version?!)
Yesterday's Newspaper (an interesting retro concept, albeit a bit raw-looking; and I'll probably end up making my own favorite artist's tribute)

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...)

Most users don't use most of the ID3v2 tags (I know I don't). And in this case, reserving space for useless fields in the library would just be a waste of space which will lead to very big library files for no reason.

Instead, I would propose some (maybe 3?) user-defined fields in the library.

Agreed. Probably it would be ideal for such a non-bloated player. And even if I like the idea of fields like "Soloist", "Conductor", etc. there's actually no reason for them nowadays, when the internet is pretty cheap/fast. You may use the disc UPC/EAN in one of these user-defined fields as a key for any additional internet search, but the "Composer" field is pretty essential for basic searching/sorting inside the library.

Hmm... Somehow I have a feel, that this breaking of compatibility wouldn't be a big issue anyway, with something like a library file. It'd kinda be a pity having to wait for a major release, while the coding itself would probably be a small(ish?) task.

I suppose, it could be a kind of state-of-art principle for Ian - to implement a brand new library with full ID3v2 support instead of such gradual step-by-step ascending.

OTOH, I'm slightly afraid of such a "monumental" change, since I've seen some supposed "clones" of xmplay using the BASS engine/modules inside of a fancy and pretty functional full-library interface. They sounded distinctly inferior to xmplay (i.e. the WASAPI output still wasn't stable and reacted to all kinds of browser or windows activity). So, the better functionality, the worse interference.

Support for DVD-Audio (for example via existing WinAmp plugin which currently doesn't see IFO/AOB files when used with xmplay) and DTS-CD (since there already was/is a native AC3 decoder, and xmplay can handle multichannel and even optionally downmix it to stereo). Am I dreaming? 

But if there actually IS option to show/hide columns in the current library version (some columns are disabled by default), maybe it's possible to start implementation of ID3v2 tags with inclusion of such a principal field as Composer which could also be disabled by default and, when enabled, it could be saved/exported as another library type (just as, say, MIDI files that may or may not be multitrack and contain tempo markers)? And there could be some hint/note for downgrading users which will help them to avoid potential problems (i.e. fatal incompatibility). Just a speculation, of course.

BTW, using the Comment tag currently may, indeed, make some sense. I'm thinking on its updating, although some of my files contain some release info in this field, so, at first I'll make a small back-up collection and will see how it works there...  

As the title says, I'm a big Classical fan, and at least 60% of music on my hard drive (not to mention my CD collection) comprise different sub-genres of Classical music. In this case, the Composer tag seems pretty essential for many searching/sorting operations, so I would be extremely pleased to have such a tag/column in the xmplay library/playlist.

Ian, could you please add it, I assume it's not that hard? 

Happy New Year to Ian and the whole community! Cheers!

Ahh, "quality" drivers nowadays... #1 reason of crashes and trouble... which 95% of user of course blame on the OS or the program.

Actually, from my experience usually it's not only a problem with drivers, and there's a very common and dangerous temptation on the developers side - to be as ignorant as possible when something happens in such "simple and obvious" domains as ASIO/Direct Sound/WASAPI APIs, predictably bashing quality of drivers in the first place and providing no investigation/support in such cases. Not a long ago I stopped using a very popular player because of such "support".

I'm happy that Ian isn't among these developers! Yes, I completely realize that my driver bundle contains 3 driver frameworks, and that Digidesign put much lesser effort into its Direct Sound driver than into ASIO and native ProTools ones (actually, it SHOULD be this way). But when I see that some program does work with these "awful" drivers like a charm while others don't, I wish to know, why, and what can be done. There're always 3 sides involved: the Mr. Gates' team, the driver developer and the program developer, so any "quick sentence" for any of these sides simply does mean the same sentence for users.

My sound driver reported that the buffer after resuming somehow had a different size than before pausing. The only thing that could help without interferring with other XMPlay functions was resetting the buffer.

You finally nailed it, Ian! THANKS A LOT!

I forgot to mention (although I'm not sure if it can be a proof of the artificial offset theory) that there's also an option in Lilith that remembers playback position for resuming after restart, and this option has an adjustable rewind sub-option, i.e. you can resume playback from a slightly earlier point.