[ANNOUNCE] CEC Remote Plugin 1.5.2/1.5.3

Quote from Ulrich Eckhardt

Die letzten paar Änderungen waren wohl nicht ursächlich, die haben nur eine Racing-Condition getriggert. Ich habe jetzt mal etwas aufgeräumt, den C++ Code modernisiert und die Racing Condition gefixt. Ist alles schon mal im Repo, hat aber noch keine neue Version.

Ich habe noch ein bischen gesucht, und habe in der libcec entdeckt, das die libcec auch wenn der port und das basedevice vorgegeben wird, das zunächst annimmt, aber dann trotzdem ein "autodetect" macht indem sie nachsieht welche phys. addresse in der edid drin steht. Das kann man nur verhindern, wenn man die phy. addr. direkt über die api setzt. (SetPhysicalAddress())

yavdr verwendet ja eine statische edid, die einmalig generiert wird und dann unverändert bleibt. (Damit der VDR weis welcher TV dran ist auch wenn der aus ist) Wenn jetzt, so wie bei mir, bei der yavdr installation der VDR direkt mit dem TV verbunden war, wird diese physikalische addresse in das edid file geschrieben, und nicht mehr verändert. LibCeC liest 1000 aus der edid. Nach dem neu generieren der edid (mit dem Denon dazwischen) macht er das "autodetect" zwar immer noch, aber die libCeC liest jetzt 1100 aus der edid.

Für das cecremote plugin läuft es darauf hinaus, das die parameter

		<hdmiport>1</hdmiport>
		<basedevice>5</basedevice>

wirkungslos sind, solange nicht der libCEC über SetPhysicalAddress() direkt eine Adresse vorgegeben wird.

Quote from Ulrich Eckhardt

cecdebug ist nur für die Debug-Ausgaben vom CEC-Adapter. Ansonsten wird das nur über die -l Option vom vdr gesteuert.

könntest du das ändern sodass cecdebug (oder auch ein anderer (cmdline) parameter) auch für die plugin log ausgaben zuständig ist?

Quote from Ulrich Eckhardt

Ich verwende da die normalen VDR Logging Funktionen, die möchte ich nicht überschreiben. Wenn du den VDR mit -l3 startest ist das halt sehr geschwätzig.

hmm, das verstehe ich nicht ganz, du hast je eh schon ein mapping auf deine eigene logging funktion drin:

#define Esyslog(a...) ceclogmsg(0, a)
#define Isyslog(a...) ceclogmsg(1, a)
#define Dsyslog(a...) ceclogmsg(2, a)

Da wäre es doch ein leichtes, das dort zentral einzubauen.

du hast doch auch schon ein ProcessArgs() drin, wenn du das z.b. erweiterst um eine -l option ist der loglevel unabhängig vom vdr einstellbar.

Wenn keine -l option angegeben wird kannst du dann den SysLogLevel nehmen. Damit ist das verhalten wie vorher.

Man stelle sich nur vor, alle plugins würden so gesprächig werden, nur weil man im vdr mit loglevel 3 einem Problem nachgehen will....

Quote from hugoboss00

Man stelle sich nur vor, alle plugins würden so gesprächig werden, nur weil man im vdr mit loglevel 3 einem Problem nachgehen will....

Das würde ich mir eigentlich sogar erwarten, wenn ein VDR-Plugin keinen eigenen Loglevel (Parameter) zur Verfügung stellt.

Quote from davie2000

Das würde ich mir eigentlich sogar erwarten, wenn ein VDR-Plugin keinen eigenen Loglevel (Parameter) zur Verfügung stellt.

ja, eh. Aber zumindest die plugins die ich verwende haben entweder einen eigenen loglevel oder loggen nur errors

Ich würde sagen, wenn ein Plugin mit -l3 deutlich mehr Meldungen ausgibt als VDR selbst mit -l3 ausgibt, dann sollte das Plugin einen eigenen Loglevel bekommen.