Java - Projekt? - Ja!

Hallo,

nachdem ich feststellen musste, dass mein Perl-Geschreibsel nicht wirklich zu portieren war und meine Ideen nicht mehr zum Script-Ansatz passten, habe ich angefangen, das ganze auf solide Füße zu stellen.

Aus einer Vielzahl von Gründen habe ich mich dafür entschieden, das Ganze unter Java zu realisieren.

Nochmal kurz zu der Idee:
Ich möchte einen "Menü-Editor", mit dem ich Vorlagen erstellen kann, die dann rel. schnell zur Umwandlung von Aufnahmen zu DVD's verwendet werden können.
Was ich nicht möchte ist das nach zu programmieren, was andere viel besser können (ala ProjectX, dvdauthor, etc.). Wie bei vdr2iso auch, soll die Umwandlung von der Vorlagen-Erstellung abgekoppelt sein und z.B. auch remote angestoßen werden können.

Warum nicht das burn-Plugin verwenden?

Ich habe einen rel. kleinen VDR, der nicht wirklich in der Lage ist, DVD's umzuwandeln. Vielleicht ist es ja auch hilfreich für die Leute, die einen Aufnahme-Server ohne Bildschirm betreiben.

Der Menü-Editor ist soweit gediehen, dass man bereits interaktiv Menüvorlagen erstellen und speichern kann. Dabei ist der Menü-Editor ähnlich wie Eclipse aus Plugins aufgebaut, d.h. Anwendungen und Themen können beliebig dazu geladen werden.

Falls also jemand Lust hat, die kalten Winterabende damit zu verbringen, mit mir das Baby zu schaukeln, würde ich mich sehr freuen.

Da ein Bild bekanntlich mehr als 1000 Worte sagt, hier mal einige Bildchen von dem, was schon da ist.

Da ich nicht "bloß" eine Anwendung stricken, sodern dabei auch noch was lernen wollte, habe ich vieles selbst gemacht, für das es evtl. schon Bibliotheken gibt. Trotzdem sind natürlich auch Fremdbibliotheken im Einsatz.

Die Rahmen-Anwendung kann als MDI-Anwendung oder als Anwendung mit einzelnen Fenstern laufen. Die "inneren" Fenster sind eigenständige Anwendungen, die einfach geladen werden. Jede Teil-Anwendung bringt ihr eigenes Menü mit, sodass das Ganze auch bedienbar wird. Vorschau und Editor sind auch jeweils eigenständig und sind nur von den Daten abhängig. So klappt die Synchronisation und trotzdem kann jeder ohne den anderen auskommen.

Die Aufnahmen werden von Festplatte eingelesen und entsprechend angezeigt.

Bei mir läuft das Ganze mit einer mysql-Datenbank, dürfte, dank Java, aber auch mit jeder anderen funzen.

Die Vorschau zeigt ein (konfigurierbares) Gitter an, sodass die einzelnen Element visuell ausgerichtet werden können. Ebenso wie das Gitter kann auch der Overscan-Bereich des Fernsehers maskiert und ein- bzw. ausgeschaltet werden. Fürs Feintuning gibt es den Eigenschaften-Dialog, in dem dann pixelgenau positioniert werden kann.
Wo möglich wird das Scrollrad der Maus unterstützt, um zügig voran zu kommen.

Den Navigationselementen können Grafiken zugeordnet werden, die bei Zustandsänderung des Navigationselements auch ihr Aussehen ändern (können).

Hallo Leuts,

schade, dass niemand Lust hat mit zu machen.

Anyway - ich bleib trotzdem dran.

Ich habe die Geschichte erstmal auf meinen Server gestellt. Falls jemand das Projekt beobachten möchte, hier folgen Dokumention und Download von VDRAssistant. Im Moment habe ich noch ca. 20 offene Punkte, es wird also noch eine Weile dauern

Ach ja, meine erste DVD habe ich mit den Programmen bereits erfolgreich umgewandelt.

Hey - es kommt Leben auf

Hallo miteinander.

Zitat

Aber bis jetzt ist ja noch nicht klar wofür bei dieser Anwendung eine Datenbank benötigt wird.

Darauf gibt es keine kurze Antwort. Deshalb:

