irmp3 and irmp3-curses: All for naught

There’s a little clock in my head that starts ticking when I have been spending too much time trying to get a program to work. And that little clock was ticking furiously by the time I got this screenshot.

That’s irmp3-ncurses, a text-based front-end to the irmp3 audio jukebox. And believe it or not, after more than an hour of scraping around in two different distros, that’s the best I could come up with.

I am ashamed. My geek credentials are in jeopardy. 😦

As I understand it, irmp3 is primarily aimed at environments that need infra-red support or LCD output, so … car stereos, custom-built home mp3 players, and so forth. And if you skim through a few of these examples, it’s quite impressive to see what you can do with it.

Unfortunately what I did with it … was almost zero. I could build both the daemon and the command-line control interface in Arch. I even managed to generate a configuration file with the built-in utility, but the daemon never seemed to find my music path, which meant the command-line interface couldn’t tell it to start playing, and irmp3-ncurses couldn’t help anyone out. Not even with alsa-oss on the team. 😦

So I switched to Mint, because the previous verision of irmp3* is in the Lucid (and Debian Squeeze) repositories. If the issue was a faulty setup in Arch, perhaps the Debian/Ubuntu versions carried enough default settings to get things rocking. But as luck would have it, the Mint/Ubuntu version was no more successful. Oh well, I tried.

There are a few considerations, of course: The last version was released way back in 2007. I don’t have either LCD or IR hardware. And I have a long-standing reputation for butchering application conf files. Any one — or all — of those could be the problem.

If you know how to get this one working, or if you have tips on how to make it sing pretty, or if you converted your 1949 Citroën 2CV into an mp3 player with irmp3, please help us out. Science demands an answer. 😉

pure-ftpd: Adventures in the service sector

My experiences with managing ftp servers is exceedingly thin.

All the same, I do enjoy boasting about a bare-bones server I set up about eight years ago, using a busted-up 300Mhz laptop without a hard drive, a Xubuntu 6.10 live CD, a USB key and vsftpd. And with that sparse recipe, managed to transfer some files from my brother, who lived in another part of the world.

(And yes, that’s how far *Ubuntu has fallen, given that it could run live on a machine with only 256Mb of memory and still have a sliver of space left over for file transfers. I’m afraid to see how heavy it has become. 😯 )

Point being, I’m usually on the other end of the ftp adventure. I’m more experienced with clients than servers. lftp, ncftp, cmdftp, even plain ol’ ftp if need be.

Servers just never enter my sphere. All the same, here’s pure-ftpd, in the best way I can show that it works.

 

That’s the Debian version of the server running off a Linux Mint live CD, with my Arch machine accessing it through the network. I didn’t actually go through the entire setup, because it’s gone as soon as I turn off the Mint system, and I haven’t really anything to transfer … except maybe that screenshot. 🙄

I can’t tell you what’s the best server system, and I’m not experienced enough to know what to look for anyway, so if you have a particular one you like, I suggest you stick with it.

On the other hand, if you have a leftover 300Mhz laptop with no hard drive and a dusty Xubuntu 6.10 live CD, and maybe a USB drive to stash files on … well, why not give pure-ftpd a go?

Worse comes to worst, I can tell you firsthand that vsftpd will work, even if pure-ftpd doesn’t. 😀

gpm: And you thought you were mouseless

No, living at the terminal does not mean you are rodentless (and I don’t mean gopher). In fact, there is very strong mouse support for you, and your text-only lifestyle.

If you actually sat through that whole gif, I applaud you. If you could make out what was happening, then doubly so.

Basically, gpm is a mouse daemon for consoles. Perhaps you know about it; it’s no big secret. Not like gnuit was. 😕

You’ve got both left- and right-button functions, middle button and/or mousewheel — depending of course on the application. Highlighting is (mostly) done by holding down the shift key. You can see most of the practical use there, with elinks.

But I’m guessing you know most of the basics of a mouse. 🙄

The home page suggests it’s wired for the console and for xterm, but I don’t use xterm so I’m not sure what the special benefit there is.

And take a look at the man page if you get a chance. It strikes me as odd that the default behavior for a triple-click is a system shutdown. 😯

Aside from elinks, vim I think, Midnight Commander and maybe a few others, I’m not sure how much practical gpm support is out there. If you know of something, please share.

P.S., depending on your system, you might have to manually start the gpm daemon. In Debian I think that’s taken care of for you, when you install gpm. In Arch, you’ll need sudo systemctl start gpm. Enjoy.

