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

Also kann ich das tmpfs 4gb groß machen für den Livebuffer?
Ist es denn möglich, ähnlich wie bei den video Verzeichnissen, 2 Verzeichnisse für den Livebuffer anzulegen?
Dann könnte man ja 2 tmpfs mit jeweils 3gb bauen.

Maniac,
man kann sich das Leben auch kompliziert machen. Wenn Du den LB im Ram nutzen möchtest dann wechsle auf ein 64Bit Betriebsystem. Alles andere ist nur gefummle und birgt mit Sicherheit auch noch andere Probleme. Oder begrenze auf 15min, dass sollte dann auch passen.
Eines ist sicher, der Livebuffer funktioniert nicht mit mehreren Videoverzeichnissen oder Ordnern. Der kennt nur einen Ordner. Bisher ...

Wenn das überhaupt nicht geht, dann könnte man auch alternativ einen USB Stick dafür verwenden, der sollte aber schon schön flott sein, am besten USB 3.0. Die gibt es auch ab 20 Euro und ein 8GB Stick reicht da auch. Wäre auch mal ein interessanter Test, wie lange der hält, vermutlich geht der eher in die Binsen als eine SSD, kostet dafür aber weniger. USB 2.0 geht auch, aber das Spulen läuft da merklich langsamer. Insbesondere weil die Sticks ansich häufig nur 1/3 oder noch viel weniger der USB 2.0 Spezifikation schaffen (3mb/write ,10mb/read ist bei low cost üblich)

gnapheus,
hast Du schon eine Idee für die Zeitanzeige im Replay Modus bei 720P ARD&ZDF ?
nochmal den -b Parameter mit mehreren Videolaufwerken getestet?

Es hat sich wieder etwas getan im reel svn bezüglich Livebuffer:

vdr1.7: fix crash in livebuffer
vdr1.7: fix switching channel while copying livebuffer data to recording
vdr1.7: corrected syslog output
vdr-1.7: livebuffer: switch to play if reached start/end of recording

Deshalb gibt es hier einen neuen Satz Patches:
vdr-1.7.18-livebuffer12-rmm: nur Änderung damit es mit einem vanilla vdr kompiliert
vdr-1.7.18-livebuffer12-yavdr: + Menu-Handling
vdr-1.7.18-livebuffer12-gnapheus: + Menu + fix für text2skin

LG

Joachim

PS:
In den Patches sind noch ein Paar Zeilen aus dem rmm-vdr drin für ReplayControll::ShowMode , die nicht mit #ifdef USE_LIVEBUFFER abgesetzt sind. Ich dachte diese Zeilen helfen vielleicht, bei der seltsamen OSD Darstellung. Tun sie aber nicht. Da ich die Patches aber schon fertig hatte, sind sie noch enthalten. Ich nehme sie im nächsten Release wieder raus.

An dieser Stelle : vielen Dank!

gnapheus,
danke für Deine Mühe.
Zu dem OSD Problem bei 720P Sendern, könnte dies etwas mit den Füllbits von ARD und ZDF zu tun haben? Ich bin mir nicht sicher, ob die nun standardmäßig herausgenommen werden? Das war irgendwo mal in einem Thread zu den ARD und ZDF Aufnahmen besprochen worden, weil man durch weglassen der Bits den Speicherbedarf von den Aufzeichnungen reduzieren kann.
Das was ich gefunden habe war das Tools TS Doctor welches diese Füll Bits entfernt.
Ist nur so ne Idee...

aktueller Stand beim Yavdr-unstable:

• Nutzen von mehreren video.xx funktioniert nun, die alten Dateien werden ordnungsgemäß gelöscht. Dank an anonymus, wer bist Du ?
• Weiterhin vorhanden ist die fehlerhafte Zeitanzeige bei 720p Sendern (hat ja auch keine Änderungen gegeben)
• "switch to play if reached start/end of recording" funktioniert weiterhin nicht, nun bekommt man ca. 1min vor Liveposition eine Zeitlupenwiedergabe, die man auch nur schwer verlassen kann (CPU Last? noch nicht geprüft), der vdr stürzt aber nicht ab.

8GB Ram mit 90% tmpfs und 1h LB Size haben bisher wunderbar funktioniert.

ach ich dachte das wäre von dir

Nee,nee, keine fremden Loorbeeren bitte, wenn ich was im bugtracker eintrage, dann auch unter meinem Namen, ich verstecke mich nicht. ich kann testen und analysieren aber nicht programmieren ... leider, deswegen würde mich auch interessieren, wer den Fehler gefunden hat und ob das vor allem nun yavdr spezifisch ist, oder allgemeingültig ist.

Hier stehen übrigens die Änderungen.

IMHO gibt es ein Schreibfehler im patch: CanelWritingBuffer <> CancelWritingBuffer

Carel

PS: danke für deine Arbeit Joachim!

witzig, es existiert beides im patch12, sowohl "canel" als auch "cancel". Ich verstehe den Code zwar nicht, aber das ließt sich tatsächlich komisch. Vielleicht hat hotzenplotz nochmal Lust und Zeit den geändert zu bauen, oder sollte es tatsächlich so gewollt sein...

kann ich gleich mal versuchen.
übrigens ist in testing-vdr auch vdr-1.7.18 für lucid.
incl. livebuffer.
gib mir 10 min.

Die Stoppuhr läuft sonst hole ich die Peitsche raus . Müssen die Plugins dafür auch neu bauen?

wird sich gleich zeigen

Torsten73 kannst testen.
läuft ohne neubau

Zitat von hotzenplotz5

Torsten73 kannst testen.
läuft ohne neubau

Also der livebuffer-Patch veraendert die API von Timers.h. Insofern sollte man vielleicht doch die Plugins neu bauen. Deshalb gibt es extra eine make.global, damit die plugins auch mit den richtigen headern kompiliert werden.

Ich fände es auch gut, wenn oben genannte Änderungen auch hier gepostet würde, damit alle etwas davon haben.

LG

Joachim

Deshalb habe ich ja den Link zu den Änderungen gepostet.

Ich habe keine verbesserung festgestellt. Aber auch keine verschlechterung. Also man kann problemlos an den Anfang des LB springen / spulen, er bleibt bei Zeitcode 0.00 stehen und startet sauber die wiedergabe. beim vorwärtsspringen / spulen über den Livepunkt aber hinaus kommt man nur bis ca 10s und dann endet es in 1 Bild alle 2-3 sekunden. Es dauert eine ganze weile dann läuft der LB wieder wieder weiter, und hat rund 15-20s Versatz zum LiveSignal.
Übrigens schießt dann die CPU Last hoch, beim core i5-2400s verbrät dann 100W statt 80W ...

Als Idee, könnte es sein, dass gleichzeitig aufnehmen und wiedergeben innerhalb der puffergröße des Wiedergabemoduls zu diesem Problem führt? müsste man nicht viel früher den LB verlassen? also nicht bei einer Zeitdifferenz von wenigen sekunden oder 0 sondern bei z.b. 15s oder eher?
Ich hoffe das habe ich verständlich erklären können. ich weiß nicht wie die wiedergabe eines streams funktioniert oder das device sich nennt, aber einen Puffer wird es dort bestimmt auch geben wie unter neutrino. und der wird vermutlich überlastet.

Edit: Ich komme mit Springen näher an die LiveGrenze dran als mit Spulen. geringster Wert waren bisher 20S idealster Wert beim Springen 5S.

Hi @all
Ich habe die Änderungen mit den symlinks gemacht

@]gnapheus
bei deiner Variante sollte es in livebuffer.c so aussehen damit die symlinks bei mehreren video.xx gelöscht werden

while(((idx.size() > maxSize) && (lastGet ? (lastGet > First()) : true) && (lastBuf ? (lastBuf > First()) : true)) || dropFile) {
			if(idx.front().number != lastFileNumber) {
				isyslog("Deleting old livebuffer file #%d (%d)", lastFileNumber, dropFile);
+				system(cString::sprintf("ls -l %s/d.ts | grep -- '->' | sed -e's/.*-> //' | xargs rm -rf", (const char *)bufferBaseName, lastFileNumber));  // for symlink video.xx
				unlink(cString::sprintf("%s/d.ts", (const char *)bufferBaseName, lastFileNumber));
				lastFileNumber = idx.front().number;
				dropFile=false;
			} // if
			idx.erase(idx.begin());
		} // if

&