Wer vdr2iso nicht kennt, möge sich bitte mal kurz einlesen - zumindest in Funktionalität und Aufgabenstellung.
Mit VdrAssistant habe ich als Java-Projekt begonnen, weil ich mit perl + tk + xml an die Grenzen gestoßen bin und noch viele unerfüllte Wünsche in der Pipeline hatte/habe. Die Portierbarkeit auf Windows war nur ein Punkt von vielen.

VdrAssistant wird also keine "kleine" Anwendung, mit der man "mal eben" ne Aufnahme konvertiert (obwohl das auch ein Anwendungsfall ist), sondern es ist eine Sammlung von Anwendungen, die nahtlos zusammen spielen soll. Das Ganze soll so nahtlos funzen, dass man net merkt, dass viele Anwendungen zusammen spielen. Tja und der Funktionsumfang von vdr2iso + jobeditor ist das Minimum für VdrAssistant. Schließlich gibt es noch viele Anwender, die kein Interesse an DVD haben und deshalb nach VCD oder irgend ein anderes Zielformat umwandeln. Da kenn ich mich nun überhaupt nicht aus, kann also auch nix zu dem Thema beitragen. Aber ich wollte wenigstens die Architektur so anlegen, dass auch andere Umwandlungen möglich werden.

Ich bin faul, bequem und dekadent - also erwarte ich eine Anwendung, die sich ohne Handbuch bedienen läßt. Dass dabei jetzt eine Datenbank ins Spiel kommt ist eine große Erleichterung bei der Entwicklung - und für die Installation heißt es vielleicht einmal "OK" mehr also ohne. Wer zu Fuß installiert bekommt ne Datenbank mit 2-3 Befehlen installiert. Kann also nicht so das Problem sein.

Was ich nicht mag, ist jemand vorschreiben, welche Datenbank er einzusetzen hat. Deshalb bin ich auf SQL-Niveau herunter gegangen. Deshalb gibt es bei mir auch ne Datenabstaktions-Schicht. Das braucht aber nur Leute zu interessieren, die mitarbeiten wollen. Das heißt jetzt aber nicht, dass es in der Anwendung Sql oder JDBC-Anweisungen geben würde - ganz im Gegenteil. Meine DA-Schicht ist so etwas wie ein MiniJPA - in der Anwendung gibt es nur Klassen und Instanzen!

Der Endanwender spürt (außer bei der Installation vielleicht) nix von der Datenbank.

Alle die mit dem burn-Plugin arbeiten können brauchen VdrAssistant nicht.
VdrAssistant ist (der Egoist denkt an sich zuerst ) für vernetzte Umgebungen, in denen der VDR klein und leise ist (bei mir ist es ein PII/400) und die Umwandlung auf einem anderen Rechner erfolgen soll/muss.

Ein weiterer Punkt, der mich bei meinen Skripten gestört hat: es ist noch viel zu aufwändig, ne Aufnahme umzuwandeln. Also musste das Konzept umgestrickt werden, denn ich wollte die Menüerstellung von der Aufnahmen-Umwandlung trennen.
Bei dem jetzigen Ansatz könnten Leute die Spaß an Grafik haben Themen und/oder Skins erstellen und anderen zur Verfügung stellen. Hier zeigt sich auch wieder ein Vorteil der Datenbank, denn ein Skin-Ersteller kann alles visuell erstellen und abspeichern. Das Portieren einer Skin beschränkt sich dann auf den Austausch eines Sql-Inserts, was z.B. mit mysql zur Trivialität ausartet
Für die Umwandlung heißt das dann "nur" noch Thema und Skin auswählen, Aufnahmen zuordnen und Feuer frei.

Naja - und je mehr Komfort die Anwendung bieten soll, desto größer ist der Entwicklungsaufwand - deshalb gibt es noch jede Menge zu tun.
Java-Knowhow ist willkommen aber nicht Voraussetzung. Alpha-Tester mit guten Nerven und konstruktiver Einstellung sind ebenso willkommen
Ein weiterer großer Wunsch von mir ist "vdrsync -i" zu ersetzen. Dazu muss man sich allerdings recht gut mit den Stream-Spezifikationen auskennen. Ich fand noch keinen Zugang zu dem Thema - teils aus Zeitmangel, teils weil die Materie so komplex ist ...
also wenn jemand mit solchen Kenntnissen Zeit und Spaß an einer Mitarbeit hätte - da wären Javakenntnisse völlig unerheblich. Pseudocode und/oder ne gute Erklärung würde mir reichen

