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

Toller Test!!
Und schönes Ergebnis.
an die Entwickler

Als nächstes versuche ich das ganze mit der Ramdisk.
Aber aufgrund meiner bisherigen Beobachtung vermute ich schon mindestens ein Problem, nämlich das Wachsen des Speicherbedarfs, wenn die Pause länger als eingestellt aktiv ist.
Frage, was passiert, wenn die Ramdisk (oder auch mal die normale HDD) voll ist?

Was mir noch aufgefallen ist, das springen mittels Farbtasten funktioniert wesentlich langsamer als bei normaler Wiedergabe. Ist nicht wirklich tragisch, aber ich kann es mir nicht erklären.

Zitat von gda

Warum den das? Keiner der Patches war gegen den VDR von yaVDR, sondern gegen den Vanilla. Der mit yaVDR gekennzeichnete Patch hat nur einen anderen Funktionsumfang aber trotzdem gegen Vanilla,

Die 2. Zeile des Zitats gehört ja auch noch dazu die hab ich nur nicht zitiert. D.h. der patch war gegen den Ext-Patch und darauf habe ich gewartet...

Frank

Hallo,

Ich hab mir den Patch von Carel mal ein wenig angeschaut und dabei ein paar kleine Aenderungen gemacht:
- Beautifier drueber gejagt
- LiveBuffer Setup Value und zusaetzliches PauseKey Handling entfernt (LiveBuffer wird abgeschaltet indem man LiveBufferSize auf 0 setzt)
- noch ein paar Kleinigkeiten

waere nett wenn die Entwickler sich das mal anschauen koennten und ggf dies einfliessen lassen ...

Zitat von helau

Hallo,

Zitat von helau

Ich hab mir den Patch von Carel mal ein wenig angeschaut und dabei ein paar kleine Aenderungen gemacht:
- Beautifier drueber gejagt
- LiveBuffer Setup Value und zusaetzliches PauseKey Handling entfernt (LiveBuffer wird abgeschaltet indem man LiveBufferSize auf 0 setzt)
- noch ein paar Kleinigkeiten

Zitat von helau

waere nett wenn die Entwickler sich das mal anschauen koennten und ggf dies einfliessen lassen ...

Welche Variante? Die mit, oder die ohne Text2skin-Anpassungen. Mir wäre es lieb wenn man das separat halten könnte.

Gerald

Zitat von gda

Welche Variante? Die mit, oder die ohne Text2skin-Anpassungen. Mir wäre es lieb wenn man das separat halten könnte.

Das sollte fuer extpngvdr1.7.17v1b9-lb10.diff.gz passen

Zitat von helau

Zitat von »gda«



Welche Variante? Die mit, oder die ohne Text2skin-Anpassungen. Mir wäre es lieb wenn man das separat halten könnte.

Zitat von helau

Das sollte fuer extpngvdr1.7.17v1b9-lb10.diff.gz passen

Mit der Antwort kann ich jetzt nichts anfangen. Es geht um die Änderungen, die gemacht wurden damit ein ungepatchtes Text2Skin nicht abstürzt. Bei uns ist Text2Skin gepatcht. Generell wäre natürlich erst mal ein Vanilla Patch besser. Erst im 2. Schritt sollte man den dann an die jeweilige Umgebung anpassen.

Gerald

Zitat von helau

- Beautifier drueber gejagt
- LiveBuffer Setup Value und zusaetzliches PauseKey Handling entfernt (LiveBuffer wird abgeschaltet indem man LiveBufferSize auf 0 setzt)

Ich verstehe nicht wozu das dienen soll? Das PauseKey Handling hat keinen Einfluss auf die Stabilität und macht die Sache sehr viel komfortabler.
Der Beautifier macht es schwieriger den Code mit eventuellen Änderungen von rmm zu vergleichen. Ich habe deshalb versucht soviel wie möglich von rmm zu übernehmen. Kannst du vielleicht etwas mehr zu den Kleinigkeiten sagen ?

LG

Joachim

Zitat von gnapheus

Der Beautifier macht es schwieriger den Code mit eventuellen Änderungen von rmm zu vergleichen. Ich habe deshalb versucht soviel wie möglich von rmm zu übernehmen. Kannst du vielleicht etwas mehr zu den Kleinigkeiten sagen ?

Auch wieder wahr!

Gerald

Zitat von gnapheus

