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

Zitat von Torsten73

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?

Alles anzeigen

Ich habe jetzt auch etwas mit tmpfs rumgespielt. Also, so wie ich das sehe, nimmt sich tmpfs immer nur die Hälfte des physikalischen RAMs. Wenn die Größe des tmpfs-Laufwerk größer ist als die Hälfte des physikalischen RAMs, wird der Rest auf die Swap-Partion geschrieben. Solange die Swap-Partition groß genug für Livebuffer und das Linuxsystem ist, sollte alles in Ordnung gehen. Deine Konstruktion mit video.00 und video.01 verstehe ich nicht ganz. Du brauchst einfach nur ein tmpfs auf irgendeinen mount point erstellen z.B /var/livebuffer und vdr diesen mount point mitgeben mit -b mitgeben. Der vdr muss natürlich Schreibberechtigung auf das Verzeichnis haben.

LG
Jolly

Nochmal zu Thorsten's Test

Zitat von Torsten73

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

Kann ich nicht bestätigen. Bei mir wird richtigerweise das Standbild angezeigt und beim Abspielen geht es an der entsprechenden stelle weiter, sowohl bei SD als auch bei HD.

Zitat

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

Das wird doch einiges mehr an Arbeit als gedacht. Man müsste ja immer die EPG Information abrufen, die zur aktuellen Stelle im livebuffer passt. Momentan würde ich das aber noch nicht einprogrammieren, um nicht zu weit weg von rmm Original zu kommen. Obwohl bei rmm schon lange nichts mehr in Richtung livebuffer gemacht wurde, mal sehen ...

Zitat

Fehler:
- Pause auf ZDFHD, kurz nach der Pause (ca 15s) sofort Wiedergabe gestartet, ergibt massive Klötzchen und Zwitscherton, der sich nicht behebt, erst nach erneuter Pause oder springen synct sich die Wiedergabe. Gilt nur kurz nach Beginn der ersten Pause, jede weitere Pause geht sogar ohne jegliche Klötzchen bei der Wiedergabe.

Kann ich jetzt auch für HD bestätigen. Bei SD Sender verhält sich der livebuffer aber normal. Ich habe aber keine Ahnung wie man das ändern könnte.

Zitat

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

Wie weiter oben schon beschrieben, soll der vdr aus dem livebuffer gehen, wenn zur aktuellen Zeit vorgespult wurde. Das klappt bei mir bei SD Sendern auch ganz gut. Bei HD Sendern wird aber gar nicht gespult. Ist das nicht ein allgemein bekanntes xine Problem ?

LG

Joachim

Momentan habe ich nicht viel Zeit, daher mal in Kürze:

Zitat von gnapheus

Ich habe jetzt auch etwas mit tmpfs rumgespielt. Also, so wie ich das sehe, nimmt sich tmpfs immer nur die Hälfte des physikalischen RAMs. Wenn die Größe des tmpfs-Laufwerk größer ist als die Hälfte des physikalischen RAMs, wird der Rest auf die Swap-Partion geschrieben. Solange die Swap-Partition groß genug für Livebuffer und das Linuxsystem ist, sollte alles in Ordnung gehen. Deine Konstruktion mit video.00 und video.01 verstehe ich nicht ganz. Du brauchst einfach nur ein tmpfs auf irgendeinen mount point erstellen z.B /var/livebuffer und vdr diesen mount point mitgeben mit -b mitgeben. Der vdr muss natürlich Schreibberechtigung auf das Verzeichnis haben.

Gut diese Möglichkeit war mir nicht bekannt. Da ich den yavdr nutze für die Tests, wäre es eine Überlegung dies Allgemein zu integrieren. Denn es gibt einen Fehler im Livebuffer, wenn mehrere Videoverzeichnisse für den VDR existieren. Z.b. video.00 und video.01. Wie schon beschrieben nutzt der VDR dann beide und erstellt einen Livebuffer Ordner, wobei im kleineren Laufwerk nur die Symlinks hinterlegt sind. Hier werden die alten Bufferfiles korrekt gelöscht, aber nicht im video.01, wo sich die eigentlichen Daten befinden. Diese bleiben bestehen und führen dann zu Problemen, insb. bei Verwendung von tmpfs (tmpfs wird bis zur max. Größe gefüllt und dann hilft nur noch Neustart des Systems).

