livebuffer patch für vdr 1.7.16 (aus rmm svn)

Zitat

Original von tiqqNur gibt es die nötigen Schnittstellen nicht...
Ohne Patchen wird man das imho nicht implementieren können.
Und nur für die Funktionalität neue Schnittstellen definieren ist wohl auch der falsche Ansatz.
Eigentlich gehört die Funktionalität imho in den VDR - so wie auch das Starten einer Aufnahme bei Pause, wenn es nicht aktiviert ist.
Es wurde, wenn ich es richtig verstanden habe, aber abgelehnt, dieses in den VDR zu integrieren.
Daher wird es immer ien Patch bleiben, selbst wenn die eigentliche Funktionalität in einem Plugin ausgelagert wird.
Daher sehe ich auch keinen Vorteil, wenn man ein Patch _und_ ein Plugin braucht.

Alles anzeigen

Darueber gabs doch schon ne lange Diskussion. Mit dem richtigen Ansatz gibt es meiner Meinung nach eine Loesung ohne den VDR zu patchen.
Man benoetigt ein Ausgabedevice welches den TS Stream puffert und bei Bedarf wird dieser in ne Aufnahme gewandelt. Mag sein dass es mit nem patch einfacher ist, aber es geht sicher auch ohne.

Warum gibt es die nötigen Schnittstellen nicht?

Ein Plugin kann einen Receiver auf ein Device hängen/Daten auf Platte schreiben und kann prüfen welcher Kanal gerade getuned ist. Plugins werden sogar über cStatus über einen Channelswitch informiert.

Was genau fehlt denn noch zusätzlich?

Zitat

Original von helau
Darueber gabs doch schon ne lange Diskussion. Mit dem richtigen Ansatz gibt es meiner Meinung nach eine Loesung ohne den VDR zu patchen.
Man benoetigt ein Ausgabedevice welches den TS Stream puffert und bei Bedarf wird dieser in ne Aufnahme gewandelt. Mag sein dass es mit nem patch einfacher ist, aber es geht sicher auch ohne.

Das Ausgabedevice ist IMHO nur für die *Ausgabe* zuständig. Davon gibt es bereits einige. Das eingebaute "dvbsddevice" ist eines. xineliboutput-plugin und xine-plugin sind zwei weitere bekannte.

Um ohne Verlust der Vielfalt an Ausgabeplugins auszukommen müsste dein Ausgabeplugin also zwischen VDR und dem eigentlichen Ausgabe-Plugin sitzen. Ich sehe das als fummelig an.

Warten wir halt mal ab, wann der Patch sauber läuft und dann kann man ja mal niederschreiben, wo überall in den VDR gegriffen wird, für was es schon Schnittstellen gibt und wo zusätzliche nötig/sinnvoll wären.

Zitat

Original von Mreimer
Das Ausgabedevice ist IMHO nur für die *Ausgabe* zuständig. Davon gibt es bereits einige. Das eingebaute "dvbsddevice" ist eines. xineliboutput-plugin und xine-plugin sind zwei weitere bekannte.

Das streamdev ist auch eines und es gibt noch weitere.
Man kann problemlos mehrere Ausgabedevices haben, die Ausgabe muss ja nicht auf nem Schirm, sondern kann auch auf Platte oder in nen Stream erfolgen ...

Zitat

Warten wir halt mal ab, wann der Patch sauber läuft und dann kann man ja mal niederschreiben, wo überall in den VDR gegriffen wird, für was es schon Schnittstellen gibt und wo zusätzliche nötig/sinnvoll wären.

Genau das ist das Problem. Laeuft der Patch dann baut nie mehr einer ein Plugin denn es geht ja. Und nachher schreien wieder alle wenn es ne Aenderung am VDR gibt und der Patch nicht mehr geht ...

Zitat

Original von helau
Das streamdev ist auch eines und es gibt noch weitere.
Man kann problemlos mehrere Ausgabedevices haben, die Ausgabe muss ja nicht auf nem Schirm, sondern kann auch auf Platte oder in nen Stream erfolgen ...

Ich kenne das noch so, dass nur das "Primary DVB Device" wirklich ausgibt. Es wird also wohl immer nur ein Ausgabe-Device aktiv sein?

Man muss an den aktiven Datenstrom dran. Das steht fest. Schon möglich, dass das schon das erste neue Interface wird, das erstellt werden muss.

Zitat

Genau das ist das Problem. Laeuft der Patch dann baut nie mehr einer ein Plugin denn es geht ja. Und nachher schreien wieder alle wenn es ne Aenderung am VDR gibt und der Patch nicht mehr geht ...

Ich werde sicher nicht schreien. Eine Plugin-Lösung würde ich vermutlich zumindest mal testen. Die Patch-Lösung würde ich dagegen links liegen lassen.

Wie schonmal geschrieben: Es ist schade, das im Bereich VDR die Patcherei derart überhand genommen hat. Klar ist der Weg, ein Feature, entweder direkt oder nach Anpassung der Plugin-Schnittstelle als Plugin mit dem VDR "sauber" zu verheiraten aufwändiger, aber auf Dauer ist das die sauberere Lösung.

