Posts by kls

Das ist bei mir auch schon mal aufgetreten, es liegt also am "vanilla" VDR ;-).

Ich werde das bei Gelegenheit debuggen.

Ich habe jetzt git-daemon installiert.

Damit geht jetzt auch

git clone git://git.tvdr.de/vdr.git

(N.B.: "git:" statt "http:"!).

Geht deutlich schneller - 12 Sekunden statt 5.5 Minuten :-).

Die Versionsnummern 2.4.2 und 2.4.3 waren notwendig wegen Änderungen an einigen Header-Files (siehe HISTORY), um dafür zu sorgen, dass Plugins neu übersetzt werden. Das offizielle "stable/2.4" Label im GIT werde ich auf die "master" Version setzen, sobald sich der Stand stablisiert hat (sprich: keine schlimmen Fehler mehr auftreten). Dann gibt es natürlich auch wieder ein entsprechendes Archiv auf ftp.tvdr.de.

Ich habe soeben http://git.tvdr.de aktualisiert.

MegaV0lt wrote:

kls Das ist doch eine VDR-Einstellung? Kannst Du da mal schauen, ob es wirklich von da herkommen kann oder obs am EPG liegt

Ich hab das leider erst heute gesehen

Wie FireFly richtig eklärt hat, werden '|' im EPG-Text zu Zeilenumbrüchen.

Es liegt also an der verwendeten EPG-Quelle.

kamel5 es hätte mich ehrlich gesagt auch gewundert, wenn es sich damit anders verhalten hätte als früher, denn ob der 'else if' Zweig wegen der Bedingung, die immer false ist, nie durchlaufen wird, oder weil er ganz weggelassen wird, sollte keinen Unterschied machen.

Aber HelmutB hat natürlich recht, warum sollen User mit nicht gebondeten Devices auf eine eigentlich gewollte Funktionalität verzichten müssen. Ich wollte zwar das Thema Device Bonding vollständig innerhalb cDvbDevice halten und es nicht in device.c haben, aber nachdem die Lösung durch ein einfaches cDevice::IsBonded() machbar ist, hab ich mich halt dazu durchgerungen.

Anbei die hoffentlich endgültige Fassung dieses Fixes. Die Zeilennummern können etwas off sein, ansonsten sollte es aber passen.

Die Änderung an cDevice::Priority() hatte wohl zu viele Seiteneffekte, daher schlage ich folgendes vor:

- für dvbdevice.[hc] und device.h wieder die Versionen aus 2.4.2 nehmen

- in device.c den 'else if'-Zweig löschen:

Damit bleibt lediglich der Fix von HelmutB , dass das erste Device genommen wird, welches den Transponder ohne Störung von Aufnahmen oder Live-View liefern kann. Da der 'else if' Zweig schon seit 8 Jahren nicht mehr aktiv war, hat er anscheinend niemandem gefehlt. Dieser Zweig sollte dafür sorgen, dass für eine anstehende VPS-Aufnahme der Live-Kanal umgeschaltet wird bzw. eine Aufnahme mit niedrigerer Priorität unterbrochen wird, falls kein freies Device verfügbar ist. So schaltet er halt zur Startzeit der Aufnahme "hart" um.

kamel5 : kannst du bitte mit den genannten Änderungen bzw. Rückbauten nochmal testen?

SurfaceCleanerZ wrote:

im git auf tvdr.de fehlt obiger Patch auch noch

Ich warte noch auf positive Rückmeldungen zu diesem Fix.

Beim Nächsten Generieren des GIT aus meinem RCS wird das alles dabei sein.

Die Schleife in cDevice::Detach() ist sehr schnell fertig. Es werden darin lediglich Pointer verglichen.

Ich denke schon, dass man hier schneller fertig ist, wenn man einmal lockt und dann die Schleife 16 mal durchläuft, anstatt 16 mal zu locken und unlocken, was ja auch jedes Mal zu einem Taskwechsel führt (bzw. führen kann).

Der einzige Unterschied zwischen den beiden Varianten ist eigentlich, dass statt 16 Lock/Unlock Sequenzen nur noch *eine* gemacht wird. Wenn überhaupt, dann hätte ich eher erwartet, dass das Umschalten damit schneller geht ;-).

HelmutB hat hier einen Fix für ein Problem bei der Device-Wahl mit IPTV gepostet und darin festgestellt, dass der Code im 'else if' Zweig nie ausgeführt wird, womit er vollkommen recht hat.