Warum der LB überhaupt auf die Idee kommt auf allen Laufwerken sich zu verlinken verstehe ich auch nicht ganz.

Zitat von gnapheus

Kann ich nicht bestätigen. Bei mir wird richtigerweise das Standbild angezeigt und beim Abspielen geht es an der entsprechenden stelle weiter, sowohl bei SD als auch bei HD.

Der Fehler tritt bei allen Sendern auf, Frontend Xine, 1. Mal Pause wählen ergibt schwarzes Bild (bei Yavdr mit "NoSignal") nach der 2. Pause wird das Standbild gezeigt. Ist nicht schlimm, aber unschön.

Zitat von gnapheus

Wie weiter oben schon beschrieben, soll der vdr aus dem livebuffer gehen, wenn zur aktuellen Zeit vorgespult wurde. Das klappt bei mir bei SD Sendern auch ganz gut. Bei HD Sendern wird aber gar nicht gespult. Ist das nicht ein allgemein bekanntes xine Problem ?

Nun Spulen an sich geht schon, aber mit der Zeitanzeige stimmt bei 720p Sender was nicht. Die läuft zu schnell ungefähr mit Faktor 2. Ich hatte Dich so verstanden, dass wenn man über die Liveposition versucht hinauszuspulen (in die Zukunft Spulen geht ja nicht) soll die LB Wiedergabe beendet werden und das Livebild wieder kommen. Das ist nicht der Fall, statt dessen erhält man ein Standbild und die Zeitposition im Statusfenster zählt eifrig weiter, das darf gar nicht. Da ist also auch eine Kleinigkeit fehlerhaft. Probiere das alles mal mit aktivem Statusfenster, dann kann man das wunderbar sehen.

Noch etwas zum tmpfs:
Der tmpfs kann gar nicht in den Swap gelangen, da eine Plattenspeicher Voll Funktion vom VDR bei weniger als 512MB greift (siehe mein letztes Log). D.h. der tmpfs kann immer nur auf Memsize-512MB genutzt werden, selbst wenn ich size=100% definiere, denn der swap wird ja erst genutzt, wenn der Speicher nicht mehr reicht, aber es bleiben immer 512MB übrig. Ich hoffe ich habe das verständlich vormuliert?
Nun könnte ich daraus ableiten, dass man immer den tmpfs auf 100% setzten kann, denn der VDR selbst braucht immer irgendwas zwischen ca 350-800MB (nur geschätzt, wenn noch Firefox läuft) womit es also bei genügend Speicher durchaus auch mit 4GB schon für ca. 25min. reicht und bei 8GB locker 45 min.
Unter 64 Bit/4GB kann ich zumindest fast eine 3/4h puffern bei ARDHD und ca. 10-12Mbit. Dies ergebe rechnerisch bei 20 Mbit die maximal existieren immer noch die besagten 25min und das reicht eigentlich schon aus. Trotzdem bekommt meine SandyBridge Plattform 8GB verpasst

gda, wird der -b Parameter beim yavdr genutzt? Denn dann gäbe es die Probleme mit mehreren Videolaufwerken nicht. Man könnte ja pauschal das video.00 festlegen. Wenn jemand eine SSD nutzt muß er halt selber dran denken die tmpfs einzurichten.

Zitat von Torsten73

gda, wird der -b Parameter beim yavdr genutzt? Denn dann gäbe es die Probleme mit mehreren Videolaufwerken nicht. Man könnte ja pauschal das video.00 festlegen. Wenn jemand eine SSD nutzt muß er halt selber dran denken die tmpfs einzurichten.

Ich weiß gerade nicht um welchen -b Parameter es geht, aber warum siehst du denn nicht einfach nach?

Gerald

Zitat von gda

Ich weiß gerade nicht um welchen -b Parameter es geht, aber warum siehst du denn nicht einfach nach?

Na diesen hier:

Zitat von gnapheus

Deine Konstruktion mit video.00 und video.01 verstehe ich nicht ganz. Du brauchst einfach nur ein tmpfs auf irgendeinen mount point erstellen z.B /var/livebuffer und vdr diesen mount point mitgeben mit -b mitgeben. Der vdr muss natürlich Schreibberechtigung auf das Verzeichnis haben.

