Datenbankanbindung

Saxman2k · 13. Februar 2004

Hallo liebe VDRler!

Ich bastel seit kurzem an einer Möglichkeit, Aufnahmen zu katalogisieren. Mangels Kenntnisse wie ich in einem Shell-Script oder per C eine SQL-Datenbank ansprechen kann, gehe ich den Umweg über lynx und PHP.
Das klappt soweit auch ganz prima. Es wird der Titel, Untertitel, Aufnahmedatum, Filmlänge und EPG Information abgespeichert. Das Ganze läuft über einen Befehl in der reccmds.conf. Hier wird per lynx ein PHP-Script mit dem Pfad der Aufnahme aufgerufen. Und da ist auch schon der Knackpunkt: z. B. die Aufnahme "/video/%Quarks_&_Co./2004-02-11.10.45.88.88.rec" beinhaltet leider ein "&". Für das PHP-Script bedeutet das also: der nächste Parameter beginnt nach dem "&".
Soweit mir bekannt gibt es keine Möglichkeit ein "&" in einem Parameter einzubauen (bitte belehrt mich eines besseren :]). Da meine Kenntnisse bei Shell-Scripten mehr als dürftig sind nun meine Frage. Wie kann ich solche unerwünschten Zeichen in einem Textstring ersetzen?
Oder alternativ: wie kann ich direkt in der Shell eine SQL-Datenbank ansprechen? Ich habe hier zum Testen erstmal MySQL laufen (vielleicht etwas überdimensioniert, aber viele gute Erfahrungen von der Arbeit).

Weiterhin ist geplant, daß man direkt aus VDR heraus nach Titeln suchen kann. Z. B. weil man nicht mehr weiß, ob man denn diesen Film schon archiviert hat. Außerdem möchte ich noch weitere Informationen abspeichern. Als da wären:
- Anzahl der Audiospuren, eventuell mit den zugehörigen Sprachen
- Tonformat (DD, MPEG)
Wie kann man denn diese Informationen aus den Aufnahmen gewinnen?

Schon mal Danke an Alle, die sich hierzu Gedanken machen.

slime · 13. Februar 2004

hi,
ich denke mal das dies eine gute aufgabe für perl ist: http://search.cpan.org/~rudy/D…l-2.9003/lib/DBD/mysql.pm
dazu gibts dan DBI::mysql um die DB anzusprechen. dazu finden sich im netz auch eine menge beispiele.
zu dem aufnahmen und informationen gewinnen: mmh ... schwierig. das mit den sprachen klappt wohl erst mit dem vdr 1.3.x, das andere kann man mit vdrsync rausfinden (was aber wohl kein guter weg ist)

devnix · 14. Februar 2004

ich habs mit einem script gemacht....

#!/bin/sh

SQL_HOST=debian
SQL_USER=vdr
SQL_PASS=vdr
SQL_DB=vdr

if [ "$1" = "after" ];
then
echo "insert into recordings set film='$2',summary='`cat $2/summary.vdr`' ;" | mysql -u$SQL_USER -p$SQL_PASS -D$SQL_DB -h$SQL_HOST;
fi

Saxman2k · 14. Februar 2004

Hallo zusammen!

slime
Habe mich noch nicht näher mit Perl befasst. Bevor ich noch eine neue Sprache lerne, versuche ich es erst mal mit der Shell.

devnix
Cool! Ich wußte garnicht, daß man mysql so einfach ansprechen kann. Ich werde das wohl so wie Du anfassen.

Jetzt fehlt mir eigentlich nur noch eine Möglichkeit aus dem Pfadnamen Datum und Uhrzeit sowie Titel und Untertitel zu extrahieren. Das geht doch sicher irgendwie mit cut oder grep. Bei cut habe ich das Problem, daß ich einen Bereich angeben muß. Irgendwie muß ich also wissen wie lang der Textstring ist. Bei regulären Ausdrücken muß ich definitiv das Handtuch werfen. Das sieht mir immer etwas chinesisch aus.