Ich verstehe nicht wozu das dienen soll? Das PauseKey Handling hat keinen Einfluss auf die Stabilität und macht die Sache sehr viel komfortabler.
Der Beautifier macht es schwieriger den Code mit eventuellen Änderungen von rmm zu vergleichen. Ich habe deshalb versucht soviel wie möglich von rmm zu übernehmen. Kannst du vielleicht etwas mehr zu den Kleinigkeiten sagen ?

Da hab ich mich wohl unklar ausgedrueckt. Ich habe das zusaetzliche Setting von PauseKeyHandling (livebuffer) wieder weggenommen, und dafuer den Livebuffer davon abhaengig gemacht ob die LiveBufferSize > 0 ist.
Die Kleinigkeiten sind allesamt fuers Endergebnis irrelevant, und kann man vernachlaessigen wenn der Code eh nicht "gesaeubert" werden soll.

P.S: Man kann auch mit beautifier den Vergleich mit der RMM Source machen, man muss nur auch deren Code aufbereiten

Zitat von Torsten73

Als nächstes versuche ich das ganze mit der Ramdisk.
Aber aufgrund meiner bisherigen Beobachtung vermute ich schon mindestens ein Problem, nämlich das Wachsen des Speicherbedarfs, wenn die Pause länger als eingestellt aktiv ist.
Frage, was passiert, wenn die Ramdisk (oder auch mal die normale HDD) voll ist?

Ich meine, es gibt Dateisysteme (tmpfs??), die in der Ramdisk Arbeiten, bis diese voll ist, und danach auf die Platte ausweichen.

Gruß,
Hendrik

tmpfs funktionierte, ramfs irgendwie nicht. Bin noch nicht weiter dazu gekommen. Wobei das springen mit tmpfs nun wesentlich schneller ging. Was aber passiert, wenn bei tmpfs das ganze in den Swap ausgelagert wird habe ich noch nicht probiert.

IMHO weiß tmpfs nicht ob es in den RAM oder den Swap schreibt, da einfach nur Cache Speicher von Kernel anfordert . Hier steht einiges dazu geschrieben http://www.ibm.com/developerworks/library/l-fs3.html . Wenn das tmpfs volläuft, passiert wahrscheinlich etwas ähnliches wie wenn die video platte vollläuft. Was genau passiert weiß ich nicht. Aber Linux wird das sicherlich nicht mögen. Meine Systemplatte ist einmal vollgelaufen -> System friert ein. Das der livebufffer weiter aufnimmt, wenn man auf Pause drückt, ist bestimmt gewollt und macht auch Sinn. Mit dieser Funktion kann aber natürlich immer eine Ramdisk oder auch die Festplatte volllaufen.

Zitat

Folgende Funktionen sind merkwürdig:
- Pause auf ARD HD und AnixeHD ergibt bei erster Betätigung "kein Signal Infobild" beim 2. pausieren während der Bufferwiedergabe wid das Bild gezeigt wie erwartet

Zu den Problemen mit den HD Sendern kann ich nichts sagen. Hast du das gleiche Verhalten auch auf den SD Sendern?

Zitat

- Channel+/- funktioniert nicht während des Livebuffers, mit Cursor up/down hingegen schon

Das lässt sich sicherlich einfach ändern.

Zitat

- Im Livebuffermode sind die Zahlentasten nicht für den Livebuffer sondern Kanalwahl. Das dürfte gewollt sein?

Ja, ist gewollt. Das wurde sogar extra dazuprogrammiert.

Zitat

- im LB-Mode funktioniert die Info Taste nicht (keine Reaktion)

Das lässt sich auch ändern.

Zitat

- ein schnelles Spulen über die Liveposition hinaus beendet nicht das Spulen und wechselt in die Wiedergabe, da fehlt noch eine Erkennung

Bleibt der vdr also einfach stehen an Ende des livebuffers? Ich dachte, dass das bei mir der livebuffer wieder in das Livebild geht, wenn man bis zum Ende gespult hat. Vielleicht irre ich mich auch. Gibt es dort einen Unterschied zwischen HD und SD?

LG

Joachim

Zitat von gnapheus

Bleibt der vdr also einfach stehen an Ende des livebuffers? Ich dachte, dass das bei mir der livebuffer wieder in das Livebild geht, wenn man bis zum Ende gespult hat. Vielleicht irre ich mich auch. Gibt es dort einen Unterschied zwischen HD und SD?

