Hier ist ein einfaches Beispiel, wie man mit ffmpeg ein Video in 720p mit 30 FPS konvertiert. Ausgehend von einer Full HD Auflösung (1920 x 1080 Pixel) ergibt sich dann eine Auflösung von 1280 x 720 Pixeln.

ffmpeg -i video.mp4 -vf scale=-1:720 -c:v libx264 -r 30 -crf 23 -preset fast -c:a copy video_720p30.mp4

Entscheidend für die Bitrate/Dateigröße und Qualität sind vor allem die Parameter

-crf

-preset

Außerdem soll das Video statt 60 FPS nur noch 30 FPS aufweisen, was mit 

-r 30

Meine mit dieser Methode konvertierten Videos haben  je nach Ausgangsmaterial eine Bitrate von etwa 6 bis 14 Mbit/s, was meiner Meinung nach akzeptabel ist. Mit dem CRF Faktor wählt man nicht die gewünschte Bitrate, sondern die gewünschte Qualität. Die Bitrate variiert, weil sich das Video je nach Inhalt unterschiedlich gut komprimieren lässt.

Ich habe das ganze in ein kleines Script gepackt und bei Github veröffentlicht, hiermit kann ich schnell meine Videos konvertieren. Der Aufruf erfolgt unter Angabe der Eingabedatei, Auflösung und Bildrate:

./video_convert.sh video.mp4 720 30

Die Lösung fand sich in folgender Zeile in der mdadm-Konfigurationsdatei

/etc/mdadm/mdadm.conf

ARRAY /dev/md0 metadata=1.2 spares=1 name=nas:RAID5 UUID=a6bbae11:8c383011:676a08ca:60cfd488

Dort wird explizit eine Festplatte als Spare-Festplatte reserviert, so dass ich die Zeile wie folgt geändert habe:

ARRAY /dev/md0 metadata=1.2 spares=0 name=nas:RAID5 UUID=a6bbae11:8c383011:676a08ca:60cfd488

Damit aus der Spare-Festplatte jetzt eine aktive Festplatte im RAID Array wird, habe ich das RAID Array unter Angabe der Anzahl der RAID-Festplatten vergrößert:

mdadm --grow /dev/md0 --raid-devices=6

Seitdem läuft nun das Reshaping, also das erneute Anordnen oder Reorganisieren des RAID Arrays, wie man mit 

cat /proc/mdstat

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf[5] sdc[0] sde[4] sdd[3] sdb[2] sda[1]
      15627548672 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [================>....]  reshape = 84.0% (3282224128/3906887168) finish=155.9min speed=66761K/sec
      
unused devices: <none>

Nun sieht man deutlich, dass keine Spare-Festplatte mehr vorhanden ist und alle Festplatten als aktiv genutzte Festplatte zum RAID Array gehören:

Warum dieses Verhalten nicht schon beim Hinzufügen der vierten oder fünften Festplatte aufgetreten ist weiß ich nicht, aber die Lösung war zum Glück einfach zu finden.

Ich habe keine Plugins installiert und ansonsten eine recht schlichte Konfiguration, weshalb ein Update wahrscheinlich ohne großes Risiko durchgeführt werden kann. Wem das zu riskant ist, der sollte eine Neuinstallation und eine anschließende Migration der Daten vornehmen. Dem Wiki ist jedenfalls zu entnehmen, dass ein Update als root Benutzer mit dem Befehl 

omv-release-upgrade

Processing triggers for initramfs-tools (0.120+deb8u3) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
Errors were encountered while processing:
 postfix
 bsd-mailx
 openmediavault
Creating index of upgradeable packages ...
Creating index of openmediavault plugins ...
E: Sub-process /usr/bin/dpkg returned an error code (1)

Nach einem Neustart wurde beim Aufruf des openmediavault Webzugangs nur eine weiße Seite angezeigt. Um das Problem zu beheben, habe ich folgende Schritte durchgeführt, wobei der Tipp größtenteils aus dem openmediavault Forum stammt:

omv-initsystem 
omv-update 
omv-mkconf nginx
omv-mkconf php5fpm
service php5-fpm restart
service nginx restart

Anschließend hat openmediavault wieder korrekt funktioniert, ich konnte mich einloggen und bei Durchsicht aller Einstellungen und Testen der NFS Verbindung waren keine Fehler festzustellen.

