Category Archives: linux

linux vdr

VDR aktualisieren auf Debian Wheezy und VDR 2.0.0

Alle Jahre wieder bringe ich meinen VDR auf einen aktuellen Stand. Nicht nur die VDR Pakete, sondern auch das drunter liegende Debian Linux. Heute war es wieder soweit, das alter Debian 6 Squeeze hat ausgedient und wurde aktualisiert auf Debian 7 Wheezy.

Im Grunde habe ich mich an die sehr gute Anleitung von Patrick Schoyswohl gehalten und kam sehr zügig und unproblematisch durch. Natürlich musste ich die sources.list um die nötigen VDR Einträge von e-Tobi und OPPs erweitern, desweiteren haben ich am Ende noch etwas aufgeräumt um alte Pakete und Kernel von der SSD zu haben.

Aktualisierung

Aber hier meine einzelnen Schritte:
Zunächst habe ich das Debian Squeeze auf den letzten Stand gebraucht mit den drei Befehlen

apt-get update
apt-get upgrade
apt-get dist-upgrade

Jetzt muss die /etc/apt/sources.list für das Upgrade auf Wheezy angepasst werden. Meine sources.list sieht wie folgt aus:

deb http://http.debian.net/debian wheezy main contrib non-free
deb-src http://http.debian.net/debian wheezy main contrib non-free
deb http://http.debian.net/debian wheezy-updates main contrib non-free
deb-src http://http.debian.net/debian wheezy-updates main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

deb http://www.deb-multimedia.org wheezy main non-free
deb http://ftp.debian.org/debian/ wheezy-backports main

deb http://e-tobi.net/vdr-experimental wheezy vdr-multipatch base addons
deb-src http://e-tobi.net/vdr-experimental wheezy vdr-multipatch base addons

deb http://debian.oppserver.net/vdr/ wheezy main non-free contrib
deb-src http://debian.oppserver.net/vdr/ wheezy main non-free contrib

Jetzt wird die Aktualisierung der Paketlisten vorgenommen mittels apt-get update, sowie ein kleines Systemupgrade, mittels apt-get upgrade. Dieser Schritt kann durchaus etwas länger dauern, schließlich werden hier zahlreiche Pakete runtergeladen und installiert.
Nachdem das erledigt ist, wird noch nicht neugestartet, sondern zunächst ein aktueller Kernel zum Booten eingerichtet. Zunächst gilt es aber rauszubekommen welche Kernel Versionen überhaupt zur Verfügung stehen. Dazu wird der Befehl dpkg -l | grep linux-image ausgeführt, der als Ausgabe uns alle installierten Kernel Versionen anzeigt. Wir wechseln jetzt mittels apt-get install linux-image-3.2-XXX (486 oder amd64) auf den jeweils aktuellsten Kernel mit dem passenden Befehlssatz für unsere CPU. Um Probleme zu vermeiden sollte unmittelbar nach dem Kernel Upgrade die neue udev Version installiert werden, dazu führen wir den Befehl apt-get install udev aus.
Nachdem alles bisher gut funktioniert hat, gilt es nun den Rest des Systems auf Wheezy zu aktualisieren, der Befehl apt-get dist-upgrade führt ein Upgrade der Distribution durch. Wenn alles soweit sauber durchgelaufen ist, kann das System mittels reboot durchgestartet werden.

Nach dem der VDR durch gebootet ist, sollte wieder Fernsehempfang möglich sein. Sollte es nicht funktionieren müssen die üblichen Logdateien auf Fehler überprüft werden (ich hatte direkt Bild).
Mittels cat /etc/debian_version kann nun die Version von Debian überprüft werden (7.x = Wheezy / 6.x = Squeeze). Die Version des VDR und der Addons/Plugins kann mittels dpkg -l | grep vdr überprüft werden.

Aufräumen

Kommen wir zum Aufräumen der nun vorhandenen Überreste von Squeeze.