sithmein · 14. Februar 2004

Hi,

Also mit Perl würde ich das Datum folgendermaßen aus dem Dateinamen herauspfrimeln:

Code

my $filename = '/video/%Quarks_&_Co./2004-02-11.10.45.88.88.rec'
if ($filename =~ m|^/video/(?:%)*(.+?)/(\d{4,4})-(\d{2,2})-(\d{2,2})\.(\d+{2,2})\.(\d{2,2})\.(\d{2,2})|) {
  my $moviename = $1;
  my $year = $2;
  my $month = $3;
  my $day = $4;
  my $hour = $5;
  my $minute = $6;
  my $second = $7
}

Zur Erklärung der Regex: ^ passt auf den Anfang der Zeichenkette, d.h. vor /video/ darf nichts anderes kommen. Dann ist eine beliebige Zahl von %-Zeichen erlaubt ((?:%)*), gefolgt von einer Menge von (mindestens einem) beliebigen Zeichen (.+) bis zum nächsten "/". Diese Teilzeichenkette wird durch das Umschließen mit runden Klammern von Perl automatisch in der Variablen $1 hinterlegt. Nach dem "/" sollten dann genau vier Ziffern kommen, die wieder wegen der runden Klammern in $2 landen. Nach dem Minus kommen zwei genau zwei Ziffern, die in $3 landen usw. Da der "." ein Platzhalter für irgendein Zeichen ist, muss man den echten "." mit \. maskieren.
Mit sed geht ähnliches, bloß finde ich dessen Syntax ein bisschen krank, wenn man mal Perl verwendet hat.
Hope this helps,

Thorsten

Delaney · 14. Februar 2004

Moin,
Superidee ! Ich hatte mir aus ähnlichen Überlegungen heraus schon mal php_film-2.0.4 angesehen aber dann nicht die nötige Zeit gefunden ...

Die Idee sich die technischen Filminfos von vdrsync zu holen ist doch gar nicht so schlecht, einziger kleiner Nachteil, die werden erst beim Erstellen von z.B. DVD-Backups erzeugt. Aber wem erzähl ich das
Für Ungeduldige gäbe es ja auch noch vdrsync -i

Aber was ich bei einer Filmarchivdatenbank sehr begrüssen würde, wäre eine Möglichkeit CD/DVD-Label mit den Infos aus summary.vdr und passenden
Postscript-Templates (cdlabelgen) zu erzeugen.
Ein Abgleich mit imdb.de wäre zwar auch nicht schlecht, aber wohl nur manuell
und damit nicht mit dem VDR durchführbar.

Nur mal so als Idee ...

mfG

Saxman2k · 15. Februar 2004

Zitat

Original von Delaney
Aber was ich bei einer Filmarchivdatenbank sehr begrüssen würde, wäre eine Möglichkeit CD/DVD-Label mit den Infos aus summary.vdr und passenden
Postscript-Templates (cdlabelgen) zu erzeugen.

Wenn das Grundgerüst steht, darfst Du gerne ein paar Erweiterungen hinzufügen.

Saxman2k · 15. Februar 2004

sithmein
Danke für den kurzen Exkurs! Ich werde jetzt mal versuchen das Ganze umzusetzen. Deinen Vorschlag kann ich so wie er ist leider nicht benutzen, weil die folgende allgemeingültige Struktur für Aufnahmen gilt:

Code

/<videoverzeichnis>/<beliebig viele optionale Unterverzeichnisse>/<Titel der Aufnahme>/(<eventuell Untertitel>/)<Jahr>-<Monat>-<Tag>.<Stunde>.<Minute>.<Priorotät1>.<Priorität2>.rec

Bei mir sieht es etwas unkomplizierter aus, weil ich keine optionalen Unterverzeichnisse benutze. Aber wenn eine Aufnahme Titel und Untertitel hat (z. B. bei Enterprise), wird für den Untertitel ein weiteres Verzeichnis angelegt.
Mal schauen, ob ich da weiterkomme.