Ist ja nicht meine Konstruktion, sondern yavdr. Ich vermute Gnapheus meint damit einen Startparameter für den vdr der den LB auf "ein" fixes Verzeichniss definiert und nicht bei Verwendung von mehreren Festplatten auf alle verteilt. Und da ich nicht genau weiß mit welchem Script der VDR aufgerufen wird, würde ein Tipp mir viel Sucherei ersparen.
Wenn nicht dauert es halt länger bis ich es gefunden habe und den Tipp probiert habe. Ist auch nicht tragisch, fragen kann man ja

Zitat von Torsten73

Und da ich nicht genau weiß mit welchem Script der VDR aufgerufen wird, würde ein Tipp mir viel Sucherei ersparen.
Wenn nicht dauert es halt länger bis ich es gefunden habe und den Tipp probiert habe. Ist auch nicht tragisch, fragen kann man ja

Torsten73, das ist doch albern. Du brauchst doch keine Skripte untersuchen. Einmal

ps -ef|grep vdr

und du siehst doch mit welchen Parametern der vdr aufgerufen wurde.

Gerald

Zitat von Torsten73

Noch etwas zum tmpfs:
Der tmpfs kann gar nicht in den Swap gelangen, da eine Plattenspeicher Voll Funktion vom VDR bei weniger als 512MB greift (siehe mein letztes Log). D.h. der tmpfs kann immer nur auf Memsize-512MB genutzt werden, selbst wenn ich size=100% definiere, denn der swap wird ja erst genutzt, wenn der Speicher nicht mehr reicht, aber es bleiben immer 512MB übrig. Ich hoffe ich habe das verständlich vormuliert?
Nun könnte ich daraus ableiten, dass man immer den tmpfs auf 100% setzten kann, denn der VDR selbst braucht immer irgendwas zwischen ca 350-800MB (nur geschätzt, wenn noch Firefox läuft) womit es also bei genügend Speicher durchaus auch mit 4GB schon für ca. 25min. reicht und bei 8GB locker 45 min.
Unter 64 Bit/4GB kann ich zumindest fast eine 3/4h puffern bei ARDHD und ca. 10-12Mbit. Dies ergebe rechnerisch bei 20 Mbit die maximal existieren immer noch die besagten 25min und das reicht eigentlich schon aus. Trotzdem bekommt meine SandyBridge Plattform 8GB verpasst

Ich bin mir nicht sicher ob das 100% richtig ist. Du kannst über die size option beim mounten angeben wieviel Speicher die tmpfs-partition haben soll. Dieser Wert kann durchaus größer sein als der physikalische Ram. Meinem Verständnis nach wird zunächst der RAM bis zu 50% vollgeschrieben, dann geht es ab auf den swap Bereich. Ich habe bei meinem Test mit einer 5 GB tmpfs partition allerdings nicht gewartet bis 2 GB=50% meines RAMs voll waren. Vielleicht kannst du das ja nachholen.
Also mit

mount -t tmpfs -o size=5G tmpfs /var/livebuffer

und den vdr mit

vdr -b /var/livebuffer

aufrufen. Dabei muss swap+50%ram >> 5 GB sein und vdr zugriff auf /var/livebuffer haben.

LG

Joachim

Zitat von gnapheus

Ich bin mir nicht sicher ob das 100% richtig ist. Du kannst über die size option beim mounten angeben wieviel Speicher die tmpfs-partition haben soll. Dieser Wert kann durchaus größer sein als der physikalische Ram. Meinem Verständnis nach wird zunächst der RAM bis zu 50% vollgeschrieben, dann geht es ab auf den swap Bereich. Ich habe bei meinem Test mit einer 5 GB tmpfs partition allerdings nicht gewartet bis 2 GB=50% meines RAMs voll waren. Vielleicht kannst du das ja nachholen.

Wir haben beide Recht, bzw. bei Wege sind möglich ich zitiere mal die Ubuntu Wiki:

Zitat