Zunächst beseitigen wir alte noch installierte Kernel. Dazu müssen wir uns eine Übersicht über alle Kernel anzeigen lassen mittels: dpkg -l | grep ^i | grep linux-[hi]. Jetzt gilt es jeden unnützen Kernel für sich zu entfernen, per Befehl: apt-get purge linux-image-*VERSIONSNR*.
Im zweiten Anlauf löschen wir alte Pakete mit dem Befehl: apt-get autoclean. Dabei werden nicht mehr benötigte Pakete von der Platte gelöscht.
Damit sollte wieder einiges mehr an freien Speicherplatz auf der SSD zur Verfügung stehen.

dies & das hardware linux windows

Thin Client Management

In den letzten Jahren ist die Anzahl der Firmen, die Terminalserver oder XenApp im Betrieb einsetzen gestiegen. Dieses Konzept bieten zahlreiche Vorteile, aber auch ein paar Nachteile und ist nicht immer bei jeder Firma und jedem Arbeitsplatz umsetzbar.
Fragt man den Systemadministrator oder die Geschäftsführung nach den Gründen für den Einsatz dieser Technologie, kommt früher oder später der Vorteil in der Wartung als einer der Pluspunkte.
Das Konzept wurde aber bei allen meinen Neukunden immer nur Halbherzig umgesetzt. Während man bei den Terminalservern von einer erleichterten und verringerten Administration ausging, krachte spätestens beim Einsatz von Thin Clients dieses Argument zusammen. Die Thin Clients sind ausgesucht worden, nach dem Schema, wir haben die Server und Monitore vom Hersteller XY, also nehmen wir auch die Thin Clients vom gleichen Hersteller. Befragt nach zentralem Management, kam bei Kunden mit kleiner Anzahl von Thin Clients die Ausrede, bei unseren 5 Geräten lohnt es nicht, da war ich zu Fuß schneller oder zentrales Management sei nicht bekannt gewesen. Bei größeren Umgebungen kommt dann oft die Ausrede, wir haben mit 3-5 Thin Clients angefangen und die anderen sind im laufe der Zeit dazu gekommen, deswegen haben wir es immer manuell gemacht, aber wir hatten auch mal drüber nachgedacht mit zentralem Management die Geräte zu verwalten. Erst in den richtig großen Unternehmen setzen die Kunden auf zentrales Management und suchen auch schon mal die Thin Clients danach aus.

Was ist jetzt mit den „kleinen und mittleren“ Umgebungen, wieso waren sie scheinbar ohne ausgekommen und ich sehe es anders?

Nun das Wort, scheinbar, trifft es direkt auf den Punkt. Oft waren in den Umgebungen Fehler an Thin Clients vorhanden, die mit ist halt so abgestempelt wurden. Das Betriebssystem und BIOS/EFI wurden nicht aktualisiert, weil man davon ausgegangen ist bei Thin Clients wäre es nicht möglich/nötig. Spätestens beim Wechsel des Servers oder der IP musste erneut zur allen Thin Clients gerannt werden und diese manuell umgestellt werden. Den Hammer schoss ein Kunde ab, der seine Thin Clients aus ganz Deutschland einsenden ließ um das Windows CE zu aktualisieren und neuen Servernamen zu hinterlegen.

Ab wann lohnt es sich also auf vernünftige Thin Client mit zentralem Management zu setzen?