Genau er wechselt in den Livemodus und verwirft den LB. Ich hätte erwartet, dass er statt dessen auf Pause LB wechselt.

Zitat von gnapheus

Zitat

Folgende Funktionen sind merkwürdig:

- Pause auf ARD HD und AnixeHD ergibt bei erster Betätigung "kein Signal Infobild" beim 2. pausieren während der Bufferwiedergabe wid das Bild gezeigt wie erwartet

Zu den Problemen mit den HD Sendern kann ich nichts sagen. Hast du das gleiche Verhalten auch auf den SD Sendern?

Alles anzeigen

Das gilt für alle Sender. Sowohl HD als auch SD. Ungünstiger sind da die Pixelfehler, wenn man die Pause weniger als 30-15s macht, dann hat man massive Artefakte (SD/HD) die sich nur durch springen beheben lassen. Warte ich 30s mit dem Wiedergabestart läuft alles normal.

Ich hatte gestern noch mal weiter bei Edit: [tmpfs] getestet. Ich hatte es nicht geschafft tmpfs über 95% zu bekommen, es gab keine Abstürze, aber die Zeitbalkenanzeige im LB Mode war merkwürdig. Ich hatte aber keine Fehler in der Wiedergabe sehen können. Getestet auf AnixeHD, da passten trotz 4GB Ram immer noch 30min und die Swapfile wurde nicht genutzt. Das gilt noch weiter zu testen, ich traue dem Braten noch nicht

Zitat von Torsten73

Zitat von »gnapheus«
Bleibt der vdr also einfach stehen an Ende des livebuffers? Ich dachte, dass das bei mir der livebuffer wieder in das Livebild geht, wenn man bis zum Ende gespult hat. Vielleicht irre ich mich auch. Gibt es dort einen Unterschied zwischen HD und SD?

Genau er wechselt in den Livemodus und verwirft den LB. Ich hätte erwartet, dass er statt dessen auf Pause LB wechselt.

It's not a bug, it's ... . Die Idee dahinter ist wohl, dass man von der Vergangenheit direkt in die Gegenwart spulen kann. Wenn man etwas verpasst hat, kann man ja wieder zurückspulen. Deswegen sind bzw. sollten auch alle Tasten so bedienbar sein wie im livetv.

LG

Joachim

Nochmal eine Korrektur, ich habe Blödsinn berichtet.

Zitat von gnapheus

Genau er wechselt in den Livemodus und verwirft den LB. Ich hätte erwartet, dass er statt dessen auf Pause LB wechselt.

das war Unsinn, er bleibt beim Vorspulen stehen (Pause), nur der Richtigkeit halber ... Sorry dafür.

Dann zum tmpfs:
folgender Eintrag in der fstab:

# <file system> <mount point>   <type>  <options>   	<dump>  <pass>
proc        	/proc       	proc	nodev,noexec,nosuid 0   	0
# / was on /dev/sda1 during installation
UUID=a47bd5de-baba-4282-8fd2-4fde730a71a2   	/                           	ext4	errors=remount-ro   	0   	1
# swap was on /dev/sda5 during installation
UUID=441882e7-d98e-4948-9224-6b4d8a7affed   	none                        	swap	sw                  	0   	0


# 2.HDD als Video Laufwerk
UUID=3d592c54-ebcc-4745-bad2-a1bec6362206   	/srv/vdr/video.01           	ext4	errors=remount-ro   	0   	1


# LB in den RAM verlagern
tmpfs                                       	/srv/vdr/video.00/LiveBuffer	tmpfs   defaults            	0   	0
#video.00 braucht nicht zwingend in dem tmpfs, hier liegen nur symlinks auf video.01
tmpfs                                       	/srv/vdr/video.01/LiveBuffer	tmpfs   defaults            	0   	0

Da hier eine ssd im Einsatz ist, möchte ich nicht, dass der LB auf eine SSD schreibt. Das die 2. HDD nun vorrangig genutzt wird, hatte ich anfangs nicht gewusst, so dass sich meine Befürchtungen als unbegründet erwiesen haben. (Lebenserwartung beim permanenten Schreiben auf SSD´s)
Nichts desto trotz würde eine LB im RAM Sinn machen, da somit die 2.HDD nicht in den Sleep Mode gesetzt werden kann. Somit braucht das System 4W mehr als es könnte.