Zitat

Original von Mreimer
Ich kenne das noch so, dass nur das "Primary DVB Device" wirklich ausgibt. Es wird also wohl immer nur ein Ausgabe-Device aktiv sein?

Das war mal so Dann wuerde ja auch streamdev-server nicht funktionieren, wenn man lokal mit xine anschaut ...

Zitat

Original von Mreimer
Ich kenne das noch so, dass nur das "Primary DVB Device" wirklich ausgibt. Es wird also wohl immer nur ein Ausgabe-Device aktiv sein?

Man muss an den aktiven Datenstrom dran. Das steht fest. Schon möglich, dass das schon das erste neue Interface wird, das erstellt werden muss.

Kein Problem.

Alles was man machen muss ist, ist abfragen welcher Kanal gerade gesehen wird und einen Receiver auf das gerade empfangende Device dranhängen.

Zitat

Original von wirbel
Kein Problem.

Alles was man machen muss ist, ist abfragen welcher Kanal gerade gesehen wird und einen Receiver auf das gerade empfangende Device dranhängen.

Dann hätten wir für den Zweck schon zwei Ansätze

Ich könnte mir rein von der Theorie her folgendes vorstellen: Ein Plugin hängt sich an den aktuell angeschauten Datenstrom dran und fängt an zu buffern. Das ganze solange bis Buffer voll. Bei vollem Buffer fällt das jeweils älteste Paket hinten runter. "Irgendwas" hat der VDR dafür (extra Klasse) deren Name mir gerade nicht einfallen will.

Man muss dann als nächstes die Pause-Taste fangen (eventuell ist das der Punkt an der eine erste Interface-Erweiterung fällig wird). Bei Pause wird der aktuelle Buffer-Stand auf die Platte geschrieben, und zwar im VDR-Aufnahmen-Format. Nun muss man diese begonnene Aufnahme "nur" noch dem VDR als seine eigene unterjubeln und ihm dann auch noch klar machen, dass diese Aufnahme in der Vergangenheit begonnen wurde, aber auf aktuelle Position vorgespult wurde. Auf diese Aufnahme wird nun im pausierten Wiedergabe-Modus gewechselt.

[quote]Original von Mreimer
"Irgendwas" hat der VDR dafür (extra Klasse) deren Name mir gerade nicht einfallen will./quote]

Du sucht nach der "ringbuffer.h"

>Man benoetigt ein Ausgabedevice welches den TS Stream puffert
>und bei Bedarf wird dieser in ne Aufnahme gewandelt
Ok, das ist aber noch nicht einmal die halbe Miete...

Wie willst du ohne Patch ermöglichen, dass auf Pause eben diese Aufnahme abgespielt wird?
Wie willst du es ohne Patchen ermöglichen, dass bei einer Aufnahme der aktuellen Sendung (die ja schon begonnen hat) die Daten aus dem LiveBuffer genommen werden?

>Bei Pause wird der aktuelle Buffer-Stand auf die Platte geschrieben,
>und zwar im VDR-Aufnahmen-Format.
Doch nicht nur bei Pause, sondern (spätestens ab da) laufend...
Und was passiert, wenn die Platte voll ist? Dann ist Ende mit der Wiedergabe?
Ohne Patchen kennt der VDR keine "dynamischen" Aufnahmen, bei denen der Anfang gelöscht wird.
Also: eigenen Player bauen und bei Pause starten.
Der Code würde sich sicher zu 99% mit dem im VDR decken.
Aber einfach durch Vererbung wird man ihm das nicht beibringen können - ist meist eh alles Private ;).
Also pflegt man doppelten Code. Auch nicht schön.

> Es ist schade, das im Bereich VDR die Patcherei derart überhand genommen hat
Finde ich auch
War aber doch eigentlich schon immer so!?!
Leider ist der VDR etwas starr designed.
Auf der anderen Seite kann man es wohl auch nie flexiebel genug gestalten, um alle Ideen ohne Patchen umzusetzen.

> Die Patch-Lösung würde ich dagegen links liegen lassen.
Feel free _not_ to use it

Es hieß doch das ein Patch nicht zu vermeiden ist. Aber das man den Patch so allgemein gestalten könnte, das er als allgemeine Schnittstellenerweiterung gilt und von kls in den VDR übernommen wird.

tiqq
Ein bischen Intelligenz muss man ins Plugin natuerlich einbauen, ich sehe aber bisher noch keine Hindernisse, die das Plugin nicht ohne Patchen und doppelten Code loesen koennte

helau: Auch die Bedienung? Wenn ich das richtig verstanden habe kann man direkt zurückspulen, aber auch nachdem man zurückgespult hat weiterzappen

Patch für 1.7.16 fertig machen (abschaltbar), in den Vdr einbauen, fertig.

Tut doch keinem weh, wenn es abschaltbar integriert wird.

Zitat

Original von Copperhead
helau: Auch die Bedienung? Wenn ich das richtig verstanden habe kann man direkt zurückspulen, aber auch nachdem man zurückgespult hat weiterzappen