Meine Antwort auf diese Frage ist sehr simpel, ab dem ersten Thin Client. Der Mehraufwand liegt nur in der Installation und Einarbeitung in die Software. Die Einrichtung ist auch beim Thin Client nötig, also entfällt diese als Mehraufwand. Der Mehrwert überwiegt, ob es das flashen eines aktuellen BIOS/EFI oder Betriebssystem ist, das Wechseln der IP-Adresse oder des Namen des Servers ist oder einfach andere Anpassungen an der Konfiguration. Alle diese Änderungen können zentral erledigt werden und manchmal Zeitlich beeinflusst werden (je nach Management Software). Als kleines Beispiel, durch einen Fehler im System muss ein neues System geflasht werden, also kann ich bestimmen nach dem Abmelden soll der Flash-Vorgang gestartet werden oder die Geräte sollen Nachts alle gestartet werden und dann geflasht werden um danach wieder abgeschaltet zu werden. Schon haben ich einen großen Mehrwert, der auch bei 1-2 Geräten vorhanden ist.
Im übrigen haben ich es noch nie erlebt, dass der Wechsel nach erfolgreicher Etablierung von 1-2 Geräten stoppt, sondern er wird fortgesetzt und dann ist man zu Faul noch ein Management in Betrieb zu nehmen!

linux windows

HowTo: EXIF Zeiten anpassen

Wenn man mehrere Digitalkameras im Haushalt hat oder gern mit Familie und Freunden mit mehreren DigiCams unterwegs ist, ist einem das Problem nicht unbekannt. Jede Kamera hat eine andere Zeit eingestellt und wenn alle Bilder zusammen geschmissen werden entsteht ein riesiges Chaos.

Einer solchen entsprechenden Aufgabe musste ich mich nun nach den Feiertagen zum Jahresende auch stellen. Zwei Digicams mit Deutscher Sommerzeit und eine Digicam mit Griechischer Winterzeit. Als kleiner Hinweis vor dem Beginn der Aufgabe sollte man sich mit ein paar keinen Tricks das Leben leichter machen.

Als letztes Foto sollte man eine DCF Uhr (optimal mit Sekunden), im Volksmund auch als Atomuhr bezeichnet, mit allen Kameras fotografieren. Das ist der Bezugspunkt, an dem wir uns richten werden. Übrigens Sekunden deswegen, weil in Windows zwar als Aufnahmezeit immer nur ein Datum TT.MM.JJJJ und eine Uhrzeit SS.MM angezeigt wird, aber die EXIF-Daten des Foto enthalten auch Sekunden. Falls Sie im Haushalt keine solche Uhr besitzen, im Internet kann Ihnen z.B. diese Seite aushelfen.

Jetzt da auf allen Kameras mit der Aufnahme der Uhr die Korrektur vorgenommen werden kann, gilt es die Fotos aus den Digitalkameras auf die Festplatte des Rechners zu bringen. Hier macht es am meisten Sinn die Aufnahmen der einzelnen Kameras in jeweils einem eigenen Ordner zu importieren. So kann die Uhr in allen Fotos einer DigiCam angepasst werden.

Was jetzt noch fehlt ist die Software, mit der EXIF-Daten bearbeitet werden. Ich empfehle hier ein kleines Kommandozeilen Tool, eine GUI existiert dazu ebenfalls, aber bis man die begriffen hat ist man mit dem Tool längst fertig. Zum Einsatz kommt ExifTool von Phil Harvey.

Jetzt geht es ans eingemachte, zunächst gilt es die Zeitdiferenz der Kamera zur realen Zeit fest zu stellen. Dazu wird die Uhrzeit auf der letzte Aufnahme mit der Uhrzeit aus den EXIF-Daten dieser Aufnahme verglichen. Die Zeit aus den EXIF-Daten lesen wir mit dem Tool aus (kleiner Hinweis, ich habe die EXE-Datei umbenannt von exiftool(-k).exe zur exiftool.exe):

exiftool.exe OrdnerKamera1letzteAufnahme.jpg

Wichtig sind die Zeilen „Date/Time Original“ und „Create Date“. Zur diesem Zeitpunkt wurden die Aufnahmen gemacht.

Jetzt gehts ans rechnen, es muss die Differenz zwischen der realen und der in der Kamera eingestellten Uhrzeit berechnet werden. Diese Differenz ist für den Abgleich zwischen den Fotos wichtig und sollte stimmen. Wer sich mit dem Rechnen von Hand nicht sicher ist kann die folgende Seite zur Hilfe nehmen.