Somit ist jetzt auch das nächste System wieder auf aktuellem Stand.

Mit durchschnittlich etwa 30 aktiven Users ist Pimux.de zwar ein kleiner Server, aber gerade darum geht es bei XMPP schließlich. WhatsApp ist aktuell gegenwärtiger denn je, aber auch die gar nicht viel bessere Alternative Telegram ist bereits dem einen oder anderen Benutzer bekannt.

Die stetig wachsende Zahl der XMPP Server und Nutzer spricht dafür, dass vielen Nutzern sicheres Messaging und Privatsphäre wichtig sind: Werft doch mal einen Blick auf die XMPP Network Map von Thomas Leister.

Das System läuft nicht permanent, ich nutze ein kleines Script, um es bei Nichtgebrauch herunterzufahren. Ich muss zugeben, dass ich kein RAID-Experte bin. Ich weiß wie bzw. wo Daten und Paritäten gespeichert werden, wie ich es erweitere und bei Bedarf eine defekte Festplatte tauschen kann. Mir ist auch bekannt, dass die langsame CPU den Flaschenhals bildet, da das Berechnen der Paritäten recht aufwendig ist. Aber wenn ich nach dem Hochfahren eine größere Datenmenge auf das RAID5 schreibe, hängt das System für mehrere Minuten beinahe vollständig. Nach ein paar Minuten kann ich problemlos mit recht hoeher Geschwindigeit Daten schreiben.

Folgendes Beispiel veranschaulicht das Verhalten:

# 10 GB Testdaten schreiben:
dd if=/dev/zero of=test.img bs=1M count=10000
# und gleichzeit iotop aufrufen:
iotop -b -n 1 -o
Total DISK READ:       2.88 M/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
 5472 be/4 root        2.58 M/s    0.00 B/s  0.00 % 99.99 % [flush-9:0]

Die Load geht bis etwa 10 hoch, top zeigt einen hohe iowait:

%Cpu(s):  0,0 us,  1,2 sy,  0,0 ni, 50,8 id, 47,5 wa,  0,0 hi,  0,5 si,  0,0 st

Natürlich verursacht das Schreiben eine hohe IO-Aktivität und auch das flush-Prinzip ist mir bekannt, denn auf Linux Systemen werden Daten häufig asynchron erst in dem RAM und dann auf die Festplatten geschrieben, um eine möglichst hohe Performance zu gewährleisten. Wirklich stutzig macht mich hier aber die Tatsache, dass flush Daten liest. Das Resultat ist eine scheinbar schlechte Schreibperformance:

10485760000 Bytes (10 GB) kopiert, 525,175 s, 20,0 MB/s

Der zweite und jede weitere Schreibvorgang hingegen läuft deutlich schneller:

10485760000 Bytes (10 GB) kopiert, 62,9669 s, 167 MB/s

167 MB/s sind für diese schwache CPU in meinem Augen völlig zufriedenstellend. Die Lesegeschwindigkeit ist ebenfalls in Ordnung:

10485760000 Bytes (10 GB) kopiert, 37,6012 s, 279 MB/s