Anstatt /media/tmpfs kann auch ein beliebiger anderer Ort eingefügt werden, an dem die Partition eingebunden werden soll. Die Option size=X%
legt den maximal abgezweigten Anteil des RAMs fest, den man belegen
darf und kann individuell angepasst werden. Anstatt Prozent kann man
auch eine absolute Zahl angeben (z.B. size=50m). Man sollte
bedenken, nicht zu viel RAM freizugeben, da man ansonsten Gefahr läuft,
sein System sehr stark auszubremsen (und zu viel auf die SWAP-Partition
ausgelagert werden muss).

Alles anzeigen

Ich habe immer size=x% verwendet, damit kann man nicht mehr Ram als vorhanden abzweigen, also für den Livebuffer max. nutzbarer Arbeitsspeicher = Arbeitsspeicher - 512MB (mind. freier Speicher für Aufnahmen), für 4GB Systeme wären dass dann 3500MB und 512MB blieben immer für das System übrig, zuzüglich des Swaps.

Dein Ansatz geht genauso, erzwingt aber u.U, mehr Arbeitsspeicher als
real verfügbar. Ergo wird der Swap in Anspruch genommen, was man aber
eigentlich vermeiden sollte.

Wird die size Option gar nicht verwendet, wird automatisch 50% maximal
vom Arbeitsspeicher zur Verfügung gestellt. Das wäre am wenigsten
empfehlenswert.

Zitat von gda

Torsten73, das ist doch albern. Du brauchst doch keine Skripte untersuchen. Einmal

Quellcode

1

ps -ef|grep vdr

und du siehst doch mit welchen Parametern der vdr aufgerufen wurde.

Alles anzeigen

Nun ich kenne diese Funktion noch nicht (dafür aber jetzt, danke). ABER ich will nicht wissen "wie" sondern "wo" der vdr in welchem Script gestartet wird , denn wenn Du den Paramteter nicht kennst, wirst Du ihn wohl kaum eingebaut haben, liege ich da richtig ?

Zitat von Torsten73

Nun ich kenne diese Funktion noch nicht (dafür aber jetzt, danke). ABER ich will nicht wissen "wie" sondern "wo" der vdr in welchem Script gestartet wird

Eigentlich wolltest du doch wissen "ob" er eingebaut ist. Der VDR wird mit dem Upstart-Skript /etc/init/vdr.conf gestartet. Parameter für den VDR befinden sich in dem File /etc/default/vdr und für die Plugins in den Files /etc/vdr/plugins/plugin-<plugin name>.conf.

Zitat von Torsten73

denn wenn Du den Paramteter nicht kennst, wirst Du ihn wohl kaum eingebaut haben, liege ich da richtig ?

Ich vielleicht nicht, aber das yaVDR-Team besteht aus deutlich mehr als einer Person.

Gerald

gda,
ich hatte in Erinnerung gehabt, dass Du den LB Patch eingebaut hast. Insofern habe ich nur Dich angeprochen ...
Fakt ist, der -b wird nicht benutzt. Ich habe mal q&d den -b in die /etc/default/vdr eingebaut, endgültig wäre logischerweise ein template oder das ganze Konfigurierbar zu machen? Vielleicht was fürs WebIF. Aber noch funktioniert das eh nicht. Und Du nutzt ja auch eine SSD + HDD insofern sind meine Versuche ja nicht umsonst.

gnapheus,
das sieht leider nicht gut aus, wenn man den -b Parameter mitgibt. es passiert folgendes:

• Es werden Symlinks im -b Pfad (hier /media/tmpfs mit richtigen Rechten) erzeugt, die auf /srv/vdr/video.01Buffer/xxxxx.ts verweisen (man beachte den Pfadnamen!)
• Ich bin nicht in der Lage den Livebuffer ausschließlich im -b Pfad speichern zu lassen
• wenn ich den srv/vdr/video.01 als -b angebe, geht der LB gar nicht, die Files werden nicht erzeugt (beide Ordner video.00 und video.01 beinhalten Symlinks auf video.01/LiveBuffer

Hast Du mal mit mehreren Video Verzeichnissen die Funktion von -b getestet? Ich kann Dich auch gerne mal auf den VDR lassen, wenn Du Dir das ansehen möchtest.

Gruß
Torsten

Zitat von Torsten73

gda,
ich hatte in Erinnerung gehabt, dass Du den LB Patch eingebaut hast. Insofern habe ich nur Dich angeprochen ...
Fakt ist, der -b wird nicht benutzt. Ich habe mal q&d den -b in die /etc/default/vdr eingebaut, endgültig wäre logischerweise ein template oder das ganze Konfigurierbar zu machen? Vielleicht was fürs WebIF. Aber noch funktioniert das eh nicht. Und Du nutzt ja auch eine SSD + HDD insofern sind meine Versuche ja nicht umsonst.

Mag ja alles sein, aber ich habe dafür im Moment keine Zeit. Es macht sich ja niemand die Mühe mir zu erklären was -b macht und ich habe im Moment eben keine Zeit mich da einzulesen und abzuschätzen welche Nebenwirkung ein mir unbekannter Parameter hat.

Gerald

Zitat von gda

Mag ja alles sein, aber ich habe dafür im Moment keine Zeit. Es macht sich ja niemand die Mühe mir zu erklären was -b macht und ich habe im Moment eben keine Zeit mich da einzulesen und abzuschätzen welche Nebenwirkung ein mir unbekannter Parameter hat.

Dann mußt Du so wenig Zeit haben, dass Du die Beschreibung des Parameters hier überlesen hast . Ich habe Ihn Dir sogar nochmals zitiert. Ich kannte ihn auch nicht, bis gnapheus ihn benannte. Aber was sollte der wohl für Nebenwirkungen haben, außer dass er den Speicherort für den Livebuffer definiert? War an der von uns gegebenen Beschreibung etwas Missverständlich? Ich denke nicht. Also tief durchatmen und alles ist wieder in Ordnung und bisher gibt es nichts was Sinn macht im yavdr zu ändern.

Problem ist halt nur, dass der Parameter nicht das tut was er soll, zumindest wenn man mehr als ein video Ordner/Laufwerk hat. Also vielleicht weiß Gnapheus ja was dazu. Ist halt ein kleiner Bug, genauso das fehlerhafte Aufräumen bei mehreren Laufwerken, der sich aber vermutlich selber behebt, wenn die Ordnerdefinition funktioniert.

Zitat von Torsten73

Zitat von »gda«



Mag ja alles sein, aber ich habe dafür im Moment keine Zeit. Es macht sich ja niemand die Mühe mir zu erklären was -b macht und ich habe im Moment eben keine Zeit mich da einzulesen und abzuschätzen welche Nebenwirkung ein mir unbekannter Parameter hat.

Zitat von Torsten73

Dann mußt Du so wenig Zeit haben, dass Du die Beschreibung des Parameters hier überlesen hast . Ich habe Ihn Dir sogar nochmals zitiert.

Stimmt, habe ich tatsächlich, sorry. Das müssen sich andere im Team ansehen, ob es hier zu Problemen mit Avahi, automounter, ... kommen könnte.

Gerald

Zitat von Torsten73

gnapheus,
das sieht leider nicht gut aus, wenn man den -b Parameter mitgibt. es passiert folgendes:

• Es werden Symlinks im -b Pfad (hier /media/tmpfs mit richtigen Rechten) erzeugt, die auf /srv/vdr/video.01Buffer/xxxxx.ts verweisen (man beachte den Pfadnamen!)
• Ich bin nicht in der Lage den Livebuffer ausschließlich im -b Pfad speichern zu lassen
• wenn ich den srv/vdr/video.01 als -b angebe, geht der LB gar nicht, die Files werden nicht erzeugt (beide Ordner video.00 und video.01 beinhalten Symlinks auf video.01/LiveBuffer

Hast Du mal mit mehreren Video Verzeichnissen die Funktion von -b getestet? Ich kann Dich auch gerne mal auf den VDR lassen, wenn Du Dir das ansehen möchtest.

Also bei mir funktioniert der -b Parameter tadellos. Aber ich benutze nicht yavdr, sondern einen Vanilla-vdr, der nur mit dem Livebuffer gepatched ist. Außerdem enthält die Version des Patches, wie ich sie verwende auch eine Änderung beim Erstellen des Dateinamens (wegen text2skin-Kompatibilität). Soweit wie ich das überblicke dürfte es also entweder an der yavdr-Version des Livebuffer-Patches oder an der Verzeichnisstruktur mit video.00 video.01 liegen. Ich tippe auf ersteres. Bei yavdr kann ich dir leider nicht helfen. Man müsste testweise vielleicht doch mal meine Version mit der geänderten Dateierstellung versuchen.

LG

Joachim

Deswegen ja die Frage ob Du das mit mehreren Video Laufwerken probiert hast. Bei Dir wird also der LiveBuffer nur in dem unter -b angegebenen Pfad angelegt. Trotz dem vorhanden sein von video.00 und video.01 oder mehr.
Dann kann ich im Bugtracker einen Eintrag machen. Ich wollte nicht die Pferde scheu machen, für einen Fehler, der nicht nicht am yavdr liegt. Auffallen tut der ja auch erst, wenn man einen anderen Ordner definiert und /oder mehrere Videoordner hat.

Danke für Deine Rückinfo.

Morgen,

bei mir legt der Livebuffer weder ein Verzeichnis noch einen Symlink noch irgendetwas an. Auch kann ich während des Sehen nicht zurückspulen oder Pause drücken ohne das eine Aufnahme gestartet wird. Habe ein tmpfs mit 6G über die fstab angelegt. Dürfte bei 8G ja auch komplett in dem RAM passen. Habe ich noch etwas vergessen einzustellen? Habe den -b Parameter auch auf /var/livebuffer gelegt und natürlich das tmpfs dahin mounten lassen.

mfg Kersten

Zitat von gda

Zitat von »gda«
Stimmt, habe ich tatsächlich, sorry. Das müssen sich andere im Team ansehen, ob es hier zu Problemen mit Avahi, automounter, ... kommen könnte.

Gerald

Ich habe gelesen, dass der livebuffer auf eurer Agenda für yavdr 0.4 steht. Wenn ihr noch etwas an der Codebasis ändert, wäre es nett dieses hier zu posten, so dass auch nicht yavdr'ler davon profitieren können. Ich freue mich auch schon auf die 0.4 .

Lg
Joachim

Zitat von GOTTMODUS

Morgen,

bei mir legt der Livebuffer weder ein Verzeichnis noch einen Symlink noch irgendetwas an. Auch kann ich während des Sehen nicht zurückspulen oder Pause drücken ohne das eine Aufnahme gestartet wird. Habe ein tmpfs mit 6G über die fstab angelegt. Dürfte bei 8G ja auch komplett in dem RAM passen. Habe ich noch etwas vergessen einzustellen? Habe den -b Parameter auch auf /var/livebuffer gelegt und natürlich das tmpfs dahin mounten lassen.

mfg Kersten

was bekommst Du mit diesen Ausgaben:

• df (wie sieht hier das tmpfs aus?)
• ps -ef | grep vdr (hier müsste -b /var/livebuffer erscheinen)

ich gehe davon aus, dass Du auch wirklich ein 64Bit Betriebsystem installiert hast, wenn Du eine 6GB tmpfs erstellst? ich bin mir nicht sicher, ob var für den Livebuffer so wirklich der passende Ort ist. Ich würde den eher im video.00, media oder tmp anlegen. Und der VDR braucht Zugriffsrechte.

Als ich gerade ein bischen an meiner Kernel config geschraubt habe bin ich über die Option "CONFIG_HIGHMEM64G" gestolpert. Die Hilfe sagt dazu

Select this if you have a 32-bit processor and more than 4 gigabytes of physical RAM.

Da ich noch auf 32Bit bin, aber ein bischen Ram liegen hatte gleich mal aktiviert und auf 8gb aufgestockt.
/proc/meminfo meldet nun

MemTotal: 8309364 kB
MemFree: 7795744 kB

Kann ich nun wirklich 8gb mit 32 Bit nutzen? Kann ich mir jetzt eine ramdisk oder tmpfs mit z.B. 6gb anlegen für den Livebuffer?

Zitat von Maniac

Kann ich nun wirklich 8gb mit 32 Bit nutzen? Kann ich mir jetzt eine ramdisk oder tmpfs mit z.B. 6gb anlegen für den Livebuffer?

Nein, das Limit pro Prozess bleibt bei 4GB, aber du kannst in der Summe eben mehr als 4GB bekommen.

Gerald