Ist die Frage ob man das unbedingt haben muss. Der Buffer (ringbuffer) kann solange komplett losgelöst mitlaufen, bis die Pause-Taste gedrückt wird. Das triggert den Mechanismus, der aus dem Buffer-Inhalt eine Aufnahme baut. In der entstandenen Aufnahme kann dann nach Belieben gespult werden.

Die kurzfristige Lösung ist sicher, den Patch von Reel ans Laufen zu bekommen. Bei Reel verstehe ich nur zu gut, dass dort gepatcht wird. Die brauchen eben eine möglichst schnelle und einfache Lösung und wenn die durch Patchen des VDR am schnellsten zu bekommen ist, dann wird das umgesetzt. Von denen wird sicher keiner an kls herantreten um zu fragen ob Plugin-Schnittstelle X eingebaut wird und dann den entsprechenden Patch nach Diskussion erst mehrfach anpassen, bis er in den VDR wandert. Bei Reel braucht man schnelle Lösungen für die Kunden und die Community muss die Patches ja nicht verwenden. So kommt es auch, dass der VDR, den Reel verwendet, nicht mehr allzuviel mit dem "normalen" VDR zu tun hat.

In der VDR-Community dagegen sollte man sich, alleine schon um zukünftig Zeit sparen zu können, wohl etwas intensiver mit solchen Themen befassen. Ziel sollte es sein, dass die Basis-Software komplett ohne Patches an die Nutzer gegeben werden kann. Alles, was nicht im VDR direkt landen kann oder soll wird als Plugin umgesetzt. Wo Plugins nicht die nötigen Eingriffsmöglichkeiten haben, da sind diese nachzurüsten.

Das Livebuffer nicht direkt in den VDR wandert, hat kls ja schon deutlich gemacht. Ehrlich gesagt verstehe ich ihn an der Stelle auch, denn den meisten reicht die "normale" Timeshift-Funktion wirklich aus. Und um auch das einmal deutlich zu machen: Ich bin heilfroh, dass kls filternd darauf einwirkt, was in den VDR wandert. Die Software ist erstaunlich sauber programmiert und gerade die Tatsache, dass hier und da nach dem KISS-Prinzip gehandelt wird, gefällt mir sehr gut. Ich habe ja selber schon Patches für den VDR eingeschickt und war erstaunt, wie kls für eine vormals recht komplexe Lösung Tipps aus dem Ärmel zaubert, wie die Lösung simpel und verständlich wird.

Zitat

Die kurzfristige Lösung ist sicher, den Patch von Reel ans Laufen zu bekommen. Bei Reel verstehe ich nur zu gut, dass dort gepatcht wird. Die brauchen eben eine möglichst schnelle und einfache Lösung und wenn die durch Patchen des VDR am schnellsten zu bekommen ist, dann wird das umgesetzt. Von denen wird sicher keiner an kls herantreten um zu fragen ob Plugin-Schnittstelle X eingebaut wird und dann den entsprechenden Patch nach Diskussion erst mehrfach anpassen, bis er in den VDR wandert. Bei Reel braucht man schnelle Lösungen für die Kunden und die Community muss die Patches ja nicht verwenden. So kommt es auch, dass der VDR, den Reel verwendet, nicht mehr allzuviel mit dem "normalen" VDR zu tun hat.

Ich denke mal die wechseln nicht umsonst zur zur 1.7.x version

Just my 2ct ...
Ich würde auch immer ein Plugin bevorzugen, dass ohne Patch auskommt. Wie schon mehrfach beschrieben, muss die Aufnahme im Plugin ja möglich sein. Was spricht denn gegen einen extra livebuffer Player unabhängig von Pause timeshift Handling des vdr. Den livebuffer player könnte man dann auf eine beliebige Taste legen.

Lg
Joachim

ACK

ich stimme dem ebenfalls zu.

Erlaubt mir aber kur zu definieren, was ich als Komforteinbußen im Vergleich zur Mediaportal/mediacenter/technisat/loewe/Entertain und andern Receivern her kenne:
- beim zappen wird immer sofort mit aufgezeichnet
- man kann jederzeit an den Anfang des zappzeitpunktes zurück (i.d.r. max 90 min)
- wenn man einen timer programmiert von der laufenden Sendung, wird der timeshiftspeicher als aufnahme rückwirkend abgespeichert
- pause funktioniert zuverlässig ohne mehrsekündige verzögerung (was imho zur Zeit eigentlich gar nicht geht, insb. bei Xine)
- wie groß der maximale puffer ist wird in der Regel vorgegeben
- wenn ich umschalte muß ich nicht erst überlegen, ob ich die pausenaufnhame vergessen habe zu löschen (ja ein automatisches löschen gibt es bereits auch)
- es ist immer ein Bereich für die Timeshiftfunktion reserviert

Insbesondere das mit dem Rückspulen jederzeit während ich ein Programm schaue ist gold Wert. Noch nie Sport gesehen? oder die obligatorische Pinkelpause in der Werbung? Dafür ließen sich noch viele Beispiele finden, warum der viele User dieses Feature durchaus sehr praktisch finden.
Und ich rufe in Erinnerung, dass dies früher zu einem der meistgenutzten Erweiterungen gezählt hat.

Gruß