btpd: Strictly a daemon

I knew the B section would have a lot of bittorrent software in it. I didn’t know so many of them would fall by the wayside as abandoned or unbuildable.

Regardless, here’s one that’s strictly business: btpd.

And as you might have guessed by its name, this is strictly a daemon. Sort of.

See, btpd alone comes with btcli, which is sort of like a taskmaster for the daemon.

You set some options through the daemon, like I did above by choking my bandwidth to 30Kbps down and 10Kbps up.

But btcli is how you add, start, stop, list or check the status of torrents that are running.

And you can set the btcli stat command to refresh after x seconds, and you get a rolling update of whatever btpd is up to.

No, it’s not really an interface. It just spits out data. But I guess we’ve seen lots of applications like that in the past … remember dstat and ethstats? Not much different in that way.

On the plus side, btpd is extremely light, taking up only the tiniest sliver of memory and CPU on this machine, which isn’t saying much but I thought worth note.

Some low-end machines lose out on interfaces and fancy menus. If that’s you, btpd might be what you need.

P.S., it looks like there are projects for web-based and GTK+ interfaces to btpd too. No guarantees on those. …

draai: A wrapper for a client for a daemon

I might have drifted beyond my limit on this one. This is draai:

draai is, as the home page explains, a wrapper for mpc. For those of you keeping score at home, that makes draai a wrapper for a client for a daemon.

I have already embarrassed myself by talking down about mpc and mpd; I figure I can’t do much more damage by bringing draai into the mix.

On the one hand, draai does simplify things a bit. draai understands most of what I think are underlying mpc commands (like draai play and draai stop). But it also adds a few nifty flairs. For example, draai can send status information into the system logs, if I understand correctly.

It’ll also show you a burst of future tracks, and information for each one. You can also set draai to start or stop itself at a particular time, meaning it could be a kind of console radio clock.

There are a few other perks in using draai over vanilla mpc, but I will let you explore. The README file explains most of them.

One caveat: As best i could tell, there was no way to run draai outside of a zsh shell. Whether or not zsh is in your repertoire is your problem to solve; it may be worth it to run zsh just to get at draai.

But again, that’s your decision to make. Traai it and decide. 😆

moosic: Simpler style, similar results

mpd doesn’t corner the market on music daemons. And mpc isn’t the only client that can do the job either.

Here’s moosic, a slightly simpler frontend for a similar approach to music playback.

Almost identical, except perhaps with the difference in ease of setup: moosic has almost none.

No, really. I didn’t even start the daemon. moosic did it for me. I gave it the add command, then play, and off it went, happy as a clam.

moosic probably has fewer commands than mpc, but of course I say that knowing very little about how to use mpc efficiently.

On the whole, I’d have to call moosic a simplification of mpc, but with the same overall result.

Next time I need something like mpd, but without the (harumph) hassle of setting it up, I’ll come looking for moosic.

P.S.: Python alert again: If you need exceedingly light software, this one might be sluggish for you.

Bonus: The sounds of silence

My original plan was to skim through each and every audio program I had on file, check to see if it actually worked, and if not, list it here, on this page, as a potential null set.

I’m going to deviate slightly, only because I already have a fairly strong idea who’s playing on the team, and who has drifted off into infinity.

I have two categories to list here though: One is “dead-and-or-dying,” and the other is “K.Mandla-is-too-dense-to-figure-this-out.” I try to be fair, and not blame my failings on someone else. 🙄

Group one:

• benmp3 and ginetob, as I more or less already knew, end up in this category. Both lack source files, to the best of my searching.
• I don’t have much to say about yauap, except that it spat out errors when I compiled it in Arch, so I transplanted a version from Debian Squeeze. That behaved itself, but refused to play either ogg files or mp3s. That may be an issue with gstreamer-(whatever), or just a problem with my surgical skills.
• Musicus and its frontend Cjukebox may just be so far out of date that they require heavy code repair. I managed to circumvent one small compile error by adjusting one source file, but after a second one appeared, my bag of tricks was empty.
• jinamp, which I think was intended as a successor to benmp3, will compile for me in Arch, but doesn’t seem to play anything. There’s no interface either, it seems, so running the program is a bit … uneventful.
• I mentioned ncxmms2, but not ncxmms because I couldn’t find a source file for it. Not even the grand archives of Debian could give me a lonely tarball. No source, no party. … 😐
• Similar problems for cxfe. Won’t build with the AUR package. Debian and Ubuntu are oblivious to this. And the link on the home page to .deb files is dead.
• pytone has been around a while, but I’ve never seen it run. It must have worked for someone at some time in the past though. My Arch system scowled at me when I tried to build it, and a transplanted “binary” from Debian spat out errors too. But in a Linux Mint live environment, pytone gave errors on installation, which I’ve never seen before, and even a transplanted Debian version refused to work. So pytone becomes the great mystery of the decade.

