Cue files and .cur files

There have been some recent reports of problems with .cur files showing up in music libraries, but turning out to be unplayable. These files are related to the presence of (usually unwanted) .cue files or cue sheets embedded in flac files, so the solution is simple: get rid of the cue files or embedded cue sheets. The .cur files disappear.

But I haven't found any discussion of exactly what these .cur files are, and that's what I would like to address. I do not have any knowledge of the code involved, so all I have to to say is speculation, but I have tried to base it on logic and observation.

Background: originally LMS supported cue files that pointed to a single audio file, defining a sequence of tracks contained within the file, such as a rip of an entire CD or a side of an LP. A few years ago some changes were made so that now LMS can use cue sheets that point to multiple files, so each of the tracks can be a separate file. These changes seem to be when .cur file problems began occurring.

Why would you want a cue sheet pointing to multiple files? If every track on an album is already a separate file, why not just play those files? There could be some valid reasons: having one file for each side of an LP could be one reason. But another reason, maybe not so valid, is because you want to use certain features in ways that were never intended. And that is the reason for my interest in this issue: I want to use the same individual track files in two or more albums, so I want to be able to address the same files from multiple cue sheets.

Again, why? One reason is to be able to break individual albums out of comprehensive compilations, like Mosaic box sets. Another reason has to do with classical albums that contain several works, each with multiple movements on different tracks. It may be desirable to have easy access to the entire album, and to each of the complete works included.

(Note: it has been pointed out in another thread on the subject that it would be much more sensible to just copy the files to a different folder. That's very true, but not relevant to this post. Remember, this part is just background!)

One complication with this is that files that are addressed by a cue sheet are not supposed to be visible in the LMS database, for obvious reasons. They are visible if you browse the music folder, but they cannot be played. Oddly enough, they can be added to favorites, though.

In my scenario of a box set and separate albums contained within it (not necessarily in the same sequence), it is necessary for both the box set and the original albums to be defined by .cue files. It also seems to help if the actual flac files are not directly scanned by LMS, so I put them in a separate folder with a sentinel file to tell the scanner to skip the folder. I put symbolic links to those files in the folder with the cue sheet, which points to the symlinks.

That's all background to explain what I think is happening with .cur files. It appears to me that they are database entries created by LMS when it encounters discrepancies between a cue sheet and the tags it finds in the flac files the cue sheet points to. For instance, if the album name or track number is different, it stores a virtual .cur file with the attributes of the flac file. The .cur file cannot be played, but it can be added to the current playlist and LMS will throw an error when it attempts to play the file.

If my speculation is wildly off base, I hope someone (by which I mainly mean Michael, but there are others who may know, as well) will correct me. But if this is close to what actually happens my question is this:

Is it really necessary for LMS to display the .cur files and allow them to be loaded into the play queue? I assume they do serve a purpose, internally, but couldn't they be hidden? Are there any occasions when it is desirable for the user to see them in the database?


Here's an error report of a recent attempt to play a .cur file (I have shortened the path to the file for readability, but it is otherwise unedited):