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

>Früher konnte man noch definieren, ob man die AUfnahme auf die
>HDD erweitern soll, wenn der Puffer voll ist.

Es wird immer auf HDD aufgenommen.
Wenn man so lange in Pause verbleibt, dass die Zeit überschritten wird (ja, man konfiguriert nun die Zeit in Min, nicht MB), wird auch länger aufgenommen (Und beim Vorspulen dann gelöscht) so lange es noch Platz auf der Platte gibt.
Was noch nicht geht: Übernahme des Buffers in Aufnahmen.
Unschön: Auch ein Retune löscht den Buffer
Und überhaupt: Erste Version

Zitat

Original von tiqq
>Früher konnte man noch definieren, ob man die AUfnahme auf die
>HDD erweitern soll, wenn der Puffer voll ist.

Es wird immer auf HDD aufgenommen.
Wenn man so lange in Pause verbleibt, dass die Zeit überschritten wird (ja, man konfiguriert nun die Zeit in Min, nicht MB), wird auch länger aufgenommen (Und beim Vorspulen dann gelöscht) so lange es noch Platz auf der Platte gibt.
Was noch nicht geht: Übernahme des Buffers in Aufnahmen.
Unschön: Auch ein Retune löscht den Buffer
Und überhaupt: Erste Version

Alles anzeigen

nabend tiqq,

also ist LiveBufferSize (30) in minuten ?

EDIT:

hier der patch inklusive buffer einstellung:

>also ist LiveBufferSize (30) in minuten ?
Zumindest Default (Setup.LiveBufferSize ist in Minuten)

maxSize = Setup.LiveBufferSize * 60 * DEFAULTFRAMESPERSECOND;

Und wenn es sich um Material mit DEFAULTFRAMESPERSECOND handelt.

Zitat

Original von tiqq
>also ist LiveBufferSize (30) in minuten ?
Zumindest Default (Setup.LiveBufferSize ist in Minuten)

Code

maxSize = Setup.LiveBufferSize * 60 * DEFAULTFRAMESPERSECOND;

Und wenn es sich um Material mit DEFAULTFRAMESPERSECOND handelt.

ok danke, dann ists im oben geposten patch richtig mit "min" ..

P.S.:

Zitat

Original von tiqqUnschön: Auch ein Retune löscht den Buffer

wenn du damit meinst, wenn man den aktuellen sender nochmal in der senderliste anwählt, das der sender neu "getunt" wird, dann ist das ein "bug" im vdr. Hat nichts mit dem patch zutun.

um das zu verhindern, einfach das (menu.c):

eOSState cMenuChannels::Switch(void)
{
  if (HasSubMenu())
     return osContinue;
  cChannel *ch = GetChannel(Current());
  if (ch)
     return cDevice::PrimaryDevice()->SwitchChannel(ch, true) ? osEnd : osContinue;
  return osEnd;
}

ändern in:

eOSState cMenuChannels::Switch(void)
{
  if (HasSubMenu())
     return osContinue;
  cChannel *ch = GetChannel(Current());
  if (ch && ch->Number() != cDevice::CurrentChannel())
     return cDevice::PrimaryDevice()->SwitchChannel(ch, true) ? osEnd : osContinue;
  return osEnd;
}

so wirds auch in der release version von extchannelmenu sein

Copperhead

Muss ich den lifebufferpatch vor Deinem ExtP anwenden? Ansonsten bekomme ich rejects. Oder anders gefragt, baust Du den patch noch in den Extp ein?

Grüsse
TheChief

Momentan ist es ehr entweder oder. Sobald ich aber sicher weiß, das der Patch funktioniert und es nicht mehr jede halbe Stunde eine neue Version gibt, kommt der natürlich wieder in den Extensionpatch.

Wenn du natürlich Rejects selber auflösen kannst, sollte das gar kein Problem sein, den jetzt schon manuell einzubasteln.

Zitat

Original von Copperhead
Momentan ist es ehr entweder oder. Sobald ich aber sicher weiß, das der Patch funktioniert und es nicht mehr jede halbe Stunde eine neue Version gibt, kommt der natürlich wieder in den Extensionpatch.

Wenn du natürlich Rejects selber auflösen kannst, sollte das gar kein Problem sein, den jetzt schon manuell einzubasteln.

Danke! Dann warte ich mal ab, bisher ging es ja auch ohne.

Schade dass nicht der Arbeitsspeicher genutzt wird. Da heutzutage für den Vdr im Schnitt nur rund 600 MB Arbeitsspeicher genutzt werden bleiben im Schnitt locker 400-2500MB RAM ungenutzt (32bit Mode), und kann man seine HDD schonen wenn erst der Arbeitsspeicher genutzt wird soweit verfügbar und dann erst die HDD dazugenommen wird. Denn bei Systemen mit 2-4GB heutzutage wäre das bestimmt begrüßenswert.

Aber wie gesagt toll, dass da überhaupt was entwickelt wird.

@Thorsten73
Du kannst doch einfach ein Ramdisk als Bufferverzeichnis nehmen. Das Verzeichnis wird mit -b beim vdr Start übergeben.

An livebuffer4.diff gefällt mir persönlich nicht, dass die Struktur von cMenuSetupRecord ohne "ifdef USE_LIVEBUFFER" umgebaut wird, nur damit der Eintrag "LiveBufferSize (min)" ein und ausgeblendet wird. Ich würde die Einträge statisch halten ( siehe diff im Angang alternativ zu livebuffer4 ).

LG

Joachim

Gute Morgen,

ich hab gerade mal livebuffer5.diff auf den yavdr 1.7.16 losgelassen und die Rejects manuell aufgelöst.

