Der muss sicherlich noch ein wenig angepasst werden, weil zwischendurch ja die Multi-Frontend-Unterstützung hinzugekommen ist. Das Ding basiert ja auf meinem dynamite-Plugin & -Patch. Ich bin nämlich auch gerade dabei, dynamite auf das nächste vdr-Release vorzubereiten und bin da über diese Stelle gestolpert.
Lars.
In der 2.4.1 werden nur Bugs gefixt.
Den o.g. Thread habe ich noch auf meiner Liste, aber eher in zweiten Viertel ;-).
Klaus
Ich bin nämlich auch gerade dabei, dynamite auf das nächste vdr-Release vorzubereiten
Nabend,
ist da mittlerweile was verfügbar. Wollte von 2.4 auf 2.4.1 upgraden aber der "vdr-2.4.0.26-dynamite-beta1.diff" Patch passt nicht mehr.
Apply patch vdr-2.4.0.26-dynamite-beta1.diff
patching file ci.h
patching file device.c
Hunk #1 FAILED at 70.
1 out of 19 hunks FAILED -- saving rejects to file device.c.rej
patching file device.h
patching file dvbci.c
patching file dvbci.h
patching file dvbdevice.c
Hunk #11 succeeded at 2043 (offset 4 lines).
Hunk #12 succeeded at 2081 (offset 4 lines).
Hunk #13 succeeded at 2138 (offset 4 lines).
Hunk #14 succeeded at 2312 (offset 4 lines).
patching file dvbdevice.h
==> FEHLER: Ein Fehler geschah in prepare().
Breche ab...LarsS
Nein, leider noch nicht. Habe beruflich so viel um die Ohren, dass kaum Zeit bleibt. Seit ein paar Monaten nutze ich auch keinen vdr mehr, der steht nur rum und tut nichts. Mal sehen, was der Winter bringt...
ja kein thema, vielleicht probier ich das mal selbst hinzukriegen.
aber bloß nicht dem vdr abtrünnig werden... 
Hallo Leute, gibt's denn mittlerweile einen funktionierenden Patch für dynamite plugin? Der Winter ist ja schon lang rum 
Ich kenne das Plugin nicht und habe keine Ahnung warum&wieso man das braucht, aber den diff zu 2.4.1 auflösen, kann man auch so. Macht halt knapp 10min Arbeit.
Ungetestet auf Funktion, ungetestet auf Compiler-Fehler. Siehe Patch im Anhang.
Ja, ich hab mir den diff auch schon gestern selber angepasst. Test steht aber noch aus. Und ja, der Patch hat sich leicht anpassen lassen
Es wunderte mich halt nur dass auf dem launchpad repo extra darauf hingewiesen wurde dass dieses Paket fehlt da es halt eben noch keinen angepassten Patch gibt
Wenns denn mal funktionieren sollte dann mach ich ggf auch mal einen PR
Weil es da schon ein paar gravierende Änderungen im Bereich der DVB-Karten mit mehreren, nicht gleichzeitig zu benutzenden Frontends gibt. Der alte dynamite-Patch passt da nicht so einfach drauf.
Und einfach nur einen diff irgendwie auflösen, dass er kompiliert, hat in meinen Augen nichts mit verantwortungsvoller Programmierung zu tun.
Der Source ist da und unter GPL, ihr dürft damit machen, was ihr wollt. Aber auf eigene Verantwortung.
wirbel einfach mal ins Readme schauen, dann kann man lesen, was es tut und entscheiden, ob man es braucht.
Der beta-Patch ist bzgl. Multi-Frontend nicht fertig. Da war bisher keine Zeit.
Ich würde das ganze Ding sowieso eher einstampfen und in einen einfachen Patch umwandeln wollen, der nur das macht, wofür dynamite eigentlich gestartet wurde: dvb-devices nach dem Start per udev erkennen und einbinden und genauso zur Laufzeit wieder aushängen können. Ich finde, das ist ein wichtiges Feature, welches dem vdr noch fehlt. Die devices sind noch viel zu statisch.
Es gibt deutliche Änderungen in {dvb,}device.c - aber "mit mehreren, nicht gleichzeitig zu benutzenden Frontends gibt"?
Welche Änderungen genau meinst du damit? Soweit sah alles dem originalen Sinn entsprechend aus.
Wie auch immer - ich nehm den Anhang mal weg.
Ich würde das ganze Ding sowieso eher einstampfen und in einen einfachen Patch umwandeln wollen, der nur das macht, wofür dynamite eigentlich gestartet wurde: dvb-devices nach dem Start per udev erkennen und einbinden und genauso zur Laufzeit wieder aushängen können. Ich finde, das ist ein wichtiges Feature, welches dem vdr noch fehlt. Die devices sind noch viel zu statisch.
Macht halt nur Sinn wenn es in Kooperation mit Klaus gemacht wird, denn sonst endet dieser Patch irgendwann genau so wie der aktuelle der für das Plugin nötig ist.
Letztlich ist das der Grund warum ich mich auf sowas für vdr4arch gar nicht erst eingelassen habe. Was nicht mit Stock-VDR geht ist nie bei vdr4arch reingekommen. Ausnahme ist der "main menu hooks"-Patch. Sowie der Ärger macht fliegt der aber auch raus.
VDR sollte keine Abhängigkeit von udev haben. Das endet im Nirvana.
Udev ist bei ziemlich genau 100% der Distributionen sowieso dabei. Gefühlt seit mindestens 10 Jahren.
Aber als Alternative habe ich in der Vergangenheit schon inotify (https://www.man7.org/linux/man-pages/man7/inotify.7.html) für sowas im Einsatz gesehen. Man kann damit auch erkennen wenn unter /dev etwas dazu kommt. Und das dürfte ein Kernel-Standardfeature sein.
Nur gibt es dabei unterschiedliche Forks udev, eudev, ...
Die aber alle zu den Clients die gleiche Schnittstelle haben. Alles andere würde den Forks auch in die Quere kommen, denn das "Original" ist eben führend.
Mag sein - aber was bitte soll udev überhaupt in VDR?
Wenn jemand ne Aufnahme, Live Bild, (any other cReceiver here) auf einem USB Stick zu laufen hat und der wird abgezogen, dann wird VDR in ein Problem laufen. Mit und ohne udev.
Es gibt DVB-Karten, die z.B. ein T- und ein S-Frontend haben, von denen aber immer nur eins exklusiv geöffnet werden kann. Wenn ich mich richtig erinnere, unterstützt der vdr das seit 2.4.1. Das zog einige Änderungen an cDvbTuner usw. nach sich, genau an den Stellen, wo der Patch auch eingreift. Ich hatte mit dem Patch schon angefangen, dann aber keine Zeit mehr, es zu Ende zu bringen.
Deshalb wird der noch nicht richtig funktionieren.
Ich weiß nicht, was die Aversion gegen udev soll. Das ist so ziemlich in jeder Distribution vertreten, es ist nichts exotisches. Und es geht nicht so sehr um das Abziehen eines usb-dvb-Sticks, der in Benutzung ist, sondern um das nachträgliche Anstöpseln eines solchen. Oder um solche Karten, die bei der Initialisierung so lange brauchen und der vdr schon lange gestartet sein könnte. Damit man keine Verrenkungen mehr machen muss, um den Start des vdr künstlich zu verzögern.
Und natürlich würde ich den Patch genauso einreichen, wie alle anderen Anpassungen, die ich gemacht habe. Und wenn Klaus das für gut befindet, hab ich Glück gehabt. Wenn nicht, dann eben nicht.
Don’t have an account yet? Register yourself now and be a part of our community!