Request for comments: Plugin-Interface für DLNA-Plugin

Zitat von zirias

Ne teilweise Antwort: Wenn ich die Kommentare im Source richtig verstanden habe sollen pro Metadaten-Satz mehrere Resourcen möglich sein -- und diese Properties gibt es eben PRO Resource. Allerdings hab ich nicht so ganz verstanden, warum

Exakt! Der Grund ist auch einfach (evtl. hatte ich ihn hier schon erklärt): bestes Beispiel Live-TV, dort gibt es SD- und HD-Kanäle, die rein von den Metadaten keinen Unterschied enthalten, da der Inhalt identisch ist. Nur die Aufmachung ist anders. Es wäre jetzt also denkbar - das muss sich erst zeigen, weil ich das Verhalten der DMPs nicht genau kenne - dass man z.B. ZDF und ZDF HD zusammenlegt und nur einen Metadateneintrag pflegt. Der Player könnte nun, eine gewisse Intelligenz vorausgesetzt, immer den höherwertigen Stream abrufen, sofern er verfügbar ist und der DMP das Profil unterstützt.

Es gibt aber auch andere Anwendungsfälle: wenn man transkodieren muss, z.B. für's Handy, kann man eine neue Resource anbieten, die dann gewisse Restriktionen hat (häufig kann man dann nicht spulen)

Ich hatte mir schon überlegt, ob es nicht sinnvoll wäre, die Resource identisch zur Metadata-Klasse aufzubauen und auch über Set-/GetProperty die Werte setzen zu lassen. Außer resourceUri und protocolInfo sind alle optional.

Testweises Browsen funktioniert, jedoch hab ich noch ein Problem mit der Update-ID: die UpdateID eines Containers muss sich immer exakt dann ändern, wenn eine Datei angelegt, modifiziert oder gelöscht wurde. Da man aber schlecht für jeden Conainer einen Counter pflegen kann, würde ich jetzt vorschlagen, einfach einen Zeitstempel zu verwenden. Jetzt haben aber die verschiedenen Systeme eine unterschiedliche Granularität der System-Uhr.

Die ContaierUpdateID wird alle 2 Sekunden via Broadcast an alle Geräte rausposaunt, damit die ihre Medienliste aktualisieren können. Rein nach Nyquist müsste ja eine Granularität von 1s vollkommen ausreichen. Daher meine Frage: ist eine Update-ID anhand des Unix-Timestamps sinnvoll oder gibt es gewisse Caveats, die mir gerade entfallen? Vorteil eines Timestamps: er lässt sich relativ leicht und schnell generieren und er muss bei Dateisystemen nicht gesondert gespeichert werden, da der Timestamp im Modified-Date eines Verzeichnisses hinterlegt ist. Einzig, wenn eine Datei selbst inhaltlich verändert wird, ändert sich nicht das mDate eines Ordners, hat hier jemand eine Idee, wie man das abfangen kann?

Ja, ich habe einen inotify-Listener. Aber ich muss trotzdem containerUpdateIDs pflegen, damit die Player ihre Listen aktualisieren.

Inotify nutzt nur während des Betriebs etwas und es liefert auch keine brauchbare ID, also muss ich mir irgendwas überlegen.

die IDs müssen uint32_t sein. UUID fällt also flach :-/ Timestamps sind int64_t oder?

Ich mach mir 'nen Knoten ins Taschentuch, damit ich's nicht vergesse...

Darüber schweigt der Standard. Den faktisch ist es so, dass ContainerUpdateIDs optional sind. Also ggf. muss ich die SystemUpdateID hochzählen und die ContainerID bleibt gleich. Das ist dann notwendig, wenn sich nur die Metadaten (Titel, Beschreibung usw.) ändert und NICHT über ide Provider mitgeteilt werden kann.

Tachchen,

ich habe den Plugin-Loader jetzt weitgehend fertig geschrieben, kann ihn aber nicht testen, da ich mit dlopen, dlsym usw. noch nie etwas gemacht habe. Ich habe mir ein Makefile aus dem Plugin-Makefile zusammenkopiert, hapere jetzt aber an den Includes, den Verlinkungen usw.

Kennt sich jemand damit aus und könnte mir hier weiterhelfen? Ich würde gerne das Plugininterface so schnell wie möglich abschließen, damit ich die Provider und Profiler dann endlich schreiben kann. Die notwendigen Vorbereitungen sind getroffen, aber beim Zusammenstecken müsste jemand helfen. Es ist alles im Git eingepflegt, so dass dort mitgearbeitet werden könnte.

Hat jemand Lust?

Danke, scheint zu klappen, was ich da fabriziert habe. Der C++-Code ist also erstmal verwertbar. Was noch gar nicht geht, ist das Makefile. Ich hab hier viel mit Verrenkungen die Bibliothek so lange zurecht gebogen, bis sie geladen wird. Viele Sachen aus dem Plugin-Makefile und dem Hauptmakefile des UPnP-Plugins sind dadurch doppelt, was nicht so toll ist. Was davon kann alles ausgelagert werden?

Plugin-Makefile: http://projects.vdr-developer.…ider/vdrProvider/Makefile
Haupt-Makefile: http://projects.vdr-developer.…ons/master/entry/Makefile

Ich komme wieder nicht weiter: Das Laden eines Plugins klappt. Auch die Symbole zum Erzeugen der Klassen funktionieren. Jetzt habe ich die in der Plugin-Schnittstelle vorgegebe Klasse erweitert. Sobald ich nun die Lib lade erhalte ich nicht definierte Symbole, die sich alle auf SYmbole im UPnP-Plugin beziehen. Ich habe als Linker-Option "-rdynamic" hinzugefügt, aber der Fehler tritt weiterhin auf: "/usr/lib/vdr/plugins/upnp/libupnp-vdr-provider.so.1.0.0: undefined symbol: _ZNK4upnp21cUPnPResourceProvider8SeekableEv"

Mit c++filt übersetzt: upnp::cUPnPResourceProvider::Seekable() const

Die Funktion ist in der pluginManager.cpp auf jeden Fall definiert. Warum kann er die dann nicht finden? Muss ich noch mehr angeben als bloß "-rdynamic"? Google schlägt mir noch "-Wl,--export-dynamic" vor. Was ist der Unterschied?

"Eigentlich" nicht, da die einzigen C-artigen Funktionen in der tools.h stehen.

edit: verdammt. Jetzt sehe ich das erst:

#define UPNP_REGISTER_RESOURCE_PROVIDER(cls) extern "C" void *UPnPCreateResourceProvider(void) { return new cls; }

Muss das extern "C" dort weg, oder wie bekomme ich das gelöst?