Caching des Aufnahmeverzeichnisses abschalten ?

versuch mal touch /video00/.update
das sollte helfen.

Gruss
- Cat -

Hi!

Einfachste und unsauberste Lösung: Ein at-Aufruf, der jede Minute "touch /video/.update" ausführt.

Oops ... da war jemand schneller ...

Gruß,
Brougs78

Ähm da hätte ich dann auch mal eine doofe Frage. Ist es bei euch auch so das der VDR in der startphase nicht ansprechbar ist wenn er die verzeichnisse scannt ? Bei mir dauert das nämlich schon recht lange und mich nervt das dann schon. Es wäre toll wenn das irgendwie im hintergrund passieren würde und der VDR trotzdem umschalten bzw. sich ansprechen liesse.

Gruss,

Jörg

*In den Tread werf*

Aufnahmen ueber (My)SQL verwalten?

Ich weis einige kratzen mir jetzt die Augen aus, und ich weis auch, dass hier wieder Probleme entstehen.

Aber ich denke mir der Aufwand lohnt in MultiVDR Umgebungen?

Also ich denke die meisten Leute konvertieren Ihre Aufnahmen ja früher oder später aber im Durchschnitt liegen 30-40 Aufnahmen als VDR Dateien vor. VDR sollte also meiner Meinung nach damit schon etwas schneller umgehen bzw. in dieser Zeit bedienbar bleiben können. Ob sich der Aufwand fiür eine Datenbank rechfertigt sei dahingestellt. Mir geht es nur darum das wenigstens 30-40 Aufnahmen ohne Wartezeiten eingescannt werden sollten. Evtl gibt es ja eine Möglichkeit den "nice level" ein wenig heraufzusetzen

Gruss,

Jörg

P.S.: Mitllerweile habe ich viele Aufnahmen im DIVX format und ich fände eine Datenbank für das mplayer plugin schon wesentlich hilfreicher. Aber ob das wirklich der VDR machen sollte ? Ich denke VDR sollte sich um Aufnahmen kümmern. So ist es wohl auch im Interesse von Klaus sonst hätte er nicht die plugins Schnittstelle erfunden

Zitat

Original von GTRDRIVER
Dies ist grundsätzlich zwar mehr als Lobenswert- funktioniert jedoch nur in einer Einzelplatzanwendung - spielen mehrer VDR´s (so wie bei mir) zusammen auf 1 /video00, so bemerken andere VDR´s neue Aufnahmen erst nach einem Neustart.
Axel

setzte den touch befehl in das record scriipt (das mit den before, after und edit ereignissen. bin in der arbeit, weiß den namen nicht genau) bei before rein. bei den vdrs, die nur aufnehmen.
dann brauchst du es nicht alle fünf minuten machen sondern nur wenn eine neue aufnehme hinzu kommt

obifrz

Zitat

Original von GTRDRIVER
Hallo

Also dass "JEDER" seine Aufnahmen kovertiert möchte ich an dieser Stelle mal stark bezweifeln !

Ich jedefnalls schneide die Aufnahmen - aber das war´s dann auch schon.

Hmm das Wort "JEDER" wurde nur von dir in diesem Thread benutzt. Aber schön das es auch Leute gibt die unendlich viel Festplattenplatz haben

Gruss,

Jörg

wie ich in dem Thread hier beschrieben habe, nervt mich dieses Verhalten auch.
Bei mir werden aber nur Aufnahmen von einem Client gelöscht. Die stehen dann immer noch in meinen Server im Aufnahmemenü, nur ohne Längenangabe. Wenn ich sie löschen will, gibt's einen "Fehler beim Löschen der Aufnahme". Ist ja auch weg. Nun könnte doch VDR (der Server) evtl. mal darauf hören, was ihm die Konsole beim Löschversuch so mitteilt und die Aufnahme auch aus seinem Gedächtnis löschen.

Müsste doch implementierbar sein, oder?!

Viele Grüsse
Chriss

hallo
theonlychriss

was hälst von meinem vorschlag
in das script vdrrecord
bei bevore)
touch /video0/.update
einfügen

obifrz

Hi!

Also ich halte den Vorschlag von obifrz am praktikabelesten; keine Änderung von VDR und würde das sicherlich ideal lösen.

Bin mir nicht sicher, aber ev. bräuchte man den Aufruf auch noch in Editted und deleted (weiß garnicht obs das gibt).

Gruß,
Brougs78

obifrz:

jaja, habe ich auch drin - ist aber nervig
Ich glaube, da muss ich wohl selber mal im src des VDR wühlen und mein Glück versuchen - wenn ich Zeit habe. Hoffentlich nicht mit dem Ergebnis wie's bei GTRDRIVER der Fall war

Gruss
Chriss

