I've been using cmus for a few months now. After trying countless music players on Linux and feeling frustrated that none of them ever felt right, cmus was the first one I thought I could get used to. In fact, I think it's the first project where I'd rather contribute new things than try to find a new project where more things feel right. So if I ever find the effort, I'll see about digging through the code and adding a couple things.
I noticed that after adding a folder to the library, it simply adds all the filepaths in that folder to lib.pl. It doesn't cache any of the metadata. This means that it has to rescan everytime. I'm wondering what thoughts went into that design decision. On the one hand, it's very easy to manage, since it's just a list of files. On the other hand, for large collections, startup time can be considerable. I have 109GiB of music, but with a top of the line SSD, it only took ten or fifteen seconds to scan the whole thing, which isn't bad.
On a similar note, it appears that because it adds all the files to the lib.pl file, and not the top level directory I added, it doesn't have any support for noticing when new files are added to my ~/music folder. This means I have to re-add ~/music when I add files to it. I guess that's not too bad. And I assume it won't add duplicates or anything if I re-add the root level directory. But what about when I remove items? Will it be smart enough to detect that they're not there? (An algorithm like: "I just traversed a directory for which there is an existing file entry in lib.pl, but during this traversal I didn't see it. I should therefore remove it.")
Cmus does cache all the metadata — in the file named, unsurprisingly, «cache». You can restart cmus, and notice that the startup will be instant (even on an HDD with 100+GiB of music).
Re-adding the ~/music should work fine. There is also an `:update-cache` command which will update the metadata for all (changed) files, and remove the missing ones.
Another thanks here. I'm between cmus and mocp at the moment due to the segfaulting bug on Debian[0] but might try to compile the latest version from source if these have been squashed upstream...
Please give the latest version a try. I am not aware of any segfaults that have not been fixed upstream. Debian packages a really ancient version of cmus for some reason.
Thanks for the encouragement. Had a bit of fun getting it to build correctly[0], but got there in the end! Would love to create a new Deb package but haven't done it before, am short on time etc. - maybe another day.
For future reference: Always start with `apt-get build-dep packagename` Whenever you are trying to build a newer version of some software that debian also packages. There is no reason to start from zero and have to discover this information for yourself one build error at a time. If you want to see what the `build-dep` list is without actually running `build-dep` try `apt-cache showsrc packagename`
Would be neat if you could also include streaming services like Pandora. I use Pianobar https://github.com/PromyLOPh/pianobar for Pandora would be nice to have some streaming tie ins. A one stop music resource so to speak. A book mark system to listening to Internet radio like cmdradio https://cmdradio.codeplex.com?
Thank you! I struggled with that for so long, and ended up installing via brew after giving up on a source build. Weird that even that process didn't set up the rc file properly.
One thing I would love to see is a folder-based music view like you have artist/album views.
I don't tag my songs, I just organise them in folders about three levels deep. What I'd like to see is a folder tree of my music folder on the left and all the files in that folder, plus all subfolders recursively, on the right. The only player I remember getting this right was amarok (now clementine). I've never once in my life ever wanted my songs listed by album or artist. I have my file manager to organise my files and they're already organised. It's really silly to ask me to organise them again in a different way that doesn't really fit my organisational style.
Moc does that. If like me you're not a music player guy you can use mplayer in slave mode, reading from a playlist created with `find | sort`. I made a script to do that and some other stuff. https://gist.github.com/afarah1/e8cbafaf1d9d8029c6ca
Ditto - automatic organisation by metadata might be nice if metadata wasn't universally inconsistent and incomplete. I tried manually fixing my whole library and it was nice for a couple of weeks, but there's so much ongoing maintainence overhead that OS-level folders are the only thing I bother with any more :(
one possibility might be to let beets handle all the music organization while cmus just leverages that to provide different views on that data using beets.
The metadata doesn't even reflect the way I think about music. And what do you do with movie OSTs, which are by ten different artists and some are songs from other albums? It's just madness.
I use beets for tagging, and it has no trouble with OSTs. It sets a different tag for Album artist and Track artist, and cmus uses the Album artist. Most soundtracks of the type you mention are under <Various Artists>.
I'm different from most people in that nearly all of my music collection is complete albums, so if that's not the case, then I could see how a file/folder layout would work better, and the artist/album view is more full-featured than the file-browser view.
[edit]
Also as far as I can tell, there's no way to filter based off of path (only filename) which might also be a good way if you prefer directory based organization.
I tag my music through MusicBrainz (https://musicbrainz.org/) and I generally don't have to worry about metadata anymore. I generally try to correct anything I find that's wrong. abcde + picard + ncmpcpp.