Aber der LB im tmpfs ist nicht ohne Probleme.
Mit 4gb Ram und 30 min. LB Größe ergibt sich folgendes Bild nach einiger Laufzeit:

root@yavdr-dt:/home/torsten# df
Dateisystem       	1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sda1         	36841040   9394976  25574604  27% /
none               	1798280   	480   1797800   1% /dev
none               	1802500     	0   1802500   0% /dev/shm
none               	1802500   	304   1802196   1% /var/run
none               	1802500     	0   1802500   0% /var/lock
none               	1802500     	0   1802500   0% /lib/init/rw
tmpfs              	1802500     	0   1802500   0% /srv/vdr/video.00/LiveBuffer
/dev/sdb1        	1922858352  20100452 1805082300   2% /srv/vdr/video.01
tmpfs              	1802500   1802500     	0 100% /srv/vdr/video.01/LiveBuffer
/srv/vdr/video.01;/srv/vdr/video.00
                 	1959699392  29495428 1830656904   2% /srv/share/vdr
root@yavdr-dt:/home/torsten# free
         	total   	used   	free 	shared	buffers 	cached
Mem:   	3605004	2317588	1287416      	0  	56052	1970688
-/+ buffers/cache: 	290848	3314156
Swap:  	1648632      	0	1648632
root@yavdr-dt:/home/torsten#

Hier zeigt sich das erste Problem, der LB nutz den TMPFS aber der tmpfs erweitert sich nicht auf den Swap, obwohl kein Speicher mehr zur Verfügung steht. Dies sollte aber eigentlich bei tmpfs der Fall sein.

Ramfs geht übrigens gar nicht, damit verweigert der LB komplett seinen Dienst, d.h. er läßt sich nicht aktivieren und beim betätigen der Pause springt der VDR direkt zurück in den Live Mode.

Was passiert, wenn der Speicherplatz erschöpft ist:

• Während der normalen Live Wiedergabe merkt man erstmal gar nichts davon, versucht man nun die Pause zu wählen landet man sofort im Livebild
• Wechselt man den Sender, werden im video.00 die Dateien alle gelöscht und neu begonnen, im video.01 hingegen nicht. Ergo der Speicher wird nicht freigegeben. Es werden aber die Dateien beginnend mit 1 neu überschrieben, so dass der LB wieder mit Pause genutzt werden kann. Besser wäre hier, dass die alten Dateien trotzdem gelöscht werden. Da video.00 aber nur Symlinks hat könnte dies nur bei mehren video.0x Ordnern der Fall sein.
• Nun wird es kompliziert: Es werden 0001.ts - 0004.ts erstellt auf Pro7 dann springt der Sender wieder auf ARDHD zurück, der LB setzt mit 0005.ts seine Aufnahme fort. Ohne dass ich den Sender geändert hätte. Das Log meldet hier zwar dass 512Mb frei sein müssen, aber auch dass sollte beim TMPFS eigentlich auf 0 gesetzt werden. Ich vermute mal dass kann ich irgendwo einstellen?

Dazu mal das Log:

Apr
 20 22:09:42 yavdr-dt vdr: [9301] setting current skin to 
"anthra_1920_OS"
Apr 20 22:09:42 yavdr-dt vdr: [9301] loading 
/var/lib/vdr/themes/anthra_1920_OS-izeman.theme
Apr 20 22:09:42 yavdr-dt vdr: [9407] [live] INFO: attempt to listen on 
ip = '0.0.0.0'
Apr 20 22:09:42 yavdr-dt vdr: [9409] streamdev server thread started 
(pid=9301, tid=9409)
Apr 20 22:09:42 yavdr-dt vdr: [9301] ERROR: remote control XineRemote 
not ready!
Apr 20 22:09:42 yavdr-dt vdr: [9301] remote control LIRC - learning keys
Apr 20 22:09:42 yavdr-dt vdr: [9409] Streamdev: Listening (VTP) on port 
2004
Apr 20 22:09:42 yavdr-dt vdr: [9409] Streamdev: Listening (HTTP) on port
 3000
