Ich bin stolz. Letzten Samstag habe ich das Plugin Permashift für den digitalen Videorekorder VDR in der Version 1.0 veröffentlicht. Wie der VDR selbst steht es gratis zur Verfügung und darf auch verändert werden (Open Source). Es steckt harte Arbeit darin.

Permashift erweitert den VDR so, dass man aus dem Live-Programm zurück­spulen kann. Manche nennen das einfach Timeshift, andere verstehen unter Timeshift nur die Möglichkeit des Pausierens und die Funktion von Permashift heißt dann permanenter Timeshift. Warum ich sowas haben will, davon habe ich ja schon erzählt.

Version 0.5.x

Die ersten Versionen von Permashift haben das mit einem Trick er­reicht. Bei jedem Umschalten wurde eine Aufnahme auf Festplatte gestartet und beim nächsten Umschalten automatisch wieder gestoppt und gelöscht. Das hatte einige Nachteile: Die Festplatte wird häufig belastet, es ist immer eine aktuelle Aufnahme in der Aufnahmeliste zu sehen, wer eine Aufnahmeleuchte installiert hat, sieht sie ständig leuchten, wenn Aufnahmen Aktionen auslösen, passieren die nun bei jedem Umschalten (gegebenenfalls zweimal) und wenn man den Fernseher mitten in einer interessanten Sendung anmacht, kann man nicht zurückspulen, weil die Aufnahme auf Fest­platte eben doch nicht rund um die Uhr läuft.

Meine Timeshift-Bedürfnisse waren damit trotzdem zu 90% erfüllt. Es wurde aber immer wieder nach einer Version gefragt, die Live­fern­sehen rund um die Uhr im Hauptspeicher puffert und nur bei Bedarf die Festplatte nutzt. Ich habe mich schließlich darangemacht. Kann ja auch nicht so schwer sein, dachte ich mir…

Der Neuanfang

Jemand hatte auf der Permashift-Homepage geschrieben, er habe gehört, dass ein Ringspeicher unter Linux schwierig zu implemen­tieren sei. Zumindest, was die Speicherung selbst betrifft, ist das Quatsch. Sowas ist eigentlich unter jedem Betriebssystem gleich. Dementsprechend war der Ringspeicher an einem Nachmittag geschrieben (auch wenn er da noch einen Fehler hatte).

Das Zwischengespeicherte direkt auf Festplatte zu bringen und ab­zu­spielen funktionierte auch bald. Wenn man darin mit dem VDR zu­rück­spulen wollte, sah man allerdings nichts, weil er dafür spezielle Anforderungen an die Verwaltungsdaten im Video stellt. Die eigent­liche Heraus­for­derung war aber dann, bei einer Verwendung des Zwischen­speichers so umzuschalten, dass das Video aus dem Speicher und das direkt auf Festplatte aufgenommene nahtlos aneinanderpassen.

Die Lücke

Die Aufnahme ab dem Zurückspul-Zeitpunkt wollte ich dem VDR-​Code überlassen. Doch der springt nicht sofort an. Er wartet, bis er genug Ver­wal­tungs­informationen im Video begegnet ist. Als ich das Plugin endlich daran angepasst hatte, funktionierte die Aufnahme. Nahtlos. Doch als ich es das nächste Mal probiert habe, war wieder eine Unterbrechung in der Aufnahme. Ich habe schließlich heraus­gefunden, dass verschiedene Sender die Verwaltungsdaten unter­schiedlich oft aussenden, und die Erwartung  des VDR, sie innerhalb von 5 Daten-Paketen zu finden, für viele Sender reichte – für andere allerdings 6 Pakete benötigt wurden.

Aber reichen 6 Pakete für jedermann? Ich habe daraufhin ein Test­progrämmchen geschrieben und eine Umfrage unter den VDR-Nut­zern gestartet. Es kamen Reaktionen von Finnland bis Neuseeland. Als es schon schien, als würden 6 Pakete für alle Sender reichen (solange es keine Übertragungsfehler gab), hat jemand bei WDR HD 13 Pakete gemessen. Der Herr über den VDR, Klaus Schmidinger, hat den Grenzwert im VDR dann auf großzügige 100 Pakete hochgesetzt.

Das Problem war nie aufgefallen, weil es im normalen VDR-Betrieb nur dazu führt, dass eine Aufnahme eine halbe Sekunde später ge­startet wird. Solange nicht zwei Videos perfekt zusammenpassen müssen, merkt das natürlich nie jemand.

Spulen

