Build a simple mobile music player with mpd and a Raspberry Pi B+

Turned out that my kitchen device was not satisfying. Not for the reasons suggested in comments, not because I wanted to use cheezy OS like the ones actually supported for most tablets (last time I checked, you cannot get a decent libre OS with full hardware support) for instance. But  the Raspberry Pi B+ is just not powerful enough to browse Internet of these days with such a resolution. It is just too slow.

On another hand, for years, I had issues with a declining portable music player I have plugged into the car audio system (that have RCA connectors or otherwise only specific mp3 files support). Either it got stuck on some files, or it had problems to recharge. And even working best as it could, the random mode seemed to have a few songs in favor.

So, for less than 30 €, I ordered a tactile 3,5″ screen from Quimat. It work fines with Raspbian, provided you use their specific script that you can obtain via (otherwise the screen would  remain white):

git clone

The box isn’t perfect, on one side the screen won’t be properly supported. But I do not intend to put my paws so much on it so let’s say it is acceptable for such price.

Then, to get some acceptable music player system, I went for a mpc/mpd solution, not wanting to bother with Kodi or any complicated solution that might not work or require a dedicated system other  than raspbian.

So I ended up with mpd along with awesomewm and a few wrapper scripts for mpc just build playlist or send OSD notifications.


(since the screen I improved the icon set, removed the visible cursor)

I use cava to provide a visualizer. Access to the device is made through anonymous Samba. My -utils-mpc package carries such setup mostly based on mpc-monitor (check currently played, could be used to made stats or scrobbling later), mpc+notify (run mpc command with sendnotify call),  mpc-playlist-build, mpc-playlist-next and few sample conffiles (awesome/rc.lua, smb.conf, redshift.conf + extra details in the README about input calibration, mpd.conf).

This Raspbian was purged of systemd, because I do want unexpected troubles, and of pulseaudio, because it causes mpd sometimes to stall and works perfectly without.

All files at stored in the main mpd music directory. Any file within a subdirectory will be treated as belonging to a specific playlist.

Plugging the USB energy input on the car relevant plug generates some odd noise: it has to be plugged to an energy bank. It seems to draw very little power.

Last step was to fill the 32GB USB key serving as storage for the music directory. Turns it was quite boring to hand pick such amount of files. So I used another quite crude script to fill it, taking randomly two thirds of available files for a given directory (a band name):


if [ ! -d "$PWD/$1" ]; then echo "$PWD/$1" not found && exit; fi

LIST=`find "$1" | grep -v .JPG$ | grep -v .jpg$ | grep -v .png$ | shuf`

for file in $LIST; do
 [ -d "$file" ] && continue ;

echo $COUNT
THIRD=$(($COUNT / 3))
echo a third is... $COUNT
# div by 3 and and skip this count

if [ "$2" ]; then COUNT=$2; fi

echo but... $COUNT

for file in $LIST; do
 if [ "$COUNT" -lt 0 ]; then exit ; fi
 [ -d "$file" ] && continue ;
 #echo $COUNT $file
 COUNT=$(($COUNT - 1))
 cp -v "$file" $DEST/`basename "$file"`

Quite crude indeed. mpc-monitor could be used to make stats to, in the end, remove unwanted out. But for now it should properly replace dying mp3/ogg player that you have no control over beside the power-off and play button.

Sure, maybe there are cool mp3/ogg/whatever players out there that could come for cheaper. Not really the point, I enjoy having full control over this one, even if I am not using more than 0,001% of this power. And, BTW, I intend, for another pre-electronics vehicule, to get a proper setup with music player and GPS so any experience in this regard is worth it.






The wild idea of mining cryptocurrency with your electrical car

Cryptocurrencies are as trendy as electrical cars. It should not come as a surprise that people now think about the possibility to use the car to mine cryptocurrency. It is mostly about abusing the electricity plan (for instance free plugs in Paris could do), but what is quite funny (or sad, depending) is that now, we’re getting some self-righteous anti-diesel anti-piston engine crowd considering to contribute to one of the worth energetical waste of the period. More or less in 2017 the consumption of a country like Slovakia, just burned, not producing anything but unneccessary heat, just to make a logical proof that some transactions are legit.

So, yeah, cryptocurrencies are fun in principle. Yeah, surely we should expand electrical engine territory. Still, the idea that both could be promoted by the same crowd is kind of a joke. Can you be a so-called hard core environmentalist when you burn energy just because?


Getting nginx’s wildcard-based server names to pass Exim HELO syntax checks

Many PHP-based apps, like webmails, when using SMTP functions, depends on nginx server_name value to set up the HELO sent.

But if your server_name value is wildcard-based, you’ll get “syntactically invalid argument(s)” from the SMTP server. Example with ownCloud.

Assuming that the SMTP running on the same host as your webmail is not accepting mail but from the webmail itself, you can easily work around this. You can addd


in, for example, /etc/exim4/conf.d/main/00_webmail, if your server name is something like ~^mx.


Checking mails/addressbook/calendars with IMAPS (Dovecot) + DAV (ownCloud)

As a followup to my article Replicating IMAPs (dovecot) mails folders and sharing (through ownCloud) contacts (kmail, roundcube, etc),  I’d like to point out that, these days, I almost completely dropped Kmail (only use it on a laptop, mostly because I do not use the laptop frequently enough to bother) and switched to Thunderbird.

Using Thunderbird enables me to use cool Firefox modules like S3.Google Translator (note that Kmail also has a similar functionality) and works decently with modules Lightning and Inverse Sogo Connector for proper CardDav and CalDav handling. I went away from Kmail due to still existing akonadi issues after so many years and the fact I was still forced to run ‘qdbus org.kde.kded /modules/networkstatus setNetworkStatus ntrack 4’ after suspend for it to notice network is on. In general, I do not think KDE people are going in a direction that makes sense for me and Kmail was almost the last piece of KDE I was still using (since they more or less killed Konqueror themselves). I still enjoy Dolphin though, especially for the group results and filter bar.