sithmein · 15. Februar 2004

Hi,

Also wenn der Teil bis zum Titel bekannt ist, dann ist der Untertitel kein Problem. Dann wendest Du einfach zwei regexen an, eine mit und eine ohne Untertitel:

Code

my $video = "/video/irgendwas/blabla/pieps";


if ($filename =~ m|^$video/(?:%)*(.+?)/(.+?)/(\d{4,4})-(\d{2,2})-(\d{2,2})\.(\d+{2,2})\.(\d{2,2})\.(\d{2,2})|) {
  my $moviename = $1;
  my $subtitle = $2;
  my $year = $3;
  my $month = $4;
  my $day = $5;
  my $hour = $6;
  my $minute = $7;
  my $second = $8;
} else if ($filename =~ m|^$video/(?:%)*(.+?)/(\d{4,4})-(\d{2,2})-(\d{2,2})\.(\d+{2,2})\.(\d{2,2})\.(\d{2,2})|) {
  my $moviename = $1;
  my $year = $2;
  my $month = $3;
  my $day = $4;
  my $hour = $5;
  my $minute = $6;
  my $second = $7;
}

Alles anzeigen

Bei der ersten Regex ist einfach noch ein zusätzliches /(.+?) dabei, dass einen evtl. vorhandenen Untertitel in $2 parkt. Ist kein Untertitel vorhanden, passt die erste Regex nicht auf den Dateinamen und die zweite kommt zu Anwendung. Wenn die Verzeichnisstruktur in $video allerdings beliebig ist, wird kompliziert. Ich kenne mich mit der VDR-Verzeichnisstruktur nicht so toll aus, aber kann sieht man dem Pfad irgendwie an, dass ein Untertitel dabei ist?

Grüße

Thorsten

Saxman2k · 16. Februar 2004

Guten Morgen!

sithmein
Erst mal Danke für die zweite Variante mit Untertitel. Das kann ich bestimmt sinnvoll nutzen.

Zitat

Original von sithmein
Ich kenne mich mit der VDR-Verzeichnisstruktur nicht so toll aus, aber kann sieht man dem Pfad irgendwie an, dass ein Untertitel dabei ist?

Leider nicht.
Die einzige Möglichkeit, die mir jetzt einfällt, ist, alle manuell angelegten Unterverzeichnisse in einer Konfigurationsdatei anzugeben. Alle anderen Verzeichnisse müssen dann Titel bzw. Untertitel sein.

@all
Ich habe gerade ein Problem mit der Filmlänge. Getestet hatte ich das mit Aufnahmen, wo irgendein alter Patch mal die Aufnahmelänge in der Datei len.vdr abgespeichert hat. Bei dem aktuellen recordinglength-Patch wird diese Datei nicht mehr angelegt, sondern die Länge der Aufnahme aus dem letzten Eintrag der index.vdr bestimmt. Ich habe mir die Datei auch mal zu gemüte geführt, habe aber nicht wirklich die Aufnahmelänge erkennen können.
Soweit ich weiß, werden dort alle Dateioffsets der I-Frames abgespeichert. Jetzt fehlt mir eigentlich nur die Größe eines solchen Index, damit ich weiß wo ich den letzten finden kann.

sithmein · 16. Februar 2004

Hi,

Sorry, ich habe gerade einen Syntaxfehler in meinem Perl-Code gefunden: In Perl schreibt man statt "else if" einfach nur "elsif". Sonst meckert der Compiler.

Grüße

Thorsten

mjohann · 16. Februar 2004