Falls nun die Uhr der Digitalkamera der realen Zeit hinterher gelaufen ist, werden wird die Differenz mit dem folgenden Befehl auf alle Fotos und alle EXIF-Daten auf addiert (im Beispiel 1Std., 1Min. und 1Sek):

exiftool.exe -AllDates+=01:01:01 OrdnerKamera1/*.jpg

Wenn es aber doch umgekehrt war und die Uhr der Digitalkamera der realen Uhr vorraus lief, wird die Differenz subtrachiert:

exiftool.exe -AllDates-=01:01:01 OrdnerKamera1/*.jpg

Wenn die Punkte der Reihe nach an allen Fotos der verschiedenen Digitalkameras angewendet worden sind, können nun die Fotos zusammen geschmissen werden und entsprechend den eigenen Vorlieben umbenannt.

linux vdr

VDR als MiniDLNA Server

Nachdem unser VDR dieses Jahr komplett neu aufgesetzt wurde, wollte ich Fehler aus dem Vorgänger ausräumen. Im Vorgänger kam MediaTomb als DLNA Server zum Einsatz, dieser kostete mich recht viel Zeit durch zahlreiche Anpassungen. Dieses mal habe ich mich vorher etwas mehr in die Problematik mit DLNA Server und Samsung Fernsehern eingelesen und kurzerhand für MiniDLNA entschieden.

Bei der Installation habe ich mich weitestgehend an die Anleitung aus dem Ubuntu Wiki gehalten. Diese ist detailliert und umfangreich und mach das ganze zur einem Kinderspiel.

vdr

VDR überarbeitet II (Squeeze + SSD)

vdradmin-am ohne Funktion

Das ist mir im ersten Moment nicht aufgefallen, aber nach dem Upgrade konnte ich die Seite von vdradmin-am nicht aufrufen. Es kam immer der Fehler:
Konnte Verbindung zu localhost:2001 nicht aufbauen: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
Bitte überprüfen Sie, dass VDR läuft und dass seine svdrphosts.conf richtig konfiguriert ist.

Der Fehler hat mich zunächst etwas Zeit gekostet. Dann kam ich aber auf die Lösung im VDR-Wiki. Seit vdr-1.7.15 wurde der Standard-Port auf 6419 geändert und deswegen antwortet er nicht mehr auf 2001. Es muss also der Port in /etc/var/setup.conf von 2001 auf 6419 geändert werden und schon ist das Problem gelöst. Im gleichen Zug muss der Port bei EPGSearch ebenfalls auf 6419 angepasst werden.

Storm sparen

Um Strom zu sparen möchte ich die eingebaute Samsung Festplatte bei Leerlauf in den Standby schicken, dazu wird hdparm installieren:
apt-get install hdparm

Die folgenden Zeilen in /etc/hdparm.conf schicken die Datenplatte in den Standby nach 15 Minuten:
/dev/sdb {
spindown_time = 180
}

Anpassungen für die SSD

Jetzt geht es ins eingemachte, um die SSD zur entlasten musst das Dateisystem von ext3 auf ext4 geändert werden. Zur diesem Zweck habe ich mir eine aktuelle Live-CD besorgt und den VDR davon gebootet. Änderung von ext3 auf ext4 erfolgt über:
tune2fs -O extents,uninit_bg,dir_index /dev/sda1
Nun noch ein kleiner Dateisystemcheck:
fsck -fCVD /dev/sda1
Bevor nun durchgestarten werden kann muss die /etc/fstab angepasst werden, in meinem Fall:
UUID=0415f59b-6535-47bb-ba4f-9f9ec86036ee / ext4 discard,noatime,errors=remount-ro 0 1
Damit ist die SSD nun vernünftig eingerichtet. Auch TRIM wird nun mit der Option discard in der /etc/fstab durchgeführt.

Quellen für die Einzelnen Punkte waren:
Martin Sebald
e-Tobi
ubuntu Users Wiki