permanentes Timeshift - Livebuffer-Patch (neue Testversion 28.03.07)

Zitat

Original von thomas83

Ein möglicher Grund könnte sein, dass es nach dem Umschalten vielleicht sehr lange dauert, bis die Karte auf die neue Frequenz getuned hat.
Dauert das Umschalten innerhalb des selben Transponders auch ähnlich lange?
Du könntest mal mit dem Femon-Plugin schauen, wie lange es dauert, bis du ein Signal hast. (Einfach mal mit aktiven OSD von Femon umschalten und beobachten, bis wann LOCK, SIGNAL, CARRIER, VITERBI, SYNC kommen)

Im Log steht wohl nichts Ungewöhnliches?

Thomas

Alles anzeigen

soll ich das jetzt mit LB oder ohne testen?
ohne LB habe ich 1-1,5sec Umschaltzeit, und mit etwa 6-9, innerhalb eines Transponders ist es bei 4-6 sekunden

ich habe FEmon aktiviert, aber wie kann ich da sehen, wofür der VDR die Zeit braucht?

ich vermute, dass es immernoch am starten von Aufnahmen liegt, denn wen ich 'pause'/sofortaufnahme (ohne LB) drücke, dauert es ca. 5-6 sec bis das bild anhält.
woran könnte das liegen? wie lange dauert das bei euch?

Gruß Aron

Halllo Thomas83,

ich habe ein Bug gefunden, wusste nicht ob es ein LiveBuffer oder BigPatch problem ist habe es deshalb unter BigPatch gepostet :
http://www.vdr-portal.de/board/thread.php?sid=&postid=388946#post388946

Gruß
Viking

Tach Thomas!

Kann es sein, das bei aktivem LiveBuffer die anzeige auf dem GraphLCD nicht mehr richtig geht? Z.B. wenn ich eine VCD oder einen Film mit MPlayer abspiele, beibt die Anzeige vom TV-Program stehen!

Kann sein, dass das schon jemand gepostet hat, aber die suche hat bix gefunden und der Tread war mir zu lang!

Gruß

Toxic

Zitat

Original von Toxic-Tonic
Kann es sein, das bei aktivem LiveBuffer die anzeige auf dem GraphLCD nicht mehr richtig geht? Z.B. wenn ich eine VCD oder einen Film mit MPlayer abspiele, beibt die Anzeige vom TV-Program stehen!

Ich hatte das Problem bisher nicht, aber aber auch (noch) nicht den ganz aktuellen LB drauf... werde es mal testen, ebenso aus einer VDR-Aufnahme heraus.

Zitat

Original von thomas83
Hallo,

gerade neue Version 0.1.4 hochgeladen:
http://home.vrweb.de/bergwinkl.thomas/

Änderungen:

• rotes Dreieck bei Schnittmarken-Anspringen funktioniert wieder
• gelöschte Aufzeichnungen können nicht mehr mit der blauen Taste bzw. Play fortgesetzt werden
• möglicher Segfault beim Stoppen und danach sofort wieder Pause drücken behoben
• Es wird nicht mehr doppelt Umgeschaltet

Thomas

Alles anzeigen

Hoi Thomas.

Also erstmal wieder nen fettes Lob: der LiveBuffer ist äußerst gut und stabil. Allerdings hab ich noch Probleme entdeckt.

• Problem während Aufnahmen-Wiedergabe:
  Ich habe bei mir festgestellt, dass wenn eine Aufnahme gestartet/wiedergegeben wird, sich der LiveBuffer leider nicht stoppt und damit im Hintergrund für unnötige Arbeit sorgt. Die zeigt sich bei mir konkret in extremen Bild-Ton-Ruckeln
• Problem während Burn-Plugin
  Mein Burn-Plugin stürzt immer während des DVD-Author-Part ab, weil bedingt durch den LiveBuffer der Flaschenhals zur Festplatte nicht reicht -> Peng.
• Problem während DVD-Plugin
  Auch beim DVD-Plugin läuft der LiveBuffer weiter (obwohl unnötig aus meiner Sicht). Die Folge ist extremes Ruckeln und in der Log finden sich viele Einträge: "cAudioRepacker: skipped XXX bytes to sync on next audio frame" und "ERROR: XXXX ring buffer overflows"

All diese Dinge machten keine Probleme, wenn der LiveBuffer abgeschaltet ist. Würde mich über eine neue, verbesserte Version freuen.

Aber lass dir Zoit, is weihnachten!

mfg bn

Hi,

ist eigentlich mehr Rechnerleistung nötig, um den LiveBuffer Patch einzusetzten?

Hoi

Zitat

Original von thomas83
Wie gesagt handelt es sich bei dem LiveBuffer im Hintergrund nur um eine normale Aufzeichnung. Wenn dies bei dir zu Rucklern und dergleichen führt könnte es möglicherweise auch an deinen Festplatten bzw. DMA-Einstellungen liegen. Überprüf das doch mal mit hdparm.

