Für das restfulapi Plugin habe ich LengthInSeconds zum 1.6er VDR backgeportet damit das Plugin auch unter dem 1.6er läuft (wäre zuviel Aufwand gewesen das Plugin umzubauen): https://bugs.yavdr.com/project…engthInSeconds-Patch.diff
Diesen Patch sollte man auch laicht auf den alten 1.7er anpassen können (sollte sich dort auch leicht einpflegen lassen können).
cu
Hi,
habe nun herausgefunden, dass bei mir metadata.db unter /var/vdr/metadata.db abgelegt wird. Finde ich eigentlich OK. Mein Problem nur, die Festplatte ist andauernd leicht am Roedeln (aber lautlos), die LED geht nie aus, und alle paar Stunden (oder auch nur eine) pfeift die HDD und macht einen Klack, aber mit smartmontools sind keine Fehler zu erkennen. Nun gut, ich hoffe das sie keinen Schaden nimmt, aber etwas ist da doch nicht ganz in Ordnung. Bei mir ist der Log voller
vdr: [16731] UPnP Unable to save the metadata of 'rec://0_Music/0_3sat_PatC/Pink_Floyd#3A_Pulse/2007-05-01.23.40.99.99.rec'solcher Eintraege, das sind denke ich alles PES Aufnahmen, ich kann ja verstehen dass die Probleme machen, auch dass sie den Log ueberschwemmen, aber vielleicht sollte metadata.db nicht andauernd niedergeschrieben werden, vor allem wenn dieses Parsen fehl schlaegt...
Ein weiteres Problem welches ich anmerken wollte, ist dass ich weder mit XBMC, noch mit VLC etwas vom Plugin streamen kann. Beide finden den Server (XBMC laeuft auf der gleichen Kiste, VLC auf einem Laptop), in XBMC kann ich nur Aufnahmen browsen, und von denen auch nur einen Teil (vermutlich ist die Liste bei mir nie komplett, wegen den Problemen die bei mir ewig geloggt werden), bei LiveTV komme ich gar nicht hereien. Die Aufnahmen die ich browsen kann, kann ich aber nicht abspielen (XBMC vom git). Bei VLC habe ich so wie Du (methodus) beschrieben hast, nach dem Server gesucht, er wird auh gefunden, aber mehr verzweigt sich da nichts (in Aufnahmen und LiveTV etwa).
Ich könnte maximal versuchen die Datenbank temporär zu machen und nur beim Herunterfahren des VDR werden die Änderungen in die DB geschrieben. Dann würde alles im RAM ablaufen. Die Datenbank sollte selten mehr als ein paar MB groß werden, so dass die auch locker im RAM platz finden dürfte. Problematisch ist lediglich, wenn der VDR unkontrolliert beendet wird und die Änderungen nicht gespeichert werden konnten.
Das einfachste wäre es wenn der Nutzer sie per Kommandozeilenparameter auf ne RAM Disk setzt und dann nach dem VDR Ende nach /var/... sichert.
Das machen die meisten mit den anderen Datenbanken (epg.data des VDR, epg.db von xmltv2vdr usw.) ja auch so.
cu
Zu XBMC und VLC: Das verstehe ich nicht. Beide funktionieren hier tadellos. Kannst du mit Wireshark umgehen und mir mal die Kommunikation zwischen den beiden tracen? Ich brauch eigentlich nur alles ab dem GET-Request zum Server und die passende Antwort.
Das wird 'ne aufwaendigere Geschichte, wenn noetig, dann werde ich mal am Abend versuchen mich da schlau zu machen...
Hast du für Live-TV die externremux für Streamdev angepasst, dass die richtigen Header gesendet werden? Ich werde sie vielleicht mit einchecken, aber letztlich gehört sie zu Streamdev. Die für mich aktuell funktionierende externremux.sh findest du hier: http://projects.vdr-developer.org/attach…/externremux.sh
Ich Dusel hatte das vergessen, und nun aber nachgeholt, es bringt im Endeffekt doch keine Besserung. Deine Version des Skripts gehoert definitiv upstream (zu streamdev), das sollten wir veranlassen...
in aktuelles log vom Plugin könnt auch nicht schaden.
Log vom Plugin waehrend VLC versucht etwas zu browsen , und Log von XBMC
Das einfachste wäre es wenn der Nutzer sie per Kommandozeilenparameter auf ne RAM Disk setzt und dann nach dem VDR Ende nach /var/... sichert.
Das machen die meisten mit den anderen Datenbanken (epg.data des VDR, epg.db von xmltv2vdr usw.) ja auch so.
cu
Done. Habs grad eingecheckt. Wenn du magst, kannst du es mal testen. Ich habe auch den SegFault error gefixt, wenn die Datenbank nicht geöffnet werden konnte.
Ich Dusel hatte das vergessen, und nun aber nachgeholt, es bringt im Endeffekt doch keine Besserung. Deine Version des Skripts gehoert definitiv upstream (zu streamdev), das sollten wir veranlassen...
Da bin ich schon im Kontakt mit schmirl. Er hat auch einen Patch für die HEAD-Methode bereitgestellt, die es erlaubt eigene Header bei HEAD-Requests über externremux.sh zu setzen. Aber ich glaub, ich hab ihm noch nicht bescheid gesagt, dass der Patch funktioniert... hmm.. 
Danke für den freundlichen Reminder.
Logs guck ich mir heut abend an.
... oder auf Deiner Dev-Kiste, methodus? Hier gibt es bereits commits von morgen (also heute nach Mitternacht) ?
Ich entwickle in einer VMWare Player-VM, dort spinnt die Uhrzeit teilweise mehrere Studen. Ich hab NTP schon eingeschaltet, aber das wird nur unregelmäßig aktualisiert. Manuell nachstellen bringt auch nix, weil spätestens nach dem nächsten Neustart der VM stimmt die Uhr wieder nicht. Jetzt grad stimmt sie
Ich entwickle in einer VMWare Player-VM, dort spinnt die Uhrzeit teilweise mehrere Studen. Ich hab NTP schon eingeschaltet, aber das wird nur unregelmäßig aktualisiert. Manuell nachstellen bringt auch nix, weil spätestens nach dem nächsten Neustart der VM stimmt die Uhr wieder nicht. Jetzt grad stimmt sie
Ha! Mir kam es schon seit 2-3 Tagen glaube ich, komisch vor, und nun nach der Zeitumstellung letzte Nacht war ich erst recht wirklich verunsichert, spinnt mein Browser, mein Rechner. Tja, ich habe auch auf der Arbeit um so eine Entwicklerumgebung startklar mit altem VS 6.0 und Sourcen des Produktes zu sichern, VMware Player genommen, danach tat es mir leid nicht doch Virtualbox genommen zu haben...
Evtl. wäre ja eine kleine Sicherheitsreserve gut? D.h. nur runterfahren erlauben wenn innerhalb der letzten 2 Minuten kein Client irgendwas angefordert hat. Dann fährt der VDR nicht runter wenn man sich in der (gerade angeforderten) Dateiliste den Film aussucht 
Oder gibts keine Anforderung (d.h. irgendeine Art der Kommunikation mit dem Server) wenn der Nutzer am DLNA Client die Liste aufruft?
cu
Bei mir (MLD 3.0.1 = VDR 1.7.31 mit UPnP 0.0.2) ist es jedenfalls so, wenn das UPnP-Plugin installiert ist, wird das Herunterfahren des Rechners abgebrochen, weil "UPnP Server is still running". Das passiert auch, wenn in den Plugin-Einstellungen "Enable UPnP Server" auf "disabled" steht. Ich weiß jedoch nicht, ob das Unterbinden vom Plugin, der MLD oder wo sonst her kommt. Wäre jedoch schön, wenn das geändert werden könnte.
Viele Grüße skippy
Das ist ein Bug, den ich schon behoben habe. Das obige würde sich dann tatsächlich nur auf aktive Streams auswirken (theoretisch ).
Das "Session-Timeout" klingt interessant. Ich überlege mir mal was (...und macht ein Ticket dafür auf).
Danke für die Super Tipps, Jungs!
Selbst bei 12.04 sind die libs zu alt. Ich habe dann die von YaVDR genommen, da ich darüber auch live und streamdev installiert habe. Bei live ist ebenfalls eine sehr aktuelle Version notwendig.
Ja, ich hatte nicht erwähnt, dass ich mich noch ein Stündchen damit herumgeschlagen hatte, live mit der neuen tntnet ans Laufen zu kriegen. Jetzt habe ich die aktuelle Entwicklerversion aus Git statt der 0.2 und gut ist.
Die Probleme mit tntdb scheinen sich irgendwie zu häufen. War wohl ein riesen Fehler die lib zu verwenden.
Och, die meisten werden ja wohl ein fertiges Paket nehmen. Allerdings wäre es da schon nützlich, wenn es eine Version ist, die bei gängigen Distributionen mitgeliefert wird. Und live sollte da auch mitspielen...
(Als Programmierer kann ich allerdings die Begeisterung für eingebettete SQL Server nicht so ganz nachvollziehen. So was wie Berkeley DB hätte es nicht getan? Aber gut, ist deine Entscheidung und das Plugin sieht vielversprechend aus.)
Erkenntnisse, die ich leider nicht teilen kann, weil ich fertige Pakete nutze
./configure; make; sudo make install. Mehr gibt die Installationsanleitung von tntnet leider nicht her. Händisch muss man dann ldconfig ausführen und tntnet-config ins bin Verzeichnis befördern. Das steht in keiner Anleitung. Ich sollte bei Gelegenheit mal den Autor darauf stossen. Bei fertigen Paketen ist das aber kein Thema.
Das Plugin muss seine Datenbank irgendwo schreibbar ablegen können, da darin die Metadaten verwaltet werden. Wenn /etc/vdr/plugins nicht schreibbar ist, es aber ein anderes Verzeichnis gibt, welches vom VDR für Schreibzugriffe genutzt werden kann, kann in der setup.conf die Zeile upnp.databaseFile eingefügt bzw. angepasst werden. Das angegebene Verzeichnis muss absolut sein, sonst legt das Plugin die Datei relativ zum Ausführverzeichnis des VDRs an, was bei vielen "/" war.
Alles klar. Wäre schön, gleich im Plugin zu prüfen, ob die Datei schreibbar ist, anstatt mit einem segmentation fault o.ä. abzuschmieren.
Okay, is'n Bug wegen zu neuer VDR-Version. Ich wühl mich mal durch die VDR-History und bau eine Alternative ein.
Mach dir da mal nicht zu viel Arbeit. Entweder portiere ich den einen Patch auf meinen VDR oder hole mir die aktuelle Version. Ist halt nur unsere einzige Möglichkeit fernzuschauen, daher fummele ich da nur selten dran rum.
Ungeklärt ist noch, warum meine UPnP Clients den Server finden, aber keine Medien. Fehlermeldungen o.ä. habe ich keine.
Ungeklärt ist noch, warum meine UPnP Clients den Server finden, aber keine Medien. Fehlermeldungen o.ä. habe ich keine.
Ist bei mir aehnlich, XBMC kann einige der Aufnahmen finden, aber nicht abspielen, und VLC kriegt den Aufnahmen-Baum nicht auf, das kleine "+" Icon in der Medienliste verschwindet und taucht auf im Sekundentakt, mit etwas Glueck klicke ich darauf und der Tree versucht auf zu gehen aber schliesst sich sofort, und am VDR-Server ist der vdr Prozess mit 109% am dual-core Athlon zu gange. Andere clients, etwa in modernerer consumer electronics haben wir (noch) nicht, vielleicht ausser dem Android-Phone meiner Frau, werde ich mal bei Gelegenheit suchen...
Ich glaube, ich weiß woran das liegt. Bin mir aber noch nicht sicher. Ich vermute, dass der Prozess zum aktualisieren der Datenbank einfach viiiiiiiiiiel zu häufig noch aufgerufen wird. Könnt ihr mal bitte jeweils im recProvider und vdrProvider in der Action-Methode, den sleep drastisch vergrößern? So auf etwa 10 Minuten (600). Wenn das geht, muss ich mir doch nochmal den Job ansehen. Eventuell beseitigt das noch andere Bugs.
Habe ich gerade ausprobiert, merke aber keine Auswirkungen auf die CPU-Auslastung.
PS: neues und vorerst finales Makefile ist eingecheckt. Danke an zoolook für die Hilfe. Wenn was nicht geht: er wars! *gg*
edit:
PPS: ich hab git add mit den neu dazugekommenen Dateien vergessen, weshalb das Plugin aktuell nicht baut. Ich fix das heute abend.
Bis dahin kann man sich noch damit behelfen.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