Regarding Roundcube, CardDav is nicely handled by RCMCardDav even though it requires a bit a work to properly deal with dependencies.

Sharing Firefox bookmarks through your Next/ownCloud/whatever ?

Recent changes in Firefox makes bookmark and password cloud apps a pain to set up, with obligatory fiddling in about:config and removed config on upgrade or else.

An alternative would be to use Firefox Sync. But I am not using only Firefox and I do not like the notion of using a solution tied to one browser. Plus, installing Firefox Sync on your own software is, last time I checked, neither properly documented or made to use existing cloud authentication.

Password-wise, I switched over KeePassXC. I am not documenting my setup now because it still experimental and I know password managers are subject to hostile hacks. So I’d would not encourage people to use an half-baked setup.

Bookmark-wise, I tried a few things. You can fiddle around places.sqlite but it changes so much that any sync of this file on a cloud is bound to generate lot of useless trafic in best scenario, conflicts otherwise.

However, Firefox save automatically backups of bookmarks in .json (simingly compressed with lz4, though package liblz4-tool in Devuan/Debian is not helpful is decompressing them) in .mozilla/firefox/random.default/bookmarkbackups/  and this directory can easily be synced.

Then, on another client, when you open the bookmarks window, you are presented with the option to load such backups, telling how many entries are within each backup. The process is half automated  – far from perfect but much less broken than anything I tried so far.

I am sure it could be possible to improve this to a fully automated solution (adding new entries is easy to handle, noticing removal a bit less, it would require some database).  I’d be interested in any alternative.

Isn’t SRS breaking SPF itself, at least regarding spam?

Earlier on this blog, I proposed ways to implement SPF (Sender Policy Framework). I recently noticed mails forwarded by one of my servers being tagged as spam by due to SPF checks. It means that while SPF works for my domains with near to 0 user base, no real business of forwarding, it is a nuisance for forwarding in general. So you are advised to use SRS (Sender Rewriting Scheme). Strangely enough it is not fully integrated on main servers and some implementation (Exim in Debian) are based on unmaintained library (SRS C library).


Fact is SRS is far from being nice. It makes so your own forwarding server is vouching for fowarded mails. But why would you want that?

SPF test will fail because your forwarding server is not a registered valid source for (forwarded) mails sent from domain X. SRS proposal is that your server will alter header so to forward the mail from X domain X to appear as sent from an address of your own domain for you server is a registered valid source.

I guess the logic is to make forwarders somehow responsible of filtering, not bad in principle.

But it also means that for each spam forwarders fail to identify, they’ll be tagged as spam originator. It is particulary annoying when forwarding is made on public addresses bound to attract spam. So it seems better to get a failed SPF test on every forwarded messages including valid ones than a valid SPF test on every forwarded messages including spam.

SPF without SRS breaks forwarding. But SPF with SRS, the workaround, breaks SPF itself regarding spam and will give you (your IPs, your domains) bad rep, with will make your legit mail at risk of being blacklisted, unless you apply an overly harsh policy on forwarded mails.

Annoying. I am thinking removing SPF completely, instead.  For now, I am updating my SPF records to remove any Fail statement, since there is no way for me to know whether one of my mail can legitimately be forwarded through several servers.  Funny enough, google that promotes SPF usage recommends using SoftFail over Fail. But I might even reset to Neutral.

Interesting link on topic : Mail server setup wih SRS ; Why not SPF?

Alternative: I implemented DKIM on my servers. Seems much smarter to have a server signature.

Cloning installed packages list over LXC containers with apt-clone

apt-clone is quite convenient to run LXC containers with the same set of installed packages.

here’s a short bash function to do run apt-clone on a list of containers to synchronize them all:

function lxc-clone {
    MKTEMP=`mktemp --dry-run` 
    guests=($(lxc-ls --active))

    # first get clones for each
    for guest in "${guests[@]}"; do
	echo -e "[${shell_datecolor}$(date +%H:%M:%S)${shell_clear} ${shell_containercolor}$guest:${shell_clear} ${shell_promptcolor}#${shell_clear} ${shell_invert}apt-clone clone $@${shell_clear}]"
	lxc-attach -n "$guest" -- apt-clone clone "$MKTEMP.$guest"
	cp -v `lxc-config lxc.lxcpath`/"$guest"/rootfs"$MKTEMP.$guest".apt-clone.tar.gz "$MKTEMP.$guest".apt-clone.tar.gz

    # then do a restore of all in each
    for guest in "${guests[@]}"; do
	echo -e "[${shell_datecolor}$(date +%H:%M:%S)${shell_clear} ${shell_containercolor}$guest:${shell_clear} ${shell_promptcolor}#${shell_clear} ${shell_invert}apt-clone restore $@${shell_clear}]"
	for guestwithin in "${guests[@]}"; do
	    echo "=> ...$guestwithin"
	    cp -v "$MKTEMP.$guestwithin".apt-clone.tar.gz `lxc-config lxc.lxcpath`/"$guest"/rootfs"$MKTEMP.$guestwithin".apt-clone.tar.gz	    
	    lxc-attach -n "$guest" -- apt-clone restore "$MKTEMP.$guestwithin".apt-clone.tar.gz
	    rm -fv `lxc-config lxc.lxcpath`/"$guest"/rootfs"$MKTEMP.$guestwithin".apt-clone.tar.gz

    rm -f "$MKTEMP".*.apt-clone.tar.gz

The variable $guest sets which LXC containers to work on. Here, it works on all active containers.

(the color variables are set in but arent required)