Darf ich mal ganz ketzerisch fragen, warum man für sowas eine SQL Datenbank braucht? Wieviele hunderttausend Aufnahmen möchte man denn verwalten? Und wieviele hundert Leute sollen denn gleichzeitig darauf zugreifen? Das alles lässt sich doch bequemst im Hauptspeicher halten.
Der Overhead, sowohl beim Zugriff über X APIs, als auch die Datenbank an sich ist, doch der totale Overkill. Nur weil es Cool ist eine SQL Datenbank am laufen zu haben, muss man das noch lange nicht für jede Anwendung benutzen.
Gerade mit objektorientierten Sprachen lassen sich solche Sachen elegant und schnell mit Hashes, Regex und serialisierung in CSV erschlagen. Weitaus leistungsfähiger und flexibler als mit jeder SQL Datenbank.
Und falls es ein offenes Projekt werden sollte, haben später die Leute nicht das Problem, dass sie erstmal umständlich eine Datenbank installieren müssen.
Das nur so als Anregung. Ich möchte keinem vorschreiben, wie er sein Projekt machen soll.

Saxman2k · 16. Februar 2004

Zitat

Original von mjohann
Darf ich mal ganz ketzerisch fragen, warum man für sowas eine SQL Datenbank braucht?

Aber natürlich. Das ist ein freies Land.

Zitat

Original von mjohann
Wieviele hunderttausend Aufnahmen möchte man denn verwalten? Und wieviele hundert Leute sollen denn gleichzeitig darauf zugreifen? Das alles lässt sich doch bequemst im Hauptspeicher halten.
Der Overhead, sowohl beim Zugriff über X APIs, als auch die Datenbank an sich ist, doch der totale Overkill. Nur weil es Cool ist eine SQL Datenbank am laufen zu haben, muss man das noch lange nicht für jede Anwendung benutzen.
Gerade mit objektorientierten Sprachen lassen sich solche Sachen elegant und schnell mit Hashes, Regex und serialisierung in CSV erschlagen. Weitaus leistungsfähiger und flexibler als mit jeder SQL Datenbank.
Und falls es ein offenes Projekt werden sollte, haben später die Leute nicht das Problem, dass sie erstmal umständlich eine Datenbank installieren müssen.

Was Du hier anmerkst ist alles einleuchtend und verständlich. Wie Du meinem ersten Posting entnehmen kannst, bin ich auch der Meinung, daß es etwas groß angelegt ist. Es ging mir hier jedoch erst mal um ein Konzept. Sprich wie komme ich alleine aus dem Pfad der Aufnahme an alle Informationen. Da ich auf der Arbeit viel mit PHP und MySQL arbeite hat sich mir hier erstmal diese Lösung angeboten. Dadurch brauche ich nicht extra eine andere Sprache lernen. Wenn es soweit läuft, darf gerne jemand mit Perl-oder-was-auch-immer-Kenntnissen die Sache überarbeiten. Ich bin der Letzte, der etwas dagegen hat.

Zitat

Original von mjohann
Das nur so als Anregung. Ich möchte keinem vorschreiben, wie er sein Projekt machen soll.

Anregung aufgenommen und auf ToDo geschrieben.

homolka · 16. Februar 2004

Tach Jungs,

habt Ihr den threat über das neue MP3/Media-Plugin im Hinterkopf. Hier sollen mit Hilfe einer SQLlite MP3s und später evtl. auch die Filme verwaltet werden. Da die Rede davon ist, Ansätze oder mehr auf dem usertreffen in Düsseldorf vorzustellen, ist das Ganze wohl auch schon ein wenig gediehen. Threat ist u.A. dieser hier.

Daniel

matrix79 · 23. Februar 2004

Zitat

Original von mjohann
Darf ich mal ganz ketzerisch fragen, warum man für sowas eine SQL Datenbank braucht? Wieviele hunderttausend Aufnahmen möchte man denn verwalten? Und wieviele hundert Leute sollen denn gleichzeitig darauf zugreifen? Das alles lässt sich doch bequemst im Hauptspeicher halten.
Der Overhead, sowohl beim Zugriff über X APIs, als auch die Datenbank an sich ist, doch der totale Overkill. Nur weil es Cool ist eine SQL Datenbank am laufen zu haben, muss man das noch lange nicht für jede Anwendung benutzen.