Der Grund hierfür war ein "Fix", den ich damals hier gepostet hatte. Der war natürlich Quatsch, denn wenn MaySwitchTransponder() false ist, wird weder der 'if' noch der 'else if' Zweig ausgeführt, weil der Aufruf ja in beiden Bedingungen drin ist und sich das Ergebnis zwischen den beiden Aufrufen auch nicht ändert. Das Problem von damals trat damit nur einfach nicht mehr auf, weil die Auswahl des Devices über die Prioritäten ganz abgeklemmt wurde. Wie kamel5  hier richtig beobachtet hat, hatte sich durch den Patch das eigentlich beabsichtigte Verhalten bei VPS-Aufnahmen verändert. Es wurde, wenn alle Devices belegt waren, nicht mehr für eine höher priorisierte VPS-Aufnahme einige Zeit vor dem geplanten Beginn auf den entsprechenden Transponder geschaltet. Nachdem Device-Bonding für mich immer schon ein "ungeliebtes Feature" war und es damit aber ansonsten zu funktionieren schien, bin ich der Sache dann auch nicht weiter nachgegangen (siehe auch hier und hier).

Anbei ein Patch, der zum Einen die Änderung von HelmutB enthält, dass immer das *erste* freie Device genommen wird, und zum Anderen im Falle von Device-Bonding die Prioritäten aller gebondeten Devices berücksichtigt. Damit sollten eigentlich beide Probleme gelöst und auch die Nebenwirkung bzgl. VPS-Aufnahmen behoben sein.

Bitte testet diesen Patch ausgiebig, insbesondere kamel5 und dile .

Uwe wrote:

Hattest du Dir den device.patch vom User xblades inzwischen angeschaut?

Danke für den Hinweis, den hätte ich fast aus den Augen verloren.

Ich habe mir das jetzt mal näher angeschaut. Die Änderung in Version 2.3.9 diente

ja dazu, einen möglichen Deadlock zu verhindern. Dazu wurde von Lock()/Unlock(),

was ja den gesamten Thread lockt, auf ein lokaleres Locking mit mutexReceiver

umgestellt. Dadurch kam aber das Receiver->Activate(false), welches vorher nicht

mit im Lock war, in den neuen Lock hinein. User xblades hat also wohl vollkommen Recht,

es da wieder herauszuholen. Allerdings würde ich gern den mutexReceiver nicht

bei jedem Schleifendurchlauf locken/unlocken, sondern einfach das Receiver->Activate(false)

und die umliegenden Zeilen aus der Schleife rausnehmen, was auf das Gleiche

hinauslaufen sollte.

Bitte schaut euch mal beiliegende Version des Patches an und testet damit.

Wobei: cArgs::arg ist eine cStringList und kein cString ;-).

Das mit args benutze ich nicht, daher hier auch kein entsprechender Aufruf.

Nachdem ich den Fehler jetzt gesehen habe wundert es mich auch, dass da nicht schon was passiert ist...

Hier die Funktion mit allen Checks:

Bis jetzt immer noch kein Aufruf. Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.

SHF du hast da vollkommen Recht, diese Funtion ist fehlerhaft!

In erster Näherung sollte das wohl so aussehen:

Allerdings habe ich eine Ausgabe eingebaut um zu sehen, ob diese Funktion überhaupt jemals aufgerufen wird.

Bis jetzt kein Aufruf.

M-Reimer wrote:

Damit wäre aber die Hauptschleife inklusive des entsprechenden Threads eigentlich ganz außen vor.

Nicht unbedingt, denn egal wie oft die Hauptschleife durchlaufen wird, werden manche Operationen ja nur in bestimmten zeitlichen Abständen durchgeführt (z.B. alles, was mit 'Now' zu tun hat).

M-Reimer wrote:

Fällt dir etwas anderes im VDR ein was mit einer gewissen Regelmäßigkeit läuft?

EPG-Daten kommen im Mittel mit einer gewissen Rate rein, die relativ gleichmäßig sein dürfte.

Was anderes fällt mir im Moment auch nicht ein.

Ich sehe das so: sizeof(*hob->object) liefert die Größe eines cListObject, während sizeof(*tmp) die Größe eines cSectionSyncerEntry liefert. Es ist nicht überraschend, dass die beiden Werte unterschiedlich sind. delete hob->object gibt den Speicher des Objekts an der Stelle frei, und das müsste der Größe von cSectionSyncerEntry entsprechen, denn so viel wurde ja beim Anlegen dieses Objekts allokiert.

Ich habe meinen Test-VDR hier jetzt mehrere Tage mit 100ms (statt 1000ms) Wartezeit in cInterface::GetKey() laufen lassen. Damit wird die Hauptschleife zehnmal so oft durchlaufen als normal. Es kam aber zu keiner erkennbaren Steigerung des Speicherverbrauchs. An der Häufigkeit liegt es also wohl nicht.

An Plugins verwende ich übrigens nur ddci2 und vaapidevice. Alle anderen Plugins würde ich zunächst mal bei der Suche nach dem Leck ausschließen.

kfb77 wrote:

Deine Meinung dazu ?

Beim ersten printf() in cHashBase::Clear(void) gibst du die Größe von *hob aus, es müsste aber doch wohl die von *hob->object sein, denn das ist es, was freigegeben wird.

Beobachtest du damit dann auch noch eine Diskrepanz?