Kompiliert auch wunderbar durch, im Menü lässt sich der livebuffer konfigurieren und im LiveBuffer-Verzeichnis nimmt er fleissig auf. Sobald ich allerdings "Pause" drück stürzt der VDR mit folgendem Syslog-Eintrag ab:

vdr[3440]: segfault at 0 ip 002107a0 sp bfa31638 error 4 in libc-2.11.1.so[19d000+153000]

Trotzdem ein super Ansatz!

Zitat

Trotzdem ein super Ansatz!

Ohne die Euphorie bremsen zu wollen, ich finde den Ansatz schlecht(aus der Sicht des Distributors).
Die komplette Funktionalitaet koennte man auch in ein Plugin packen, anstatt am VDR rumzupatchen ...

Zitat

Original von helau
Ohne die Euphorie bremsen zu wollen, ich finde den Ansatz schlecht(aus der Sicht des Distributors).
Die komplette Funktionalitaet koennte man auch in ein Plugin packen, anstatt am VDR rumzupatchen ...

Volle Zustimmung. Worst-Case braucht es eine Erweiterung der Plugin-Schnittstelle. Ein Patch, der diese erweitert, hätte aber durchaus eine Chance in den VDR übernommen zu werden.

helau,
ich frage mich nur seit Monaten warum niemand der User, die Plugins schreiben können dazu Lust hatten? Oder warum KLS sich dieses doch durchaus wichtigem Feature angenommen hat?
Die Antwort darauf ist wie immer, wir sehen dies hier als Hobby an und jeder macht das wozu er sich berufen fühlt.
Anders bei RMM, da sitzen wahrscheinlich eher die User im Nacken, denn wer gibt über 1000€ für einen Receiver aus, der noch nicht mal die Grundfunktionen des Timeshifts beherrscht?

KLS hat sich immer gegen den Livebuffer ausgesprochen, korrigiert mich wen ich Unsinn schreibe, und der Patch erfordert bei jeder neuen DR Version eine neue Anpassung, was beim Plugin vermutlich weniger Arbeit macht? Oder warum ist ein Plugin sonst zu bevorzugen?

Zitat

Original von Torsten73
Anders bei RMM, da sitzen wahrscheinlich eher die User im Nacken, denn wer gibt über 1000€ für einen Receiver aus, der noch nicht mal die Grundfunktionen des Timeshifts beherrscht?

Timeshift kann VDR schon immer. Als im Sinne von "Ich schaue Sendung und drücke Pause um später weiterzuschauen".

Zitat

KLS hat sich immer gegen den Livebuffer ausgesprochen, korrigiert mich wen ich Unsinn schreibe, und der Patch erfordert bei jeder neuen DR Version eine neue Anpassung, was beim Plugin vermutlich weniger Arbeit macht? Oder warum ist ein Plugin sonst zu bevorzugen?

Wenn die nötige Änderung der Plugin-Schnittstelle in den VDR wandert, dann wird diese für jede VDR-Version automatisch nachgezogen. Das Plugin dagegen wird nur noch angefasst, wenn Features hinzkommen oder Bugs gefixt werden.

Davon abgesehen ist Patchen eines fertigen Produkts immer schlecht. Das anzustrebende Ziel sollte sein, dass der VDR überall ganz ohne Patcherei läuft. Leider hat sich im Bereich VDR, wie in keinem anderen OSS-Projekt, die Patcherei ziemlich festgefahren.

Zitat

Original von helau

Ohne die Euphorie bremsen zu wollen, ich finde den Ansatz schlecht(aus der Sicht des Distributors).
Die komplette Funktionalitaet koennte man auch in ein Plugin packen, anstatt am VDR rumzupatchen ...

Na, dann mach _du_ es doch besser - ohne den VDR zu patchen....

Es geht nicht darum, das ganze *ohne* Patch zu lösen. Das wird vermutlich auch nicht möglich sein. Ein Patch, der die nötige Schnittstelle bereitstellt, wird fällig werden.

Ziel sollte sein, dass der Teil, der in den VDR gepatcht wird, so allgemein gehalten wird, dass er ohne Probleme als Erweiterung der Plugin-Schnittstelle direkt in den VDR wandern kann.

Allerdings ist das ganze IMHO Zukunftsmusik. Noch funktioniert die hier diskutierte Patch-Lösung nicht sauber. Wenn die aber funktioniert, wäre es optimal, wenn man das ganze dann in Richtung Plugin weiterentwickelt.

Zitat

Original von tiqqNa, dann mach _du_ es doch besser - ohne den VDR zu patchen....

Wuerde mich die Funktionalitaet interessieren, dann haette ich dies schon laengst gemacht. Wenn sich schon jemand die Muehe macht dies zu realisieren, sollte er die dazu verfuegbaren Schnittstellen nutzen, und nicht VDR patchen.

Zitat

Original von helau
Wuerde mich die Funktionalitaet interessieren, dann haette ich dies schon laengst gemacht. Wenn sich schon jemand die Muehe macht dies zu realisieren, sollte er die dazu verfuegbaren Schnittstellen nutzen, und nicht VDR patchen.

Moin Helmut,

würde ein Feature Request für Gen2VDR was bewirken

Zitat

Original von helau

Wuerde mich die Funktionalitaet interessieren, dann haette ich dies schon laengst gemacht. Wenn sich schon jemand die Muehe macht dies zu realisieren, sollte er die dazu verfuegbaren Schnittstellen nutzen, und nicht VDR patchen.

Nur 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.

>Wuerde mich die Funktionalitaet interessieren
Dann haben wir zumindest das gemeinsam - ich hab es auch noch nie gebraucht