Du hast vielleicht recht, dass eine MySql Datenbank etwas zu überdeminsional ist. Aber dies schadet der Datenbank nicht.

Zitat

Gerade mit objektorientierten Sprachen lassen sich solche Sachen elegant und schnell mit Hashes, Regex und serialisierung in CSV erschlagen. Weitaus leistungsfähiger und flexibler als mit jeder SQL Datenbank.

Ich verstehe nicht warum du mit objektorientierten Sprachen leistungsfähiger sein willst als mit einer Datenbank die totale Overkill sein soll.

Zitat

Und falls es ein offenes Projekt werden sollte, haben später die Leute nicht das Problem, dass sie erstmal umständlich eine Datenbank installieren müssen.

Was soll den umständlich sein eine Datenbank zu installieren?
Die Tabellen kann man ganz einfach in jede Datenbank einfügen, ohne zu wissen, wie man Tabel erstellen kann und wie die Abhängigkeiten untereinander sind (wenn man mehrere Tabellen verwendet um Dublikate zu vermeiden).

Zitat

Das nur so als Anregung. Ich möchte keinem vorschreiben, wie er sein Projekt machen soll.

@all:
Mir ist aufgefallen, dass wenn man einige Aufnahmen mit einigen Unterordner hat, es schon mal einige Zeit daueren kann bis alle Aufnahmen im VDR unter "Aufnahmen" angezeigt werden.
Mit "ps ax" habe ich festgestellt, dass die Aufnahmen mit find erst gesucht werden.

Jetzt ist mir die Idee gekommen, man könnte doch die Aufnahmen aus einer Datenbank rausholen, dies würde nicht so lange dauern.
Oder man geht auf locate und updatedb, wobei dann beim herunterfahren eun ubdatedb ausgeführt werden sollte und im VDR der find Befehl durch locate ersetzt gehört.
Für dieses Problem fände ich updatedb sinvoller.

Gruß
matrix79

devnix · 23. Februar 2004

Zitat

Original von matrix79
@all:
Mir ist aufgefallen, dass wenn man einige Aufnahmen mit einigen Unterordner hat, es schon mal einige Zeit daueren kann bis alle Aufnahmen im VDR unter "Aufnahmen" angezeigt werden.
Mit "ps ax" habe ich festgestellt, dass die Aufnahmen mit find erst gesucht werden.

Jetzt ist mir die Idee gekommen, man könnte doch die Aufnahmen aus einer Datenbank rausholen, dies würde nicht so lange dauern.
Oder man geht auf locate und updatedb, wobei dann beim herunterfahren eun ubdatedb ausgeführt werden sollte und im VDR der find Befehl durch locate ersetzt gehört.
Für dieses Problem fände ich updatedb sinvoller.
matrix79

Alles anzeigen

sql datenbank klingt am einfachsten.
was spricht gegen diese?
ein kleiner vdr-client mit kleiner cpu und wenig ram!
aber hier ist ja dann ein server vorhanden dem z.b. mysql-server nicht weh tut.
der mysql client hat ca 64 kb, hat also sicher auch auf einem kleinen vdr platz.

ueber eine sql datenbank koennte man noch jede menge andere sachen (z.b. timer) verwalten. wie siehts da mit epg aus?
so koennte hoerzu oder tvtv plugin direkt auf die db schreiben.

ich denke an mysql, weil es am meisten verbreitet ist, und die leisungsfaehigkeit der datenbank hier ueberhaupt keine rolle spielt. jeder der ein bischen homepage proggt kann mit mysql etwas umgehen

per odbc bekommt man die daten auch ins (bitte jetzt nicht hauen) z.b. ins ms-excel

matrix79 · 23. Februar 2004

Zitat

Original von devnix

sql datenbank klingt am einfachsten.
was spricht gegen diese?
ein kleiner vdr-client mit kleiner cpu und wenig ram!
aber hier ist ja dann ein server vorhanden dem z.b. mysql-server nicht weh tut.
der mysql client hat ca 64 kb, hat also sicher auch auf einem kleinen vdr platz.