bool cLiveRecorder::Cleanup(bool RemoveDir) {
	if(FileName())
	    if (RemoveDir)
+	    		if(-1 == system(cString::sprintf("ls -l %s/%s/* | grep -- '->' | sed -e's/.*-> //' | sed -e's/.......ts//' | xargs rm -rf", BufferDirectory,"LiveBuffer")))
+			return false;
+	    else
            		if(-1 == system(cString::sprintf("rm -rf %s/%s/*", BufferDirectory,"LiveBuffer")))
			return false;
	    else
            		if(-1 == system(cString::sprintf("rm -rf %s/*", FileName())))
			return false;
	return true;
}; // cLiveRecorder::Cleanup

Torsten73
Ich denke das Problem beim Vorspulen kommt vom xine Plugin mit xineliboutput funktioniert es.

Das Problem mit den symlinks bei separatem BufferDir (Parameter -b beim vdr Start) und mehreren video.xx sollte damit gelöst sein in videodir.c.

cUnbufferedFile *OpenVideoFile(const char *FileName, int Flags)
 {
   const char *ActualFileName = FileName;
+#ifdef USE_LIVEBUFFER
+  bool SepBufferDir = false;
 
   // Incoming name must be in base video directory:
+   if (strstr(FileName, VideoDirectory) != FileName) {
+     if (strstr(FileName, BufferDirectory) == FileName)
+        SepBufferDir = true;
+     else {
+#else
   if (strstr(FileName, VideoDirectory) != FileName) {
+#endif /*USE_LIVEBUFFER*/
      esyslog("ERROR: %s not in %s", FileName, VideoDirectory);
      errno = ENOENT; // must set 'errno' - any ideas for a better value?
      return NULL;
      }
+#ifdef USE_LIVEBUFFER
+     }
+#endif /*USE_LIVEBUFFER*/
   // Are we going to create a new file?
   if ((Flags & O_CREAT) != 0) {
      cVideoDirectory Dir;
+#ifdef USE_LIVEBUFFER
+     if (Dir.IsDistributed() && !SepBufferDir) {
+#else
      if (Dir.IsDistributed()) {
+#endif /*USE_LIVEBUFFER*/
         // Find the directory with the most free space:
         int MaxFree = Dir.FreeMB();
         while (Dir.Next()) {

Im Anhang Aktueller dpatch fur yavdr. mit meinen Änderungen und den letzten von rmm

r16605 | dirk | 2011-05-26 17:46:27 +0200 (Thu, 26 May 2011)
vdr1.7: call empty() if changing from backward trickmode to play in livebuffer mode

Endung.txt natürlich löschen!

Gruß Gerald

cool !
danke gst !
ist in unstable-vdr vdr-1.7.18-5yavdr5~natty
und in testing-vdr vdr-1.7.18-5yavdr5~lucid

hab vergessen dich im changelog zu erwähnen, ebenso gnapheus, wird nachgeholt ! damit man weiss wo es herkommt.

Zitat von gst

Hi @all
Ich habe die Änderungen mit den symlinks gemacht

@]gnapheus
bei deiner Variante sollte es in livebuffer.c so aussehen damit die symlinks bei mehreren video.xx gelöscht werden

Code

[...]
+				system(cString::sprintf("ls -l %s/d.ts | grep -- '->' | sed -e's/.*-> //' | xargs rm -rf", (const char *)bufferBaseName, lastFileNumber));  // for symlink video.xx
				unlink(cString::sprintf("%s/d.ts", (const char *)bufferBaseName, lastFileNumber));
[...]

So ganz glücklich bin ich mit dieser Lösung nicht, da unlink im Gegensatz zu rm wartet bis kein Prozess mehr auf die Datei zugreift und dann löscht.
Mich würde interesieren warum "rm" mit einer Liste funktioniert und "unlink" bei den symlinks nicht. Laut Dokumentation funktioniert "unlink" auch mit Symlink.

Zitat

@Torsten7
Ich denke das Problem beim Vorspulen kommt vom xine Plugin mit xineliboutput funktioniert es.

Also ich habe einähnliches Verhalten wit Thorsten auch mit xineliboutput bei HD-Sendern. Bei SD-Sendern ist bei mir alles in Ordnung.

Zitat

Im Anhang Aktueller dpatch fur yavdr. mit meinen Änderungen und den letzten von rmm

Code

r16605 | dirk | 2011-05-26 17:46:27 +0200 (Thu, 26 May 2011)
vdr1.7: call empty() if changing from backward trickmode to play in livebuffer mode

Ich werde demnächst auch eine aktualisierte Version mit den aktuellen Ändernungen hier einstellen.

LG

Joachim