Leider komme ich damit nicht weiter. Hab ich schon ausgereizt. ich weiß da nicht weiter

Zitat

Original von thomas83
Eigentlich habe ich es mit absicht so gemacht, dass bei einer Wiedergabe der LiveBuffer weiterläuft. Wenn dies aber zu Problemen führt, könnte ich das ja noch einstellbar machen.

Das fände ich sehr schön! Da DVD ja auch nur "eine Wiedergabe" für den VDR ist, würde sich der LB doch dabei auch abschalten, oder?

vielen Dank. bn

BTW. Es stürzt auch nicht das Burn-PLugin ab, sondern viel mehr der VDR (mit LiveBuffer) durch die Aktionen (dvdauthor/mkisofs), die das Burn-Plugin auslöst. Und dass dafür der LiveBuffer verantwortlich ist, behaupte ich, weil ich keine Probleme damit habe, wenn jener abgeschaltet ist und ich mkisofs/dvdauthor laufen lasse...

Hi

Ich hab festgestellt das er mit der C't Distri v4.5 also VDR 1.3.37 das compilen im zusammenhang mit dem LNB-Sharing batch nicht funktioniert.

Gruß

Peysche

Hallo,

Bugfinding

vdr-1.3.39 mit akt. Bigpatch:

Problem mit der neuen Info-Taste

Livebuffer eingeschaltet, es wurde seit vdr-Start keine Aufnahme abgespielt, also der Info-Buffer dafür ist leer, Info-Taste ==> Absturz.
Wenn dann eine Aufnahme ab-/angespielt wurde, werden bei Druck auf Info immer deren Daten angezeigt. Wird sie gelöscht, Info ==> Crash

MfG

Hi,

mal ne Frage: wieso wird wenn ich eine Größe von 25 MB einstelle (für etwa eine Minute ) neben der ersten Datei 001.vdr mit etwa 25 MB noch eine zweite Datei 002.vdr mit sogar fast 30 MB erstellt (config siehe sig). Bei Ramdisk ziemlich unangenehm...

Gtx.

Zitat

Original von thomas83
Habe gerade bei mir eine Größe von 25MB ausprobiert, und es wurde nur die 001.vdr mit ca. 25MB erstellt. Tritt das bei dir immer auf oder nur manchmal? Um es evtl. besser reproduzieren / nachvollziehen zu können, wäre es gut zu wissen, wie groß dein Ramdisk íst und welche Einstellungen bezüglich des LiveBuffers du hast.

Anscheinend tritt es nur bei einer Ramdisk auf.
[edit]und bei tmpfs - da hatte ich die Größe bis auf 52MB geändert aber war noch zu klein![/edit]

Aber ich hab LiveBuffer jetzt ganz aufgegeben. Wenn der Buffer auf Festplatte liegt gibt's Ruckler, bei tmpfs blockiert der ganze Rechner von Haus aus (Reaktion auf Tastendruck dauert mindestens 10 Sekunden,CPU-Belastung aber normal). Bei ramfs ging es komischerweise einigermaßen gut - und ohne dass ich etwas an LiveBuffer geändert habe hatte ich dann den gleichen Effekt wie bei tmpfs.

ramfs hatte ich in der fstab angelegt - Optionen sind eh keine möglich, einfach für /var/cache/vdr/buffer (das mit -b beim vdr-Start übergeben wurde).
Bei LiveBuffer habe ich Verhalten bei Pause auf ja und nein probiert (keine Änderung), Beibehalten auf nein (ist aber auch unerheblich gewesen).

Ich finde es seltsam dass der LiveBuffer solch Probleme macht. Ich kann gleichzeitig zwei normale Aufnahmen auf Festplatte machen und eine dritte anschauen, ohne dass es zu Rucklern kommt.

Zitat

Original von scovery
Ich finde es seltsam dass der LiveBuffer solch Probleme macht. Ich kann gleichzeitig zwei normale Aufnahmen auf Festplatte machen und eine dritte anschauen, ohne dass es zu Rucklern kommt.

hoi. also das kenne ich auch, aber bei livebuffer kommt es zu rucklern bis abstürzen, wenn noch mehr traffic auf der festplatte ist. deswegen musste ich den livebuffer leider wieder abschalten...

...

mfg bn

Hiho..

Habe nun den VDR 1.3.40 mit dem LiveBuffer 1.5 (im BigPatch) laufen. Ist stabil und auch brennen nebenbei geht ohne probleme. Es ist echt klasse....

Deswegen habe ich jetzt grad nochmal damit rumgespielt und nen Schmankerl-Vorschlag:
Wenn die Leiste eingeblendet wird, dann sieht man da ja auch "potentielle" Schnitte und Schnittmarken. Wenn man diese jetzt noch setzen und verschieben könnte und alles... und dann das ausgewählte speichern.... Oh=> das wäre High-End!

mfg bn

Zitat

Original von LightYear
Habe nun den VDR 1.3.40 mit dem LiveBuffer 1.5 (im BigPatch) laufen. Ist stabil und auch brennen nebenbei geht ohne probleme.

Und vorher auch die genannten Probleme? Interessant.
Welche VDR-Version war's zuvor? Welche Hardware?

Bei c't vdr 4.5 ist der Livebuffer-Patch noch in Version 0.1.3 enthalten. Da ich aber jetzt eh selbst comiliere sollte ich vielleicht doch die neueste Version 0.1.5 mal probieren? Über Änderungen zu dieser Version finde ich leider nichts hier oder auf der Webseite.

Thomas

Danke für die Nachfrage.
Ich hab's aufgegeben gehabt LiveBuffer zu benutzen da der VDR damit völlig unbrauchbar wird.
Mich würde interessieren wie Du tmpfs benutzt hast. Ich habe gerade eben jetzt einfach mal /dev/shm als LiveBuffer-Pfad angegeben (auf meinem unveränderten original ctvdr45 System, bei meinem anderen habe ich testweise LNBsharing mit drin, dass womöglich andere Nebeneffekte erzeugen könnte) und wieder ein anderes Problem. Jetzt tritt anscheinend keine Verdoppelung mehr auf. Statt dessen gibt's aber jetzt laufend (wenn die angegebene Größe des Puffers erreicht ist, aber nicht jedes Mal) kurze Aussetzer. Ein Blick ins LiveBuffer-Verzeichnis zeigt, dass nach dem Aussetzer das Verzeichnis komplett leer ist. Im Log ist mir nichts aufgefallen, außer dass ein Kanalwechsel angegeben wird ohne dass einer gemacht wurde! Ohne LiveBuffer sind keine unnötigen Kanalwechsel-Einträge da. Direkt vor dem fälschlichen Kanalwechseln sind auch keine anderen Aktivitäten gewesen:

Feb 15 21:49:58 [letzer vorheriger Eintrag]
Feb 15 21:50:53 localhost vdr[6818]: switching to channel 2
Feb 15 21:50:53 localhost vdr[7623]: recording thread ended (pid=7623, tid=802830)
Feb 15 21:50:53 localhost vdr[7622]: file writer thread ended (pid=7622, tid=786445)
Feb 15 21:50:53 localhost vdr[7621]: buffer stats: 60724 (1%) used
Feb 15 21:50:53 localhost vdr[7621]: removing /dev/shm/LiveBuffer/ZDF/index.vdr
Feb 15 21:50:53 localhost vdr[7621]: removing /dev/shm/LiveBuffer/ZDF/001.vdr
Feb 15 21:50:53 localhost vdr[7621]: removing /dev/shm/LiveBuffer/ZDF

Manchmal [edit] doch offenbar jedes Mal [/edit] setzt nach dem Aussetzer und dem Löschen überhaupt keine weitere Aufnahme mehr ein, erst wieder nach Kanalwechsel.
Zur Sicherheit habe ich tmpfs mit anderen Dateien vollgeschrieben, keine Probleme feststellbar. Liegt also eindeutig an LiveBuffer. Nach wie vor also alle möglichen überhaupt nicht nachvollziehbaren unkontrollierbaren verschiedenen Probleme.

Werde demnächst dann doch einmal VDR mit der neuesten Patch-Version selbst compilieren, werde berichten wenn ich etwas feststellen konnte.

[noch eine Feststellung]

Wenn ich nach dem Aussetzer und der nicht mehr erfolgenden Pufferung weiter auf dem Kanal bleibe und erst nach ein paar Minuten umschalte kann ich (reproduzierbar) feststellen, dass beim ersten Wechsel auf einen anderen Kanal danach keine Wiedergabe mehr statt findet (nochmaliges Umschalten ist erforderlich). Log:

Feb 15 23:02:08 localhost vdr[14130]: Text2Skin: channelInfo display update thread started (pid=14130, tid=3358732)
Feb 15 23:02:09 localhost vdr[6818]: switching to channel 2
Feb 15 23:02:09 localhost vdr[14131]: creating directory /dev/shm/LiveBuffer/ZDF
Feb 15 23:02:09 localhost vdr[14131]: recording to '/dev/shm/LiveBuffer/ZDF/001.vdr'
Feb 15 23:02:09 localhost vdr[14130]: Text2Skin: channelInfo display update thread ended (pid=14130, tid=3358732)
Feb 15 23:02:09 localhost vdr[6818]: switching to channel 2
Feb 15 23:02:09 localhost vdr[14131]: replay /dev/shm/LiveBuffer/ZDF
Feb 15 23:02:09 localhost vdr[14131]: playing '/dev/shm/LiveBuffer/ZDF/001.vdr'

Hat wohl mit aktivierten automatischen Replaymodues zu tun? Für was ist der eigentlich (gleiche Frage für Mindest-Benutzerinaktivität und Frameswait). Wäre vielleicht günstig auf der Download-Seite oder im Patch etwas dazu zu schreiben.
Wie die Suche gezeigt hat wurde mti Version 0.1.4 auch etwas gefixt wegen zweimaligen Umschalten. Ob das damit zusammmenhängt?