ueber eine sql datenbank koennte man noch jede menge andere sachen (z.b. timer) verwalten. wie siehts da mit epg aus?
so koennte hoerzu oder tvtv plugin direkt auf die db schreiben.

ich denke an mysql, weil es am meisten verbreitet ist, und die leisungsfaehigkeit der datenbank hier ueberhaupt keine rolle spielt. jeder der ein bischen homepage proggt kann mit mysql etwas umgehen

per odbc bekommt man die daten auch ins (bitte jetzt nicht hauen) z.b. ins ms-excel

Alles anzeigen

Ich bin nicht gegen eine MySql Dantenbank.
Aber in dem Beispiel wenn die Aufnahmen angeziegt werden sollen, ich nicht weis wie und wie aufwendig man den VDR Patchen müste, dass dieser die Aufnahmen in eine Datenbank eintragen kan, bzw auslesen kann, dachte es könnte einfacher sein den Befehl find durch locate ersetzen und beim shutdown ein updatedb durchführen lassen.
Ansonsten sehe ich eine MySql Datenbank sehr vom Vorteil, da ich selber nach bestimmten kriterien suchen kan.
Ich würde es begrüßen wenn jemand den VDR so Patchen kann, dass dieser in eine MySql Datenbank schreibt und lesen kann.

Gruß
matrix79

Saxman2k · 24. Februar 2004

Hallo zusammen!

Zumindest die Datenübernahme klappt jetzt. Für eine Web-Oberfläche hatte ich noch keine Zeit. Ich kann dazu jedoch PHPMyAdmin empfehlen.

Was zur Zeit abgespeichert wird:
- Titel
- Untertitel
- Beschreibung aus EPG
- Aufnahmedatum mit Uhrzeit
- Aufnahmelänge

Beim Thema Aufnahmelänge bin ich aber noch nicht zufrieden. Ich nehme jetzt den letzten eintrag in der marks.vdr. Das macht bei mit auch keine Probleme, da ich alle Aufnahmen erst schneide. Aber was ist, wenn keine Schnittmarken gesetzt sind? Dann würde die Aufnahmelänge nicht ermittelt.
Ich habe schon einige Zeit mit der index.vdr verbracht und bin zu dem Ergebnis gekommen, daß die dort abgespeicherten Frame Offsets keinen Rückschluß auf die Spieldauer ermöglichen. Die einzige Möglichkeit wäre dann jeden einzelnen Frame zu zählen, aber daß kann und will ich nicht implementieren. Der Zeitaufwand ist je nach Festplattengeschwindigkeit und Datenvolumen einfach zu hoch.
Bei einer etwa älteren Aufnahme habe ich noch eine len.vdr gefunden. Die wurde mal von einem etwas älteren Recording-Length-Patch angelegt und wäre für meinen Verwendungszweck ideal. Der Patch müßte in einen Komplettpatch enthalten gewesen sein, weil ich schon länger aus Bequemlichkeit den Komplettpatch einsetzt (hier noch mal vielen Dank an Dirk und all die anderen Komplettpatch-Bastler). Weiß jemand welcher Patch das war? Die Aufnahme ist von November 2003, also sollte der Patch zu dieser Zeit aktuell gewesen sein.
Weiß jemand zufällig, welchen Patch ich meine?

slime · 24. Februar 2004

hi,
die dateigröße der index.vdr ist proportional zur filmlänge in sekunden.
leider kann ich dir den genauen faktor nicht mehr sagen, aber vielleichti hilft da ja auch mal einfaches rumrechnen.

HFlor · 24. Februar 2004

Hallo,

in der index.vdr wird doch jeder Frame mit Typ gespeichert. Also ist die

Aufnahmelänge [sek] = Dateigröße [Byte] /8 [Byte/Frame] /25 [Frame/sek, bei Pal]

Hardy

Datenbankanbindung

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema