Gegen welche Quelle ist der Patch?
Ich möchte mir das mal anschauen.
LG,
Jasmin
Mod.: Auf Wunsch von wirbel abgesplittet von vdr-live @ vdr-2.3.1 ?
vdr-plugin-live für VDR 2.3.x ...
-
Gegen welche Quelle ist der Patch?
Vergiss die Frage ...
Natürlich gegen git://projects.vdr-developer.org/vdr-plugin-live.gitLG,
Jasmin -
Das hier ist eine Version, die zumindest als Basis für 2.3.1 dienen könnte, vieles funzt damit (aber nicht alles).
Was geht nicht?
Enthält einige Änderungen von Nachteule, einige von mir in bunter Mischung. Also nicht 100% die Version mit Patch von Nachteule.
Also deine Version ist wg. der Format Änderungen leider nicht mit der von Nachteule zu vergleichen. Ich müsste beide Versionen durch einen Source Konverter laufen lassen, damit man erkennt was du jetzt gemacht hast.
Ich hab mal die Version von Nachteule am Laufen und bei mir geht alles was ich so brauche, deshalb die Frage was nicht geht.
Und gleich neue Fragen, 1)WARUM hast du 2)WAS geändert?Vielleicht wird ja so aus einer der Versionen wieder eine neue 100% funktionierende Version.
Also derzeit ist nur die Version von Nachteule als Patch verwendbar. Aber wenn du mir die Fragen beantwortest, tu ich mir vielleicht die Arbeit an und versuche deine Änderungen als Patch zu rekonstruieren, wenn du das nicht machen kannst/willst.
LG,
Jasmin -
Ich müsste beide Versionen durch einen Source Konverter laufen lassen, damit man erkennt was du jetzt gemacht hast.
Ich habe das heute mal mit "astyle -A4 *.cpp *.h epgsearch/*.h" für beide Versionen gemacht und diese verglichen
und ...
Und gleich neue Fragen, 1)WARUM hast du 2)WAS geändert?
DAS ist trotzdem nicht leicht zu sehen, weil da "&&" durch "and" und '!' durch "not" ersetzt wurden und sonst viele fragwürdige Style Anpassungen, wie Object Variablen von hinten nach vorne in der Klassendefinition verschoben, einen schnellen Vergleich verhindern. Verstehen tu i sowas ned!
Dann hab ich gesehen, dass der Sinn von "LOCK_CHANNELS_READ" dadurch ausgehebelt wurde, indem "cChannels::GetChannelsRead" mit "rd.Remove()" gepaart vor jedem return den Lock wieder freigibt. Man verwendet in C++ diese AutoLock Klassen, damit man sich eben nicht um das Unlock kümmern muss, wenn man schon unstrukturiert mit mehreren "return" aus einer Funktion geht. Wo da die Verbesserung liegen soll ist mir schleierhaft. Höchstens im entfernen eines "#if VDRVERSNUM >= 20301". Und abfragen ob der Pointer 0 ist muss man auch nicht, da das Lock Macro erst zurück kommt wenn man den Lock hat.
Dann wurde der "std::" Namespace überall ergänzt und die "using namespace std;"Anweisungen entfernt.
Es wurde auch ein neuer Vector eingeführt, aber das hab ich mir nicht genau angeschaut. Das ist wahrscheinlich eine wirklich sinnvolle Erweiterung.
... tu ich mir vielleicht die Arbeit an und versuche deine Änderungen als Patch zu rekonstruieren
Also das wäre schon recht viel Arbeit!
Ich würde das vielleicht wirklich tun, wenn ich die Frage "Was geht nicht?" beantwortet bekomme. Ich will nämlich nicht leere km laufen, wenn es dann an etwas kleinem scheitert, was ich mangels Hardware oder tiefen Plugin Kenntnissen nicht lösen kann.LG,
Jasmin -
Moin Jasmin,
ich nutze das Plugin nicht mehr, ich brauchte es nur für die Umstellung auf 2.3.x.; und weitere
Arbeit lohnte nicht.Egal, welche Basis du benutzen möchtest, du wirst in jedem Falle die gleiche Arbeit investieren.
Etwa die gleiche Arbeit, wie das Schreiben eines neues Plugins.btw: Einfach überall ein 'LOCK_CHANNELS_READ' macro einsetzen hat nicht funktioniert, weil
zusätzlich die locks der einzelnen listen in bestimmter Reihenfolge erfolgen müssen.
Nur diese macros vor jedem Zugriff führt zu deadlocks. -
Ich war jetzt einige Zeit mit dem ddci2 Plugin und Kernel Patches beschäftigt.
Jetzt bin ich wieder am Vergleichen der beiden Patches und ich bin mir nicht sicher ob da immer die Lock Reihenfolge Timers, Channels, Recordings und Schedules eingehalten wird. Wenn das jetzt funktioniert, dann nur zufällig und das werde ich versuchen zu beheben.Ein schönes Beispiel ist SearchResult::GetEvent() in epgsearch.cpp. Da wird eindeutig zuerst Schedules gelockt und dann erst die Channels in GetChannel().
Aufgerufen wird das dann in pages/whats_on.ecpp und da steht ein "LOCK_CHANNELS_READ;" am beginn, was es wieder gut macht, weil dann die Lock Reihenfolge doch stimmt. Also das ist alles andere als schön und für zukünftige Erweiterungen hinderlich.Ich muss mir noch überlegen wie man das ev. besser machen könnte. Da sehe ich aber das Problem die Kompatibilität zu VDR 2.x.y aufrecht zu erhalten.
Wie wichtig ist denn das?
Beim epgsearch Plugin hat fnu die "#if VDRVERSNUM" ja raus genommen. Wenn ich das auch mache, dann könnte ich leichter Parameter zu den Zugriffsfunktionen hinzufügen und so die Lock Reihenfolge immer sicherstellen.EDIT: Habe gerade gesehen, dass in "pages/whats_on.ecpp" LOCK_SCHEDULES_READ überhaupt am Beginn steht und dann später erst LOCK_CHANNELS_READ. Also das ist laut der Beschreibung von Klaus genau verkehrt herum. Warum das dann so problemlos funktioniert wie hier alle schreiben versteh ich ned
LG,
Jasmin -
Beim epgsearch Plugin hat fnu die "#if VDRVERSNUM" ja raus genommen. Wenn ich das auch mache, dann könnte ich leichter Parameter zu den Zugriffsfunktionen hinzufügen und so die Lock Reihenfolge immer sicherstellen.
Nun, ja, es gibt ja einen bekannten Stand für VDR 2.2.0, der gut funktioniert, wie ja auch bei epgsearch. Es geht also nix verloren, wenn man nun live für VDR 2.3.x bei gleichbleibender Funktionalität richtig fit machen würde.Ausserdem wurde bei live auch da vor über 2 Jahren schonmal alle "#if VDRVERSNUM" bis einschließlich 1.7.28 rausgenommen ...
Regards
fnu -
Stimmt. Dann aber bitte, wie bei epgsearch, auch wieder einen festen Branch für VDR 2.2. Ich habe bei vdr4arch bei epgsearch bereits umgebaut und würde dann auch "live" auf diesen Branch nehmen, sobald er denn da ist.
-
Dazu müsste man erstmal die Kontrolle über das GIT bekommen. Ich vermute bei Jasmin geht es erstmal um einen Patch für 2.3.1 ...
[Edit] rofafor hätte sich live geforkt ... https://github.com/rofafor/vdr-plugin-live ...
Und wir hoffen ja, das die nächste stable Version in absehbarer Zeit mal 2.4.0 heißt ...
Regards
fnu -
Also das wäre schon recht viel Arbeit!
Ich habe die Änderungen von Wirbel herausgefunden und sie in einen Patch verpackt.
Der Patch ist nach dem Patch vdr-plugin-live-2.3.1.diff von Nachteule anzuwenden!Ich hab keine Ahnung wie ich die neuen Code Stellen testen soll. Es geht mir hierbei um RecordingsManager-StateChanged, aufgerufen von RecordingsManager-EnsureValidData und SortedTimers-Modified, aufgerufen von TimerManager-DoPendingWork. Vielleicht hat ja Nachteule oder Wirbel eine Idee dazu.
Nachteule würde ich um ein Review der Änderungen bitten. Am besten du schreibst mir eine eMail, weil es gib wahrscheinlich einiges zu besprechen. eMail Adresse steht im README vom ddci2 Plugin.
Die verkehrte Lock Reihenfolge hab ich noch nicht repariert!
Dazu müsste man erstmal die Kontrolle über das GIT bekommen
Ich habe die früheren Maintainer mal angepingt.
rofafor hätte sich live geforkt ... https://github.com/rofafor/vdr-plugin-live ...
Ah danke, mal sehen wie ich das mache. Wahrscheinlich doch auf GitHub arbeiten.
Und wir hoffen ja, das die nächste stable Version in absehbarer Zeit mal 2.4.0 heißt ...
Ja, aber vorher kommt sicher noch eine Developer Version zum ausgiebig Testen.
LG
Jasmin -
Ah danke, mal sehen wie ich das mache. Wahrscheinlich doch auf GitHub arbeiten.
Gesagt getan, ihr findet meine Version im Git auf Branch vdr-2.3.x
LG,
Jasmin -
Es gäbe ja noch den ausstehenden Punkt, diese Suchtimer für inaktiv angelegte Timer von epgsearch in live anlegen bzw. bearbeiten zu können ...
Gruß
Frank -
Guten Morgen,
vielen Dank, das du dich der Sache an nimmst
Gruß
speed -
Hallo,
wäre es auch möglich diesen Patch mit einzubauen ?
[live] Patch für OSD ohne Ausgabeplugin
Das ist bei einem headless Server wirklich super praktisch.
Thanks
speed -
Es gäbe ja noch den ausstehenden Punkt, diese Suchtimer für inaktiv angelegte Timer von epgsearch in live anlegen bzw. bearbeiten zu können ...
Also bevor neue Features rein kommen, muss das Plugin 100% sicher funktionieren. Da wäre z.B. das:
Die verkehrte Lock Reihenfolge hab ich noch nicht repariert!
und
Ich hab keine Ahnung wie ich die neuen Code Stellen testen soll. Es geht mir hierbei um RecordingsManager-StateChanged, aufgerufen von RecordingsManager-EnsureValidData und SortedTimers-Modified, aufgerufen von TimerManager-DoPendingWork. Vielleicht hat ja Nachteule oder Wirbel eine Idee dazu.
Und mir sehr sehr wichtig:
Nachteule würde ich um ein Review der Änderungen bitten. Am besten du schreibst mir eine eMail, weil es gib wahrscheinlich einiges zu besprechen. eMail Adresse steht im README vom ddci2 Plugin.
Meine Zeit ist sehr begrenzt und ich möchte auch noch ein neues Media-DKMS Paket für die Kernel Treiber von DD auf Basis der Arbeit von nst machen.Ich kenne mich ned wirklich aus mit dem ganzen Plugin, ich kann nur Code lesen und diesen einfach logisch zusammen stöpseln ... .
Und bitte nicht mehr Patches verwenden, sondern Git!
LG,
Jasmin -
Hallo,
wäre es auch möglich diesen Patch mit einzubauen ?Ja, wobei ich wohl besser diese Version nehme.
LG,
Jasmin -
@Jasmin,
das wäre super, vielen Dank
speed -
-
Guten Morgen Jasmin,
super vielen Dank.
Werde ich direkt heute Abend testen, und gebe dann Feedback.
Gruß
speed -
Hallo,
ich habe gerade mal geschaut, ich habe Schneehintergrund und kann nicht einstellen.
Der Patch hat leider nicht funktioniert.
Das war das Ergebnis, was ich auch hatte beim Versuch den Patch mit VDR 2.3.x zu benutzen.
Lieben Gruß
speed
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!