Ein Graph der Arbeitsspeicherauslastung (auch manuell mit

free -m

Der hellblaue Bereich ist der Cache, der nach dem Booten (etwa gegen 18:30 Uhr) kaum verwendet wird. Ab etwa 18:47 Uhr wächst der hellblaue Bereich, bis er ein paar Minuten später (18:55 Uhr) sprunghaft ansteigt und um 18:56 Uhr sein Maximum erreicht hat. Innerhalb dieses Zeitraums wird ebenfalls der Buffer beansprucht, der dann wieder kleiner wird, da Daten dann auf die Festplatte geschrieben werden können. Danach läuft alles wieder normal und es können ohne spürbare Performance-Engpässe Daten geschrieben werden.

Ich frage mich, was genau der flush-Prozess während des Schreibens liest und warum das Schreiben dadurch so enorm blockiert wird. Wahrscheinlich ist dies ein recht normales Verhalten, welches aber kaum auffällt, da die meisten NAS Systeme über mehr Leistung verfügen und nur selten neu gestartet werden. Aber vielleicht liegt tatsächlich ein Problem vor und ich sehe es nur nicht.

Welche Art von Daten benötigt Linux im RAM, bevor es performant schreiben kann und wie lässt sich dieser Prozess optimieren? An diesem Punkt stelle ich leider wieder einmal fest, dass mein Wissen nicht ausreicht und ich noch einiges vor mir habe. Auch das Verändern der stripe_cache_size (aktuell 8192, auch kleinere Werte bis 256 habe ich probiert) bringt bei diesem Problem keine Veränderung. Früher oder später wird sich aber eine Lösung oder zumindest eine Erklärung finden lassen. Was mich aber wundert: Hat sonst noch nie jemand dieses Verhalten in dieser Größenordnung festgestellt?

Weitere Details sind im entsprechenden Beitrag auf pimux.de zu finden.

Auch wenn die Karten in der Regel deutlich detailreicher als Google Maps sind, gibt es in jeder Gegend noch viel zu tun. Auch als Anfänger kann man inzwischen erstaunlich einfach seinen Beitrag leisten. Mein OSM-Account ist zwar schon von einige Jahre alt, aber erst seit wenigen Wochen bin ich wieder aktiv dabei. Bis vor kurzem wusste ich noch gar nicht, wie viele Details in den Linien, Flächen und Punkten stecken. Ich stelle hier nur meinen kleinen persönlichen Workflow vor, wer mehr wissen möchte, sollte einen ausführlichen Blick in das OpenStreetMap Wiki werfen.

Für kleine Ergänzungen unter Android: StreetComplete

Die Android App StreetComplete zeigt Straßen, Gebäude und sonstige Punkte an, zu denen noch Informationen fehlen. Die Informationen können relativ leicht hinzugefügt werden und erfordern keine Vorkenntnisse, da recht einfache Fragen wie in etwa „Welcher Straßenbelag hat diese Straße?“, „Welche Hausnummer hat dieses Haus?“ und „Hat die Bushaltestelle einen Unterstand?“ gestellt werden. Die Antworten sind entweder vorgegeben (sogar bebilderte Straßenbeläge) oder einfach einzugeben.

StreetComplete ist sehr einfach zu bedienen und eignet sich meiner Meinung nach gut für Einsteiger und generell als Zeitvertreib für Zwischendurch.

Für die meisten Änderungen im Desktop-Browser: iD Editor von openstreetmap.org

Für einfache Änderung verwende ich den webbasiertern iD Editor auf openstreetmap.org. Man sucht das entsprechende Gebiet, klickt im oberen Bereich auf Bearbeiten und schon kann es losgehen. Für Häuser, Straßen / GPX Tacks, und Attribute ist der Editor gut geeignet und einfach zu bedienen.

Für komplexere Änderungen auf dem Desktop: Merkaartor

Komplexe Änderungen wie z.B. das Erstellen von Reihenhäusern, das das nachträgliche Zerschneiden von Häusern oder das massenhafte Kopieren von Attributen nutze ich Merkaartor. Eine gute Dokumentation konnte ich zwar nicht finden, aber nach ein paar Minuten hat man sich gut eingearbeitet.

GPX Tracks unter Android aufnehmen: OsmAnd

Meine Liebling-Navigations-App OsmAnd kann nach Aktivierung des Streckenaufzeichnung-Plugins mit einem Klick GPX Tracks erstellen und speichern, welche ich dann auch direkt in der App zu OpenStreetMap hochlade. Anschließend nutze ich den iD Editor auf der OpenStreetMap Webseite und zeichne die fehlenden Wege oder Straßen nach.

Für Kleinigkeiten unterwegs: Vespucci

Vespucci ist ein recht mächter OSM-Editor in Form einer Android-App. Ich muss aber zugeben, dass die meisten Änderungen am Desktop schneller erledigt sind. Ich setze Vespucci ein, wenn ich Hausnummern eintragen, schnell einen POI hinzufügen möchte oder sonstige überschaubare Objekte editieren möchte. Der Vorteil ist offensichtlich: Man sieht beim Editieren seine Position, was besonders bei Hausnummern und POIs eine Erleichterung ist.

Sicherlich hat jeder Editor seine Vor- und Nachteile und jeder Nutzer arbeitet anders. Wer jetzt Lust auf mehr bekommen hat, aber nicht weiß, wo er starten soll, dem kann ich den OpenStreetMap Leitfaden für Anfänger von learnosm.org empfehlen. Es existieren zahlreiche Attribute, mit denen Punkte, Linien und Flächen versehen werden können. Erst die Attribute machen aus Linien verschiedene Straßen- und Wegtypen, aus Flächen Gebäude oder Wälder und aus Punkten fast alles, was man sich vorstellen kann: sogar einen Hundekot-Tüten-Spender lässt sich eintragen.

Damit der Rechner nur dann läuft, wenn eine Aufnahme ansteht, habe ich tvh-auto-power.py geschrieben. Dieses kleine Python Script wird regelmäßig als Cronjob ausgeführt und erfüllt zwei Aufgaben:

1. Der Rechner wird automatisch heruntergefahren, wenn folgende Bedingungen erfüllt sind:
   • Keine Aufnahme läuft oder gleich beginnt
   • Keine Verbindung (z.B. Kodi Client, Webinterface oder SSH) aktiv ist
   • Der Rechner bereits für eine gewisse Zeit läuft (min_uptime, damit nach mauellem Hochfahren nicht sofort wieder heruntergefahren wird)
2. Vor dem Herunterfahren wird die Zeit für das nächste automatische Hochfahren gesetzt
   • Wenn eine Aufnahme geplant ist, wird diese Zeit (minus ein paar Minuten Puffer) verwendet
   • Wenn keine Aufnahme geplant ist, wird nach 24 Stunden hochgefahren (z.B. damit EPG aktualisiert werden kann und Autorec neue Sendungen findet)

Leider unterstützt nicht jeder Rechner automatisches Hochfahren (Stichwort rtc wakeup), manchmal ist diese Option noch im BIOS zu aktivieren. Das Script nutzt jetzt neuerdings

rtcwake

apt-get install rtcwake

.nomedia

Normalerweise braucht man diese Datei nicht manuell anlegen oder löschen, aber nachdem ich den Nextcloud Speicherort auf die SD Karte verschoben habe, tauchten heruntergeladene Bilder nicht mehr in der Galerie auf. Der standardmäßig in CyanogenMod und LineageOS integrierte Dateimanager bietet glücklicherweise durch das Setzen oder Entfernen eines Hakens bei „Medienscan überspringen“ die Möglichkeit, diese Datei anzulegen oder zu löschen.

Dessen war mir bisher nicht bewusst, aber ausnahmensweise bin ich einmal froh, mir den Weg über eine Shell zu sparen. Natürlich führt auch der Weg über ein Terminal zum gleichen Ergebnis:

adb shell
cd /storage/A14F-395E/Android/data
# Datei anlegen, Medienscan überspringen
touch .nomedia
# oder Datei löschen, Verzeichnis in Medienscan aufnehmen
rm .nomedia

Glücklicherweise bietet Nextcloud seit der Version 1.4 die Möglichkeit, den Speichert in den Einstellungen festzulegen. Das Einstellungsmenü erreicht man, wie häufig üblich, über den Button mit den drei Strichen, welcher in der App oben links zu finden ist. Falls der Button nicht zu sehen ist, befindet man sich vermutlich einem Ordner, stattdessen wird oben links dann der Pfeil zurück angezeigt. Drückt man diesen, bis man im obersten Verzeichnis angekommen ist, findet man den Menü-Button.

Wählt man in diesem Menü den Punkt Einstellungen, stolpert man an oberster Stelle bereits auf die Einstellungsmöglichkeit des Speicherortes. Die Bezeichnungen bzw. Pfade sind auf den ersten Blick ein wenig verwirrend, aber A14F-395E ist meinem Fall der Name der Speicherkarte.

Glücklicherweise haben die Nextcloud Entwickler daran gedacht, bereits auf dem internen Speicher vorhandene Daten bei Änderung des Speicherortes zu migrieren, so dass schon heruntergeladene Daten nun auch die die Speicherkarte verschoben werden. Hiermit ist mein recht kleiner interner Speicher von 4 GB nun deutlich entlastet.

Sollte das Problem auftreten, dass nach dem Verschieben des Speicherortes die Bilder/Musik/Videos nicht mehr in der Galerie oder der Musik App auftauchen, schaut mal in meinen Beitrag zur .nomedia Datei.