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.")
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.
[0] - https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=cmus;dist=...
Error: selecting output plugin '': no such plugin
'cmus --plugins' lists a single plugin: ao.
~/.cmus/rc
file and add set output_plugin=ao
that should get it working on OSX.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.
vlc -I ncursesI do have one very minor suggestion though; you might want to change your README.md:
> namp is a command line MP3 player for Linux
Technically it's a terminal player rather than command line.Carbon components warning is because cmus currently uses libao for the sound output on OS X by default. If somebody will contribute a native OS X output plugin, it will be gone.
My only wish is that it was a bit more "vi-y". I'm sure someone has a way, though ;).
I wrote down how I use moc[1]. Hope someone might like it. Also I tried to make navigation feel like vim sometime back. The keymap[2] might have a few tips.
[1] https://chanux.wordpress.com/2013/04/25/the-thinnest-music-i...
[2] https://github.com/chanux/dotfiles/blob/master/moc/keymap
I construct the playlists myself by using soft-links to the actual paths of the songs. Real files are placed in sensibly named directories.
It's a matter of taste of course. Still I really appreciate that people write this kind of software for the terminal!
It would be sick if this could play videos via libcaca too..
For libcaca, see mpv's or mplayer's "-vo caca" flag.
(Remember, kids, you're sending a clear signal about what's valuable with your purchases. And if you're using spotify, it isn't the artists whose music you're listening to.)