Apr 20 22:09:42 yavdr-dt vdr: [9407] [live] ERROR: Unable to load 
cert/key 
(/var/lib/vdr/plugins/live/live.pem//var/lib/vdr/plugins/live/live-key.pem):
 Datei oder Verzeichnis nicht gefunden
Apr 20 22:09:42 yavdr-dt vdr: [9410] LIRC remote control thread started 
(pid=9301, tid=9410)
Apr 20 22:09:42 yavdr-dt vdr: [9419] Text2Skin: menu display update 
thread started (pid=9301, tid=9419)
Apr 20 22:09:42 yavdr-dt kernel: [11163.292881] hda_codec: num_steps = 0
 for NID=0xc (ctl = Front Playback Volume)
Apr 20 22:09:52 yavdr-dt vdr: [9419] Text2Skin: menu display update 
thread ended (pid=9301, tid=9419)
Apr 20 22:09:52 yavdr-dt vdr: [9301] switching to channel 4
Apr 20 22:09:52 yavdr-dt vdr: [9710] receiver on device 1 thread started
 (pid=9301, tid=9710)
Apr 20 22:09:52 yavdr-dt vdr: [9712] TS buffer on device 1 thread 
started (pid=9301, tid=9712)
Apr 20 22:09:52 yavdr-dt vdr: [9301] recording to 
'/srv/vdr/video.00/LiveBuffer/00001.ts'
Apr 20 22:09:52 yavdr-dt vdr: [9301] playing 
'/srv/vdr/video.00/LiveBuffer/00001.ts'
Apr 20 22:09:52 yavdr-dt vdr: [9714] recording thread started (pid=9301,
 tid=9714)
Apr 20 22:09:52 yavdr-dt vdr: [9301] OSD size changed to 1920x1080 @ 1
Apr 20 22:09:52 yavdr-dt vdr: [9715] Text2Skin: channelInfo display 
update thread started (pid=9301, tid=9715)
Apr 20 22:09:52 yavdr-dt vdr: [9301] timer 1 (24 1908-2022 'Star Trek - 
Das nächste...~Der Rachefeldzug') set to event Don 21.04.2011 
19:10-20:15 'Star Trek - Das nächste...'
Apr 20 22:09:52 yavdr-dt vdr: [9301] timer 2 (4 0903-1005 'Rote 
Rosen~Folge 1018') set to event Don 21.04.2011 09:05-09:55 (VPS: 21.04 
09:05) 'Rote Rosen'
Apr 20 22:09:52 yavdr-dt vdr: [9301] timer 3 (4 1408-1510 'Rote 
Rosen~Folge 1019') set to event Don 21.04.2011 14:10-15:00 (VPS: 21.04 
14:10) 'Rote Rosen'
Apr 20 22:09:52 yavdr-dt vdr: [9710] TS continuity error (0)
Apr 20 22:09:52 yavdr-dt vdr: [9710] TS continuity error (3)
Apr 20 22:09:52 yavdr-dt vdr: [9710] TS continuity error (6)
Apr 20 22:09:52 yavdr-dt vdr: [9710] TS continuity error (11)
Apr 20 22:09:52 yavdr-dt vdr: [9710] cVideoRepacker: operating in H.264 
mode
Apr 20 22:09:53 yavdr-dt vdr: [9401] EPGSearch: search timer update 
started
Apr 20 22:09:53 yavdr-dt vdr: [9402] EPGSearch: timer conflict check 
started
Apr 20 22:09:53 yavdr-dt vdr: [9402] timer 1 (24 1908-2022 'Star Trek - 
Das nächste...~Der Rachefeldzug') set to event Don 21.04.2011 
19:10-20:15 'Star Trek - Das nächste...'
Apr 20 22:09:53 yavdr-dt vdr: [9402] timer 1 (4 0903-1005 'Rote 
Rosen~Folge 1018') set to event Don 21.04.2011 09:05-09:55 (VPS: 21.04 
09:05) 'Rote Rosen'
Apr 20 22:09:53 yavdr-dt vdr: [9402] timer 1 (4 1408-1510 'Rote 
Rosen~Folge 1019') set to event Don 21.04.2011 14:10-15:00 (VPS: 21.04 
14:10) 'Rote Rosen'
Apr 20 22:09:53 yavdr-dt vdr: [9402] EPGSearch: timer conflict check 
finished
Apr 20 22:09:53 yavdr-dt vdr: [9401] EPGSearch: search timer update 
finished
Apr 20 22:09:53 yavdr-dt vdr: [9710] SetBrokenLink: no GOP header found 
in video packet
Apr 20 22:09:54 yavdr-dt vdr: [9386] changing pids of channel 146 from 
6210+6210=27:6221=deu@3,6222=fra@3;6220=deu@106:0:6230 to 
6210+6210=27:6221=deu@3,6222=fra@3;6220=deu@106:6231=fra:6230
Apr 20 22:09:57 yavdr-dt vdr: [9715] Text2Skin: channelInfo display 
update thread ended (pid=9301, tid=9715)
Apr 20 22:11:01 yavdr-dt vdr: [9714] recording to 
'/srv/vdr/video.00/LiveBuffer/00002.ts'
Apr 20 22:11:04 yavdr-dt vdr: [9390] changing pids of channel 145 from 
255+255=27:0;259=deu@106:0:0 to 255+255=27:0;259=deu@106:0:0
Apr 20 22:11:24 yavdr-dt vdr: [9390] changing pids of channel 150 from 
255+255=27:0;259=deu@106:0:32 to 255+255=27:0;259=deu@106:0:32
Apr 20 22:11:25 yavdr-dt vdr: [9390] changing pids of channel 155 from 
511+511=27:0;515=deu@106:0:33 to 511+511=27:0;515=deu@106:0:33
Apr 20 22:11:25 yavdr-dt vdr: [9390] changing pids of channel 157 from 
1279+1279=27:0;1280=deu@106:0:0 to 1279+1279=27:0;1280=deu@106:0:0
Apr 20 22:11:25 yavdr-dt vdr: [9390] changing pids of channel 151 from 
1535+1535=27:0;1539=deu@106:0:37 to 1535+1535=27:0;1539=deu@106:0:37
Apr 20 22:11:33 yavdr-dt vdr: [9714] low disk space (0 MB, limit is 512 
MB)
Apr 20 22:11:33 yavdr-dt vdr: [9714] Deleting old livebuffer file #1 (1)
Apr 20 22:11:46 yavdr-dt vdr: [9390] changing pids of channel 1359 from 
532+532=27:0;850=pol@106,851=pol@106:0:0 to 
532+532=27:0;850=pol@106,851=pol@106:0:0
Apr 20 22:12:06 yavdr-dt vdr: [9714] recording to 
'/srv/vdr/video.00/LiveBuffer/00003.ts'
Apr 20 22:12:15 yavdr-dt vdr: [9389] frontend 1/0 timed out while tuning
 to channel 584, tp 110920
Apr 20 22:12:50 yavdr-dt vdr: [9390] changing pids of channel 605 from 
231+231=27:0;331=fra@106,431=eng@106:0:602 to 
231+231=27:0;331=fra@106,431=eng@106:0:602
Apr 20 22:13:12 yavdr-dt vdr: [9714] recording to 
'/srv/vdr/video.00/LiveBuffer/00004.ts'
Apr 20 22:13:14 yavdr-dt vdr: [9714] low disk space (0 MB, limit is 512 
MB)
Apr 20 22:13:14 yavdr-dt vdr: [9714] Deleting old livebuffer file #2 (1)
Apr 20 22:13:52 yavdr-dt vdr: [9390] changing pids of channel 153 from 
511+511=27:0;515=deu@106:0:33 to 511+511=27:0;515=deu@106:0:33
Apr 20 22:13:52 yavdr-dt vdr: [9390] changing pids of channel 154 from 
767+767=27:0;771=deu@106:0:34 to 767+767=27:0;771=deu@106:0:34
Apr 20 22:13:52 yavdr-dt vdr: [9390] changing pids of channel 156 from 
1023+1023=27:0;1027=deu@106:0:35 to 1023+1023=27:0;1027=deu@106:0:35
Apr 20 22:13:52 yavdr-dt vdr: [9390] changing pids of channel 152 from 
255+255=27:0;259=deu@106:0:32 to 255+255=27:0;259=deu@106:0:32
Apr 20 22:14:18 yavdr-dt vdr: [9714] recording to 
'/srv/vdr/video.00/LiveBuffer/00005.ts'
Apr 20 22:14:21 yavdr-dt vdr: [9389] frontend 1/0 timed out while tuning
 to channel 606, tp 111670
Apr 20 22:14:35 yavdr-dt vdr: [9390] changing portal name of channel 219
 from '' to 'Portal'
Apr 20 22:14:35 yavdr-dt vdr: [9390] changing name of channel 221 from 
'Sky Sport 1,Sport1;SKY' to 'Fu�ball ENG,;'
Apr 20 22:14:35 yavdr-dt vdr: [9390] changing name of channel 222 from 
'Sky Sport 2,Sport2;SKY' to 'Wrestling,;'
Apr 20 22:14:35 yavdr-dt vdr: [9390] changing name of channel 226 from 
'Sky Bundesliga,Sky Buli;SKY' to 'Mein Stadion,;'
Apr 20 22:14:35 yavdr-dt vdr: [9390] linking channel 219 from none to 
221 222 226
Apr 20 22:14:55 yavdr-dt vdr: [9714] low disk space (0 MB, limit is 512 
MB)
Apr 20 22:14:55 yavdr-dt vdr: [9714] Deleting old livebuffer file #3 (1)
Apr 20 22:15:24 yavdr-dt vdr: [9714] recording to 
'/srv/vdr/video.00/LiveBuffer/00006.ts'
Apr 20 22:16:19 yavdr-dt vdr: [9390] changing pids of channel 220 from 
767+767=27:0;771=deu@106,772=eng@106:0:32 to 
767+767=27:0;771=deu@106,772=eng@106:0:32
Apr 20 22:16:20 yavdr-dt vdr: [9390] changing pids of channel 159 from 
1023+1023=27:0;1027=deu@106:0:32 to 1023+1023=27:0;1027=deu@106:0:32
Apr 20 22:16:20 yavdr-dt vdr: [9390] changing pids of channel 158 from 
1279+1279=27:0;1283=deu@106,1284=eng@106:0:32 to 
1279+1279=27:0;1283=deu@106,1284=eng@106:0:32
Apr 20 22:16:20 yavdr-dt vdr: [9390] changing pids of channel 225 from 
1535+1535=27:0;1539=deu@106:0:32 to 1535+1535=27:0;1539=deu@106:0:32
Apr 20 22:16:29 yavdr-dt vdr: [9714] ERROR: 
/srv/vdr/video.00/LiveBuffer/00006.ts: Auf dem Gerät ist kein 
Speicherplatz mehr verfügbar
Apr 20 22:16:29 yavdr-dt vdr: [9714] recording thread ended (pid=9301, 
tid=9714)
Apr 20 22:16:41 yavdr-dt vdr: [9390] changing pids of channel 34 from 
210+210=2:220=deu@3,221=mis@3;225=deu@106:0:230 to 
210+210=2:220=deu@3,221=mis@3;225=deu@106:231=deu:230

Dabei fällt mir gerade ein Grund ein, warum der tmpfs sich nicht auf den swap erweitert, der Speicherbedarf wird ja dynamisch vergrößert, bis kein ram mehr verfügbar ist. Da aber der VDR erwartet, dass 512MB frei sein müssen, kommt der tmpfs gar nicht dazu mehr Speicher aus dem Swap anzufordern, da er ja bereits 100% also voll belegt meldet und der LB somit abbricht und keinen weiteren Speicher mehr anfordert.

Es geht doch etwas besser... Wenn man richtig liest. Die tmpfs ist per default immer auf 50% Arbeitsspeicher begrenzt. Deswegen waren bei mir auch nur ca. 1,8 GB zur Verfügung.

Einfach mal auf video.00 default, size=2% und video.01 auf 95% beschert mir nun knapp 3,4GB. Sollte jetzt selbst bei AnixeHD für 30 min. reichen (bei rund 11Mbit/s). Aber an die Sinnvolle Größe muß man sich rantasten, denn rund 800 MB braucht der yavdr wenn firefox und Co laufen. Und den Swap möchte ich eigentlich nicht nutzen. Den betrachte ich eher als Notreserve.

An dem Fehler, bei Speichermangel auf der HDD, ändert dies natürlich nichts. Aber es sieht so aus, dass man mit feintuning der tmpfs größe durchaus gut mit 4Gb arbeiten kann. Trotzdem ist eine 64Bit Installation hierfür eine interessante und vielleicht sinnvolle Möglichkeit. Die Zeit wird es zeigen.

Hat den mittlweile schon jemand anderes mit tmpfs experimentiert?

Knobel doch mal ein bisschen herum und baue doch mal einen Skript der die verschiedenen Stellgrößen für tmpfs und livebuffer alleine aus dem zur Verfügung stehenden freien Speicher ermittelt.

Gerald