Als das dann endlich geschafft war… kam ein neues Problem. Wieder waren nur manche Sender betroffen. Unter Umständen hat der VDR den Anfang eines Bilds nicht recht­zeitig erkannt, so seine Verwal­tungs­in­formationen zu spät gespei­chert und konnte beim Zurück­spulen das Video nicht anzeigen. Auch hier ein altes Problem im VDR, das nur unter den ganz speziellen Be­din­gungen von Permashift auf­trat. Wo im normalen Betrieb die Daten schubweise kommen, tröp­feln sie bei Permashift, und daher wurden manchmal Bilder nicht erkannt. Auch hier wurde der VDR korrigiert.

Unit-Tests

Um sicherzustellen, dass Permashift funktioniert, habe ich sogar ein paar Unit-Tests geschrieben, also Code, der nur dafür da ist, die korrekte Funktion von anderem Code sicherzustellen. Das dürfte im Open-Source-Umfeld ungewöhnlich sein. Und tat­sächlich habe ich damit noch einen Fehler gefunden in dem Pro­grammteil, der das Video speichert und bei einem Überlauf des zur Verfügung stehenden RAMs die ältesten Teile der Aufnahme über­schreiben muss.

Betatests

Als ich dann endlich zuversichtlich war, dass es funktionieren würde, habe ich das Programm im März im VDR-Portal zum Testen vor­ge­stellt. Schon bei den 0.5er-Versionen hatte ich die Erfahrung gemacht, dass es bei mir noch so gut laufen kann, es gibt viele unterschiedliche VDR-​Installationen und -Konfigurationen, bei denen es unter Um­ständen ganz anders aussieht. Die Tests liefen ganz ok, wenn auch mit einigen Problemmeldungen, die ich zum Teil nicht nachvollziehen konnte.

Ich habe mich dann darangemacht, noch eine Baustelle zu bearbeiten: Wenn man nach längerem Fernsehen auf zurückspulen drückt, will man nicht warten, bis ein gut gefüllter mehrere Gigabytes großer Speicher auf Festplatte geschrieben ist. Das kann pro GB 10 Sekun­den und länger dauern. Ich habe daher eingebaut, dass nur der letzte Teil abgespeichert wird, und der Rest dann parallel zum Zurück­spulen. Das könnte zwar schiefgehen, wenn das Spulen schneller ginge als das Speichern, klappte bei mir aber locker.

Da mir das Paket Permashift damit zum ersten Mal „rund“ erschien, habe ich die Betaversion 1.0 genannt und im Juni nochmal zum Testen vorgestellt. Leider habe ich nun sehr wenige Rückmeldung bekommen. Bei einem funktionierte es, ein anderer hatte unklare Probleme mit verschiedenen Plugins, die ich aus technischen Gründen auch nicht ausprobieren konnte. Aber ich konnte anhand seiner Informationen immerhin feststellen, dass Permashift noch ein Problem mit dem Speichern über 4 GB hinaus hatte (die Grenze dessen, was man mit 32 Bit darstellen kann). Das habe ich noch korrigiert.

Aber ich stand dumm da: Fehler, die ich nicht nachstellen konnte, und von den wenigen, die die zweite Beta ausprobiert hatten, hatte sich nur ein weiterer zurückgemeldet. War Permashift nun bereit für die Veröffentlichung oder nicht?

1.0

Ich habe dann nach einer weiteren Pause ein paar Leute einzeln angeschrieben, in der (nur teilweise erfüllten) Hoffnung, dass sie sich dann auch zurückmelden werden. Als die erste positive Rückmeldung – verbunden mit Erweiterungswünschen, wie sollte es anders sein? – kam, hab ich mir ein Herz gefasst und die Version 1.0 veröffentlicht. Von den 58 Leuten, die es seitdem heruntergeladen haben, hat kein einziger gemeldet, ob es funktioniert hat. Aber ist ja auch keine Test­version mehr. Trotzdem ist es schade, dass sich selbst bei dedizierten Tests die meisten nur melden, wenn es nicht funktioniert.

Fazit

Insgesamt war die Entwicklungszeit von Frustmomenten geprägt. Immer wieder traten dieselben Symptome auf, nachdem das ent­sprechende Problem schon gelöst schien, wie beim Rück­wärts­spulen oder dem nahtlosen „Aneinan­der­kleben“ der beiden Video­teile. Gerade, wenn man auch das Berufsleben mit Programmieren ver­bringt, fällt es da schwer, dranzubleiben.

Umso stolzer bin ich darauf, dass ich mich durchgebissen habe.