Falls jemand ernsthaft Interesse an einer Zusammenarbeit hat, könnten wir das "wie" ja per email klären.

Vielleicht macht es Sinn, wenn ich mal aufführe, wo ich welche Unterstützung brauchen könnten?

• Java- und Perl-Kenntnisse vorhanden
  bestehende Funktionalität aus meinen "alten" Scripten in Java bzw. ins Framework übertragen
  

  
  

• Kenner von Netzwerk-Protokollen
  Der Verarbeiter sollte als Dienst installierbar sein. Als Systemdienst unter Windows, mit init-Scripten für Linux.
  Vieleicht macht SOAP-Schnittstelle Sinn?
  

  
  

• Administrator-Kenntnisse o.ä.
  die Anwendung gegen andere Datenbanken und unter Windows testen. Unter Linux habe ich sehr gute Erfahrung mit dem freien vmware-Server gemacht. Damit kann man schnell mal neue Installationen testen, ohne sein eigenes System zu versauen.
  Wenn jemand sich mit der Erstellung von RPM-paketen, deb-paketen und/oder Installierern unter Windows auskennt ...
  

  
  

• Codec-Insider (1)
  wie schon angedeutet, hätte ich gerne 'vdrsync -i' ersetzt. Mit meinem cutmarks-Patch arbeitet "vdrsync -i" so, dass von der ersten Schnittmarke an die Aufnahmen untersucht werden und die gefundenen Streams werden mit Größenprognose ausgegeben.
  Wer sowas ähnliches machen kann (Programmiersprache egal, sollte halt auf Windows und Linux funktionieren) würde mich damit sehr erfreuen.
  Es kann auch ein völlig eigenständiges Programm sein, welches über die Befehlszeile funktioniert (also keine Grafikanwendung).
  Schnittstelle sollte so funktionieren, dass ich Aufnahme-Verzeichnis und Schnittmarke (Unterstützung für bytepos und timecode wäre genial) als Parameter übergeben kann und die Informationen werden als Text ausgegeben.
  Die Ausgaben würde ich dann parsen, um die Informationen in die Datenbank zu übernehmen.
  Idealerweise sollte dieses Infoprogramm nicht nur mit VDR-Aufnahmen klarkommen, sondern z.B. auch (nicht verschlüsselte!) DVD-Quellen untersuchen können.
  

  
  

• Codec-Insider (2)
  Wenn es andere Zielformate gibt, bei denen ein Menü ala DVD-Menü Sinn macht, würde ich auch mich hier über Informationen/Mitarbeit freuen.
  

  
  

• Grafik-Kenner (1)
  Entwurf neuer Themen.
  

  
  

• Grafik-Kenner (2)
  Falls jemand schonmal ne Diashow auf DVD gemacht hat ...

Bei allen Punkten gilt: wer die Kenntnisse nicht hat, aber sich solche aneignen möchte ist genauso herzlich willkommen. Ne professionelle Grundeinstellung setze ich mal als selbstverständlich voraus
Ich weiß nicht, ob ich es schon erwähnt habe: das Framework und die Anwendung sind Freeware und daran will ich auch nichts ändern!

update in eigner Sache - oder auch Fortsetzung eines Monologes

VdrAssistant wurde von SF als Projekt akzeptiert, sodass es in Zukunft nicht nur bei mir Kwark mit Sauce gibt
Allerdings ist der Verwaltungsaufwand enorm und manche Punkte überfordern mich noch (so habe ich noch nie ne Mailingliste eingerichtet, etc.) Es wird also noch etwas dauern, bis die Infrastruktur rund läuft.

Bis dahin habe ich eine gute Nachricht vom Oberhaupt der Centurianer:
Für alle, denen vor nix graust und die Spaß dran haben, griechischen Anwender (auch Alphatester genannt) zu spielen, gibt es den ersten download. Allerdings noch nicht über SF, sondern über die Homepage von VdrAssistant.

Bitte dran denken: es ist eine Entwicklungsversion und weit davon entfernt, ein release zu sein.

Ansonsten: Kommentare, Kritik und/oder Verbesserungsvorschläge sind herzlich willkommen.