The next ones are either too obscure for me to set up, or I just lack the requisite wherewithal to do right by them.

• I’m not ashamed to admit that m9u seemed so convoluted and so meagerly documented that I couldn’t even figure on where to start. If you find something, let me know.
• epris, on the other hand, seemed fairly straightforward for a text-only background music “daemon,” but I’ll be darned if I could get it configured and working. Is it a system service? Should I start it with systemctl? Hmm. 😕
• Similarly, but to a lesser extent, Mylene escapes me. I can compile the software and I see that there have been updates even within the past months, but I don’t hear any sound. Which usually means I’ve done something wrong.
• pimpd and pimpd2 are both mentioned as command-line players for mpd, but neither would build in Arch because of the knot of perl dependencies, and Debian didn’t seem to know about them. I know I probably ought to provide due diligence and get them installed, but … but … those dependencies. … 😯
• mpdc probably works, but by this point my configuration for mpd was probably so mangled that it couldn’t handle the stress. Mangled or not, all I got from it were python errors. It does look useful if you prefer mpd and want some flexibility. Extra points if you can tell me why the Arch version needs GTK3. 👿
• vimus probably works too, but this time there were some issues installing stuff through Cabal, and I don’t know enough about Haskell to figure out what the errors were. Or how to get around them.
• I had great hopes for mplay, but after building a lot of obscure perl packages and taking its sweet time assembling, it eventually just gave me error messages. So disappointing. …
• bplay and brec (and I suppose vplay and vrec too) may be too intricate for me to figure out. In most cases, there seemed to be issues with device addresses. Those are my weak point. 🙄

Again, it may be that those last ones all work, but I am too much of a dunderhead to figure them out. (I might also note that they all seem to work on a daemon-client model, like mpd and its ilk. I think.)

If you get any or all of those working, or your distro has manageable copies, please tell. Science demands it.

ncxmms2: Similar style, different daemon

Eliminate the graphical interface, keep a daemon for playback, add a text-based control panel and what do you have? ncxmms2.

I’ve not used the xmms2 application much in my time with Linux. No particular reason; it just never really grabbed me.

I do find ncxmms2 easier to work with than, for example, mpd and its plethora of hangers-on. Maybe I’m just luckier with xmms2.

Regardless, it never really appealed to me, so I never really followed it. I wandered off with beep media player and Audacious, in the years that followed xmms‘s slow gliding halt.

ncxmms2 is a fairly reasonable interface to the xmms2d daemon. You can see both running there, in the screenshot.

Controls are a little odd, though. Press the number 1 for the help screen, and that will get you started.

Other than that I can’t find much about ncxmms2 to complain about. If you prefer a daemon without the (harumph) hassle of setting up mpd et alia, this might be the ticket for you.

On the other hand, I can promise at least a few more audio players with their own way of doing things. Stay tuned. 😉

bitflu: A tiny torrent daemon

I like rtorrent for the console, followed in quick succession by aria2. The former I use almost exclusively as my torrent client of choice, and it has been that way literally for years.

In the grand scale of things, I will admit that rtorrent doesn’t have a lot of the “features” that some other torrent clients have.

I am willing to forgive most of those things, primarily because rtorrent’s memory footprint and CPU drag are infinitesmal when compared to those other programs.

On the other hand, it would be nice to have a web interface, or telnet access, or a daemonlike structure without dragging in third-party patches and whatnot.

Enter bitflu, which is designed more in that angle.

 

Written in perl and with obvious designs on expansion (think: plugins!), bitflu does just about everything you might expect from any standard torrent download tool.

But does it with most everything happening silently, in the background, and out of the way.

You can figure out how to work it probably just from the screenshots there. The daemon itself will watch its .workdir/autoload directory and load anything torrent-ish dropped in there.

You can also access it via telnet and force-feed it through its console interface.

And — hold your breath — it also has a web GUI, accessible through a modern graphical browser, without dragging in miles of Xorg dependencies. 😯

Nicely done, bitflu. A gold smilie for your feature-rich but dependency-lean design: 😀