Macht es Sinn die Datenbank über den VDR Start aufzuheben?
BTW: Wenn ich das nicht komplett falsch in Erinnerung habe ist das Resource-Verzeichnis für statische Resourcen (Bitmaps oder ähnliches), evtl. sogar Read only auf einigen Systemen.
BTW2: Die Datenbank rödelt doch ziemlich heftig auf der HDD rum (vermutlich das dauernde hintergrund Kanalistenupdate), es wäre doch schön wenn man sie auf ne Ramdisk legen könnte.
cu
Macht es Sinn die Datenbank über den VDR Start aufzuheben?
Das macht dann Sinn, wenn man zusätzliche Metainformationen zu einer Resource angeben möchte. Andere Server machen es ähnlich. Für die Daten, die der VDR anbietet, mag das etwas overkilled zu sein, aber die Ansätze über Virtual Tables haben mir einige Probleme bereitet, so dass ich davon wieder abgewichen bin.
BTW: Wenn ich das nicht komplett falsch in Erinnerung habe ist das Resource-Verzeichnis für statische Resourcen (Bitmaps oder ähnliches), evtl. sogar Read only auf einigen Systemen.
Oha... die plugins.html sagt dazu nicht wirklich was. Ich hab dazu im FHS-Thread gelesen, aber nicht alles und hab auch den konkreten Ausgang nicht verfolgt. Wenn dem so ist, dass ResourceDirectory für solche Sachen nicht genutzt werden kann/darf, nehm ich das zurück.
BTW2: Die Datenbank rödelt doch ziemlich heftig auf der HDD rum (vermutlich das dauernde hintergrund Kanalistenupdate), es wäre doch schön wenn man sie auf ne Ramdisk legen könnte.
Da bin ich noch am Optimieren, weil bei vielen Kanälen auch viel aktualisiert wird, aber in den wenigsten Fällen betrifft das die aktuellen EPG-Infos. Am meisten rödelt bei mir aber der recProvider, weil folgende Zeile ständig true liefert:
if(Recordings.NeedsUpdate() || Recordings.StateChanged(state)){
OnContainerUpdate(GetRootContainer(), GetContainerUpdateId(GetRootContainer()));
}Ich hab aktuell noch bewusst auf inotify verzichtet, da mir nox mitgeteilt hat, dass inotify auf FreeBSD nicht verfügbar ist. Es gibt Alternativen, aber das hebe ich mir für die anderen DLNA-Provider auf.
Oha... die plugins.html sagt dazu nicht wirklich was. Ich hab dazu im FHS-Thread gelesen, aber nicht alles und hab auch den konkreten Ausgang nicht verfolgt. Wenn dem so ist, dass ResourceDirectory für solche Sachen nicht genutzt werden kann/darf, nehm ich das zurück.
Also garantieren kann ich das nicht, ich hats nur so verstanden. Es gibt ja Config, Cache und Resource. Und von der Benennung klingt es IMHO sinnig das ne Datenbank nach Config gehört. Zumindest solange es nix passenderes gibt (weil so wirklich Config ist es ja auch nicht) 
Evtl. ja auch Cache, wobei hier die Vereinbarung fehlt ob Cache den VDR Start/Reboot überlebt oder nicht. Wenn eine Distribution das so und die andere macht wirds ja irgendwie kompliziert
Resourcen sind ja ganz klassisch alle möglichen statischen Daten (Also RO) die von Programmen so benötigt werden. z.B. die "upnpIcon*.jpeg|png".
cu
Naja, dem User hilfts Macht das Backup ja einfacher, ich lasse mir z.B. die Config 1x täglich ins GIT einchecken (einfach automatisch komplett alles im Config Dir), da wäre es ja nervig haufenweise statischen Kram (ca. 30 MB) und temporäre Sachen (die würden das GIT ja extrem aufblähen) drin zu haben.
Die binäre DB im Config Dir passt mir persönlich da natürlich auch nicht ins Konzept, aber die werde ich mir dann schon weg patchen.
cu
Einfach eine Zeile in die Konfiguration und die Datenbank wird dort hingegelegt, wo du sie haben möchtest. Basta 
Nix Patch!
Anyway. Hat mal jemand eine Radioaufnahme, die ich mir ansehen könnte? Ich hab zwar SAT, aber alle Radiostationen gefiltert und möchte meine Channels.conf auf meinem Produktivsystem nicht wegen einer Radiostation verhunzen. Via DVB-T bekomme ich kein Radio. Theoretisch gibt es AAC und MP2-Profile für Audio. Ob die passen und auf den DLNA-Player abgespielt werden, ist fraglich. Aber es würden erstmal die Fehlermeldungen aus dem Log verschwinden.
Funktioniert inzwischen bei jemanden das Plugin?
hallo zusammen,
auf meinem Testserver (Ubuntu 12.04.1 LTS, vdr 1.7.31) kann ich das Plugin nicht kompilieren.
Es kommt der Fehler:
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"upnp"' -DPLUGINDIR=\"/usr/local/src/vdr/PLUGINS/lib\" -I/include -I../../../include -o httptnt/deviceDescription.o httptnt/deviceDescription.cpp
/usr/include/tnt/component.h:49:22: Fehler: »virtual unsigned int tnt::Component::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&, bool)« war versteckt [-Werror=overloaded-virtual]
httptnt/deviceDescription.ecpp:34:14: Fehler: von »virtual unsigned int {anonymous}::_component_::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&)« [-Werror=overloaded-virtual]
cc1plus: some warnings being treated as errors
make: *** [httptnt/deviceDescription.o] Fehler 1
rm httptnt/deviceDescription.cpp
Hatte jemand diesen Fehler?
Danke, Wolfgang
Hi, mein aktueller Patch an den Makefiles laesst sich in einer einzigen Datei Make.config gemeinsam konfigurieren, und die spezifischen Sachen sind zum einen auf Makefile fuer das Haupt-Plugin und optionalem Aufruf der Sub-Plugin Targets, und auf Makefile.plugins fuer die Subplugins aufgeteilt. In den Einzelnen Sub-plugins Verzeichnissen haben sich die Makefiles stark reduziert. Ich habe auch eine spaerliche INSTALL-Datei hinzugefuegt, welche erklaert wie man mit den neuen Makefiles auch installieren / deinstallieren kann, wobei zu beachten ist, das Hauptplugin sollte immer vorher im Zielverzeichnis installiert sein.
Zur Funktionalitaet des Plugins:
Bei mir ist nun der VDR UPnP/DLNA Server in XBMC sichtbar, ich kann auch die TS-Aufnahmen durchbrowsen, nur abspielen geht noch nicht, vielleicht ist noch nicht alles konfiguriert, werde morgen mal in Logs gucken usw.
P.S. Habe ich etwa vergessen zu erwaehnen, dass ich fuer Gentoo ebuilds gebaut habe? bei Interesse einfach im overlay in meiner Signatur gucken, es gibt
media-plugins/vdr-upnp-9999
media-plugins/vdr-upnp-subplugins-9999Es reicht eines davon zu emergen, egal welches, es zieht das andere ueber DEPEND, bzw andersrum PDEPEND nach sich mit 'rein und werden von den gleichen Sourcen gebaut.
Habe mal gerade sources upgedatet und neu compiliert, beim Start bekomme ich dann:
Oct 27 13:30:08 gentoo64 vdr: [6979] UPnP Initializing UPnP media server on 192.168.2.110:0
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Initialising webserver
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Using /usr/local/vdr/config1731/plugins/upnp/httpdocs/ for static content delivery.
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Initialising media manager
Oct 27 13:30:09 gentoo64 vdr: [6979] UPNP Preparing database structure...
Oct 27 13:30:09 gentoo64 vdr: [6979] UPNP Loading Plugins...
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Error while opening plugin: ../../../../../lib/libvdr-upnp.so.1.7.31: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Error while opening plugin: ../../../../../lib/libvdr-upnp.so.1.7.31: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Error while opening plugin: ../../../../../lib/libvdr-upnp.so.1.7.31: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Found 0 plugins
Oct 27 13:30:09 gentoo64 vdr: [6979] UPnP Scanning directories...Du musst die relativen Pfade im Makefile gegen absolute tauschen.
PLUGINLIBDIR im Makefile sollte eigentlich auch überflüssig sein. Die lib kann ja auch selber rausfinden wo sie selber liegt. Diese ganzen absoluten Pfade sogen auch für ziemliche Probleme.
Aber erst mal abwarten wie das mit den neuen Makefiles wird. Da wird sich ja dann wohl einiges ändern.
cu
Hi, mein aktueller Patch an den Makefiles laesst sich in einer einzigen Datei Make.config gemeinsam konfigurieren, und die spezifischen Sachen sind zum einen auf Makefile fuer das Haupt-Plugin und optionalem Aufruf der Sub-Plugin Targets, und auf Makefile.plugins fuer die Subplugins aufgeteilt. In den Einzelnen Sub-plugins Verzeichnissen haben sich die Makefiles stark reduziert. Ich habe auch eine spaerliche INSTALL-Datei hinzugefuegt, welche erklaert wie man mit den neuen Makefiles auch installieren / deinstallieren kann, wobei zu beachten ist, das Hauptplugin sollte immer vorher im Zielverzeichnis installiert sein.
Okay, ich habe deinen Patch ohne irgendwelche Anpassungen mal auf meine Sourcen angewendet, was auch geklappt hat. Ich hätte aber trotzdem noch ein paar Sachen...
Hi,
wozu ist install eigentlich notwendig. Im Normalfall werden die Plugins ja nach LIBDIR (../../lib) kopiert, die man dann überladen könnte.
Nun, install is so eine Art aufgemotztes cp, kommt mit sys-apps/coreutils und wird generell beim Installieren von binaries, egal nun ob DLLs oder executables genommen, weil es so Sachen wie Quelle mit Ziel falls vorhanden sogar binaer zu vergleichen und nur bei Nicht-Gleichheit die neue Version zu kopiren, Rechte zu vergeben, und am interessantesten wohl das Strippen der Debug-Symbole (-s Switch welches ich in den Makefiles extra leicht abschaltbar gemacht habe, da bei Gentoo falls Debug-Symbole doch gewuenscht werden diese nicht mehr beim Paketmanager ankommen wuerden, der diese gesondert im Dateisystem ablegen wuerde und deswegen selber strippt).
Warum werden beim install die Verzeichnisse für config und resource angelegt? Das ist doch aufgabe des VDR bei dessen Installation? Würde ich mich da nicht in die Angelegenheiten des VDR reinhängen?
Na es sind die entsprechenden Unterverzeichnisse nur fuer das Plugin welches in frage kommt, VDR kann nicht vorher wissen dass irgendwann ein Plugin "upnp" kommt, um dafuer unter /etc/vdr/plugins ein Verzeichnis mit passendem Namen zu erstellen. Analog fuer Ressourcen, wobei mir noch nicht klar ist ob upnp letzlich welche hat, dass sollst Du als Autor designen/entscheiden.
Aufgrund des Vorschlags, die Sub-Plugins auf die gleiche Ebene wie das Hauptplugin zu bringen, wird das UPNP-Plugin-Verzeichnis obsolete. Das macht die Verzeichnisstruktur einfacher. Das böse Plugin macht das wohl auch so.
Soll mir recht sein. Btw, den Makefile-Mechanismus habe ich wie fuer Manche relativ leicht zu erkennen ist beim erwaehnten Plugin stibitzt.
Ich hab bei mir LIBDIR = . gesetzt, so dass das UPnP-Plugin in das aktuelle Verzeichnis kopiert wird. Wenn ich die Subplugins bauen und linken möchte, hab ich ja dann den absoluten Pfad in meine Entwicklungsumgebung. Kann ich dann die *.so dann noch nach /usr/lib/vdr/plugins kopieren?
Ich denke dann knallt's, weil Deine subplugins leider gegen libvdr-upnp.so.1.7.31 linken muessen, wieder wissen sie dann nicht woher. Das zitierte Plugin mit dem oh, uns allen im Hals stecken bleibenden Namen hat dieses Problem nicht (habe mir mal dem seine "subplugins" mit ldd angeguckt, die sind nicht gegen das Hauptplugin gelinkt.
Was mich ein bisschen verwundert, warum brauchen Deine subplugins auch noch dlopen auf die DLL gegen die sie linken? Ist wahrscheinlich bei gcc/Linux so, jedenfalls wenn Du daraus implizite Aufrufe brauchst, kommst wohl ans Linken nicht vorbei.
Gruss,
Lucian
Ich habe das Plugin auf meinen VDR losgelassen (1.7.18, Ubuntu Natty). Startet auch nach einigem hin und her. Allerdings finden meine UPnP Clients bisher keine Medien zum Abspielen.
Aber hier erst mal ein paar Beobachtungen, die ich während der Installation gemacht habe:
1. libtnt...(-dev) und libcxx per apt purge entfernt, weil die Ubuntu Natty Versionen zu alt waren.
2. Händisch die neuesten tntnet Bibliotheken gesaugt, gebaut und nach /usr/local installiert.
3. Mich am Kopf gekratzt, warum libtntdb nicht sauber kompilierte und auch nachdem ich LD_LIBRARY_PATH gesetzt hatte, wurden Bibliotheken nicht gefunden. Nach diversem hin und her bin ich schliesslich auf ldconfig gestossen, danach fluppte es.
4. vdr-plugin-upnp gepullt und kompiliert. Das wollte erst nicht, weil tntnet-config nicht installiert worden ist; das musste ich händisch von den tntnet Sourcen nach /usr/local/bin befördern.
5. libvdr-upnp in meine VDR_LIB kopiert und VDR gestartet.
6. Mich gewundert, was mir diese Fehlermeldung im VDR Log sagen will: "basic_string::_S_construct NULL not valid". Vermutlich mochte das Plugin nicht, dass ich kein Konfigurationsverzeichnis unter /etc/vdr/plugins angelegt hatte.
7. Nach diversem Googeln bin ich auf dieses Thema und das Projektwiki gestossen. Wäre nett, wenn man hier http://vdr-wiki.de/wiki/index.php/Upnp-plugin dick und fett darauf hinweisen könnte, dass die Anweisungen veraltet sind und auf das Projektwiki linken.
8. /etc/vdr/plugins/upnp angelegt, httpdocs dorthin kopiert, libupnp-vdr-provider.so gebaut und dorthin kopiert. Wäre übrigens auch interessant zu wissen, was diese Subplugins überhaupt tun. Ich habe von DLNA und UPnP keine Ahnung, ich weiss nur, dass ich auf mein Android Handy keine Verzeichnisse mit SSH mounten kann/will.
9. VDR gestartet und mich über einen fetten Stacktrace gefreut. /etc/vdr/plugins/upnp für VDR schreibbar gemacht, danach ging es. Offenbar mag es das SQLite Ding von libtntdb gar nicht, wenn es nicht in das upnp Plugin Verzeichnis schreiben kann.
Ach ja, das vdrDVBProfiler Plugin will bei mir nicht kompilieren:
vdr-1.7.18/PLUGINS/src/vdr-plugin-upnp/plugins/profiler/vdrDVBProfiler$ make
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I../../../include -I../../../../../../include -o dvbProfiler.o dvbProfiler.cpp
dvbProfiler.cpp: In member function âbool upnp::DVBProfiler::GetRecordingMetadata(const std::string&, upnp::cMetadata&)â:
dvbProfiler.cpp:152:19: error: âclass cRecordingâ has no member named âLengthInSecondsâ
dvbProfiler.cpp:153:89: error: âclass cRecordingâ has no member named âLengthInSecondsâ
make: *** [dvbProfiler.o] Error 1Insgesamt bin ich jedenfalls guter Hoffnung. BubbleUPnP und MediaHouse auf meinem Android und der Windows Media Player finden den VDR Server. Nur Medien wollen sie bisher keine finden.
Ach ja, das vdrDVBProfiler Plugin will bei mir nicht kompilieren:
VDR zu alt. Die Funktion (LengthInSeconds) kam erst später.
cu
1. libtnt...(-dev) und libcxx per apt purge entfernt, weil die Ubuntu Natty Versionen zu alt waren.
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.
3. Mich am Kopf gekratzt, warum libtntdb nicht sauber kompilierte und auch nachdem ich LD_LIBRARY_PATH gesetzt hatte, wurden Bibliotheken nicht gefunden. Nach diversem hin und her bin ich schliesslich auf ldconfig gestossen, danach fluppte es.
Die Probleme mit tntdb scheinen sich irgendwie zu häufen. War wohl ein riesen Fehler die lib zu verwenden.
4. vdr-plugin-upnp gepullt und kompiliert. Das wollte erst nicht, weil tntnet-config nicht installiert worden ist; das musste ich händisch von den tntnet Sourcen nach /usr/local/bin befördern.
Erkenntnisse, die ich leider nicht teilen kann, weil ich fertige Pakete nutze Wenn es eine Installationsanleitung für tntnet gibt, könnte ich die im Wiki verlinken. Wie hast du das gemacht?
6. Mich gewundert, was mir diese Fehlermeldung im VDR Log sagen will: "basic_string::_S_construct NULL not valid". Vermutlich mochte das Plugin nicht, dass ich kein Konfigurationsverzeichnis unter /etc/vdr/plugins angelegt hatte.
7. Nach diversem Googeln bin ich auf dieses Thema und das Projektwiki gestossen. Wäre nett, wenn man hier http://vdr-wiki.de/wiki/index.php/Upnp-plugin dick und fett darauf hinweisen könnte, dass die Anweisungen veraltet sind und auf das Projektwiki linken.
oops Die Seite gibt's ja auch noch.
8. /etc/vdr/plugins/upnp angelegt, httpdocs dorthin kopiert, libupnp-vdr-provider.so gebaut und dorthin kopiert. Wäre übrigens auch interessant zu wissen, was diese Subplugins überhaupt tun. Ich habe von DLNA und UPnP keine Ahnung, ich weiss nur, dass ich auf mein Android Handy keine Verzeichnisse mit SSH mounten kann/will.
die Subplugins müssen aktuell noch nach /usr/lib/vdr/plugins/upnp, später mit dem neuen Makefile nach /usr/lib/vdr/plugins. Erklärung, was die Plugins im groben tun, steht in der HISTORY kurz beschrieben, eine genaue Erklärung für das einzelne Plugin fehlt. Kann ich noch nachholen.
9. VDR gestartet und mich über einen fetten Stacktrace gefreut. /etc/vdr/plugins/upnp für VDR schreibbar gemacht, danach ging es. Offenbar mag es das SQLite Ding von libtntdb gar nicht, wenn es nicht in das upnp Plugin Verzeichnis schreiben kann.
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.
Ach ja, das vdrDVBProfiler Plugin will bei mir nicht kompilieren:
Okay, is'n Bug wegen zu neuer VDR-Version. Ich wühl mich mal durch die VDR-History und bau eine Alternative ein.
Danke für die vielen Aspekte, die noch unstimmig sind. Ich hoffe, dass ich die schnell aus der Welt schaffen kann.
6. Mich gewundert, was mir diese Fehlermeldung im VDR Log sagen will: "basic_string::_S_construct NULL not valid". Vermutlich mochte das Plugin nicht, dass ich kein Konfigurationsverzeichnis unter /etc/vdr/plugins angelegt hatte.
Ach ja, das vdrDVBProfiler Plugin will bei mir nicht kompilieren:
Codevdr-1.7.18/PLUGINS/src/vdr-plugin-upnp/plugins/profiler/vdrDVBProfiler$ make g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I../../../include -I../../../../../../include -o dvbProfiler.o dvbProfiler.cpp dvbProfiler.cpp: In member function âbool upnp::DVBProfiler::GetRecordingMetadata(const std::string&, upnp::cMetadata&)â: dvbProfiler.cpp:152:19: error: âclass cRecordingâ has no member named âLengthInSecondsâ dvbProfiler.cpp:153:89: error: âclass cRecordingâ has no member named âLengthInSecondsâ make: *** [dvbProfiler.o] Error 1
Ich denke, Deine VDR-Version ist einfach zu alt, es ist nicht sonderlich spassig und vor allem ist es aufwaendig bei einem Plugin Abwaertskompatibilitaet zu pflegen, vor Allem in so einer Phase wie sich dieses Plugin nun gerade befindet... Mein Vorschlag waere, den VDR doch zu erneuern, auch wenn es wie ich mir das so vorstelle, bei Deiner Distribution nicht so einfach ist.
Hey, methodus und Keine_Ahnung was ist denn hier los, gleich geht doch das F1 Rennen in Indien los
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
