MyPlayer Update

New: Options for „Autoplay“, „Loop“ and „Shuffle“.

 Break2 (Rev5.7, postprocessed)

Basic Example for Response-Policy-Zones with BIND

I would like to emulate a public DNS entry that does not exist yet, while i am developing the service that will use this name on an intranet server. Let a public domain name i develop the service for be When working in my intranet, i want to override whatever public DNS resolves this as to some the IP I would like to implement this using the „response-policy zones“ (RPZ) feature available in recent versions of BIND.

Weiterlesen … »

Stabilize Shaky Video With ffmpeg and vidstab


On my walking and hiking tours i often do not carry my camera but only my Android phone. Unlike the camera, the phone features no image stabilization mechanism whatsoever. In the past i have used the option offered by Google’s YouTube to apply a transformation that compensates for the most unfriendly effects of my hands being a bit shaky after some 10 or 20 miles of hiking. Since i am now moving forward to a more self-hosted approach of presenting my videos, i would like to have a similar procedure available locally.

For the ffmpeg software, which i use to convert A/V streams into internet-friendly output formats such as VP8 and Ogg Vorbis, there is a plugin „vidstab“ that is capable of doing the same thing.

In this article i describe a „two-pass“ procedure of applying „vidstab“ during a video conversion procedure, and i present some initial results i had when experimenting with the plugin’s parameters.

Weiterlesen … »

Land- und Abendstimmungen

Meckesheim, Zuzenhausen 3.10.2015
Aufgenommen auf dem Rundweg von Spechbach über Meckesheim, Zuzenhausen und Eschelbronn.

Providing XDG Runtime Directories


The intended audience for this document are application programmers and providers of init-systems for managing features of installations of the GNU/Linux operating system and POSIX-compliant operating systems in general, who are concerned with per-user temporary file management based on the XDG Base Directory Specification, [XDG].

Many applications that follow XDG guidelines and specifications expect a directory with a location specified by environment variable XDG_RUNTIME_DIR. This directory – in the following called „rundir“ – stores files that serve purposes of process communication and synchronization; it is comparable to the directory /run, but on a per-user basis, with ownership and permissions set up so that every user of a system can have such a directory, protected from access by other users.

The existence of such a directory, requirements to this directory, management of the directory’s lifecycle and its denomination by the content of a user’s XDG_RUNTIME_DIR environment variable are mandated by [XDG].

Weiterlesen … »

„nodm“: Improved „restart“ behavior

I currently maintain an experimental spin-off of the „nodm“ minimal display manager written by Mr. Enrico Zini:

As has been reported, in recent installations of „nodm“ from Debian packages up to version 0.11.1-3 (Debian unstable), the „restart“ action of the sysvinit-script does not reliably restart „nodm“.

This is due to the fact that a nodm process that has been backgrounded using start-stop-daemon –background (as the sysvinit-script does it) can not be stopped in a manner that could reliably report the shutdown status. In the case of the „restart“ action, this has the consequence that the „start“ action is attempted before the „stop“ action has finished, resulting in an error.

I have mitigated this problem by introducing a NODM_RESTART_RETRY option to /etc/default/nodm that defaults to 10 and specifies a time (in seconds) during which the nodm command will retry to start the display manager. It will retry once per second.

This is of course not a very good solution, because the amount of time that should be spent can arbitrarily differ between sites. Given certain load or runtime environments, a display manager might take more than 10 seconds to shut down.

It is my intention to extend „nodm“ by completed built-in service management facilities that make it agnostic of specific init-systems and independent from tools such as start-stop-daemon. It then could provide its own, built-in procedure for starting and stopping a specific display manager. How to accomplish this is currently subject to a vivid debate, especially in the community of Linux distributors.

In the meantime, i provide aforementioned „restart-retry“ feature as a workaround.

„jack-autostart“ ALSA Hotplug Support

jack-autostart Version 1.3 Release Notes

To handle a hotplug-removed ALSA device (such as a USB headset), i use a rule for the „udev“ hotplug daemon that invokes a new action hotplug remove $device of the jack-autostart script under the identity of every affected user. By sending SIGKILL to the jackd process, this prevents jackd CPU load from skyrocketing in such a scenario, which has been the case at least on my installation of „jackd1“ for Devuan 8 (based on Debian jessie).

The changes have been merged to the trunk and are available as sourcecode

  • via SVN: svn://
  • via GIT:

Implementation Notes

To determine if the device is affected, the controller device path in the /dev directory structure is determined when the service is started by jack-autostart start. The alsa-list-hw helper executable has been extensively modified to provide this detection.

The installation procedure generates and installs an additional rules-file for „udev“, the installation directory is /lib/udev/rules.d which can be modified using the SYSTEM_UDEV_RULESDIR variable for make:

~# make SYSTEM_UDEV_RULESDIR=/somewhere/else/rules.d install

On systems that do not utilize „udev“, this change has no operational effect, but the rules-file will be installed anyway.