also ich wäre ja dafür das kls eine entsprechende option betreffs updaten der videoverzeichnisse in die erweiterten vdr-optionen einfügt.
damit wäre allen geholfen.
natürlich tun es auch die alternativen methoden aber sie erschweren doch unnötig die vdr-installation für die leute welche das einmalige scannen beim vdr-start nachteilig ist.

Zitat

Original von SledgE
also ich wäre ja dafür das kls eine entsprechende option betreffs updaten der videoverzeichnisse in die erweiterten vdr-optionen einfügt.
damit wäre allen geholfen.
natürlich tun es auch die alternativen methoden aber sie erschweren doch unnötig die vdr-installation für die leute welche das einmalige scannen beim vdr-start nachteilig ist.

Ja so sehe ich das leider auch. Denn ich bin leider Alpha und Beta tester und dann startet man schon öfter den VDR

Zzt. behelfe ich mir mit einer 2. Installation die auf ein eigenes video verzeichnis zugreift aber dann kann ich nicht die Aufnahmen abspielen. Ist also ein wenig zeitaufwendig das ganze. (Wenn man so viele aufnahmen hat wie ich )

Gruss,

Jörg

Zitat

Originally posted by devnix
*In den Tread werf*

Aufnahmen ueber (My)SQL verwalten?

Ich weis einige kratzen mir jetzt die Augen aus, und ich weis auch, dass hier wieder Probleme entstehen.

Aber ich denke mir der Aufwand lohnt in MultiVDR Umgebungen?

Alles anzeigen

*hinterher werf*
Ne 'Datenbank' für Arme wäre evtl. auch ein XML-File. Der VDR hält sich im Speicher die Struktur mit der Übersicht der Aufnahmen und kann diese einfach beim Beenden als XML-Datei wegschreiben. Beim Start kann diese dann wieder eingelesen werden.
Ich weiss nicht, ob schon irgendwas im VDR mit XML gelöst ist, aber wenn mans einmal benutzt hat sieht man die ganzen Vorteile.
Gruß
Jarny

Die Sache mit XML sehe ich wieder zu local, nicht optimal fuer Multiuser (client)
Bei SQL uebenimmt der Server die Datenbankfunktionen, sprich, der Client hat hier kaum CPU/Ram last. Warum sollte man z.B. einen 200 Mhz Client mit XML belasten? Es reicht wenn er ein "Select name from aufnahmen where..." absetzt, den Rest macht der Server, der ja, unabhaengig von VDR selbst, irgendwo im Netzwerk liegen kann.

Ausserdem muss man die XML Datei dann wieder zentral im Netzwerk bereithalten. Und wie laeuft das Locking? Wenn z.B. 2 Clients gleichzeitig aufzeichen?

Ich sehs mit SQL deutlich einfacher als mit XML.

ein:

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

schreibt mir jetzt schon jede Aufnahmen auf MySQL.

Zitat

Originally posted by devnix
Die Sache mit XML sehe ich wieder zu local, nicht optimal fuer Multiuser (client)
Bei SQL uebenimmt der Server die Datenbankfunktionen, sprich, der Client hat hier kaum CPU/Ram last. Warum sollte man z.B. einen 200 Mhz Client mit XML belasten? Es reicht wenn er ein "Select name from aufnahmen where..." absetzt, den Rest macht der Server, der ja, unabhaengig von VDR selbst, irgendwo im Netzwerk liegen kann.

Ausserdem muss man die XML Datei dann wieder zentral im Netzwerk bereithalten. Und wie laeuft das Locking? Wenn z.B. 2 Clients gleichzeitig aufzeichen?

Ich sehs mit SQL deutlich einfacher als mit XML.

ein:

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

schreibt mir jetzt schon jede Aufnahmen auf MySQL.

Alles anzeigen

Ja, ich weiss, das Problem mit dem verteilten VDRs wird dadurch nicht gelöst. Das XML sollte lediglich das Scannen am Anfang auf ein paar Millisekunden (auch auf ner 200MHz-Maschine, glaub mir) verkürzen.
Das Locking ist natürlich ein Problem wenn man VDR-Clustering betreibt. Elegant kann man sowas dann nur mit ner Datenbank lösen. Aber wieviele VDR-User haben mehrere Aufnahmemaschinen in einem Netzwerk? Das klingt nach 'VDR-Professional' und ist imho höchstens für ne absolute Minderheit relevant (sonst wärs bestimmt schon gelöst).
Gruß
Jarny

PS: MySQL auf den VDR zu installieren ist anscheinend nicht das große Problem. Um das muggle-Plugin zu nutzen braucht man die sowieso. Evtl. gibts in Zukunft noch mehr Plugins die ne Datenbank benötigen. Wenns nich ne zusätzliche Fehlerquelle wäre würd ichs begrüßen, wenn MySQL standardmäßig mit dem VDR auf dem Rechner landet. Da könnte man einiges mit zaubern.