Beiträge von UFO

Zitat

Original von nextlevel

Find ich auch. Ich habe auch noch nie verstanden warum bei LinVDR /video0 nicht in einer separaten Partition angelegt wird.

Weil es bei einem System, das nur für vdr benutzt wird, doch völlig egal ist, ob die root-Partition voll läuft oder nicht. Da passiert nämlich gar nichts!

Edit:
Außerdem kann der User vdr die Platte gar nicht vollschreiben, da üblicherweise eine gewisse Zahl von Blocks für root reserviert sind. (Weiß allerdings nicht, ob linvdr das auch so macht.)

CU
Oliver

Zitat

Original von Torsten/WarEagle
Half Duplex wird kommen weil du vermutlich einen Switch dran hast?

Anders herum:
ein Hub kann nur half duplex, ein Switch kann sowohl full als auch half duplex.

Gruß
Oliver

Zitat

Original von boardman

Nur um sicherzustellen, daß wir nicht an einander vorbei reden...
Ich mache kein Timeshift, sondern sehe online - damit werden die Bilddaten in den Speicher geladen und dann wieder auf die DVB Karte geschickt... (keine Plattenzugriffe)
ISt das so richtig?

Was die Menge der übertragenen Daten zwische Karte und PC angeht, macht es aus Sicht der DVB-Karte keinen Unterschied, ob Du Timeshift oder Liveview bei gleichzeitiger Aufnahme verwendest. Die Daten gehen in beiden Fällen erst zum PC und anschließend wieder zurück.

Zitat

So und was ist nun anderst wenn ich eine andern Kanal live sehe... doch eigendlich nur ggf. die Datenrate...

Das damit CPU und Datenbus belegt sind ist mir schon klar...

Und das ist eben der Unterschied! Schaust Du einen anderen Kanal an, ohne aufzunehmen, werden
- die aufgenommenen Daten nicht zurück zur DVB-Karte und
- das gesehene Programm nicht an den PC
übertragen. -> geringere Systemlast.

Zitat

Daraus resultiert also: 2 mal Pro7 aufnehmen + PRo 7 live sehen = zu hohe Datenrate
2 mal Pro7 aufnehmen und RTL live sehen = grade so nicht zu hohe Datenrate...
Ist das so richtig?

So ungefähr, wobei "zu hoch" halt systemabhängig ist.

Außerdem wäre noch anzumerken, daß das mehrfache Aufnehmen eines Kanals nur das Filesystem höher belastet. Die Daten werden nicht mehrfach von der DVB-Karte auf den PC übertragen (wäre ja auch ziemlich unsinnig).
Wenn Du die Datenübertragung von der Karte auf den PC testen möchtest, mußt Du verschiedene Kanäle gleichzeitig aufnehmen.

Gruß
Oliver

Zitat

Original von jarny

Die Erklärung hat UFO weiter oben schon gegeben. Warum das so implementiert wurde lässt sich nur mutmaßen. Ich glaube, dass damit das Timeshift gelöst wird. Man kann über den Umweg des Hauptspeichers bzw. Festplatte den Mpeg-Datenstrom beliebig anhalten und fortsetzen.

So ist es. (Hatte ich aber auch schon geschrieben.) Wenn man das anders machen würde, könnte man kein Timeshift realisieren. Der Preis für Timeshift ist eine höhere Systemlast.

Ich weiß, das hier ist das linvdr-Forum, aber...
Wenn man vdr selbst kompiliert, kann man auch in vdr/dvbdevice.c die Zeilen

#define DO_REC_AND_PLAY_ON_PRIMARY_DEVICE 1
#define DO_MULTIPLE_RECORDINGS 1

auskommentieren. Dadurch wird Timeshift deaktiviert, und vdr läuft auch auf einem langsamen System.

Zitat

PS: Ich finds schade, dass VDR nicht die Signalstärke und Signalqualität des Transponders anzeigt. JEDE Windowssoftware hat eine solche Anzeige und man konnte bei Bildstörungen sofort sehen ob man bei schlechtem Wetter und schwachen Transponder ein Empfangsproblem hat oder etwas anderes das Problem ist. Gibt der DVB-Treiber diese Info nicht her oder ists im VDR unterschlagen?
Ich find solche Anzeigen jedenfalls immer hilfreich.

Für so etwas gibt es den Tech-Patch (ist der in linvdr nicht enthalten?). Wenns es ein Kommandozeilen-Tool sein darf, kann man auch einfach 'femon' aus DVB/apps/szap verwenden. Kann man parallel zu vdr auf einer Konsole laufen lassen. Reicht zu Testzwecken völlig aus.

Gruß,
Oliver

Hallo,

mit Deiner Hardware sollte das problemlos funktionieren.

Hast Du überprüft, daß der Stecker des Empfängers wirklich richtig eingesteckt ist? Es wäre nicht das erste Mal, daß sich der Stecker nicht ganz einschieben läßt, weil die Karte etwas schräg eingebaut wurde. Dann funktioniert es nicht.

roscho, freaky:
Ist alles im Prinzip schon richtig, av7110_loadkeys wird jedoch bei der C'T-Distribution nicht mehr benötigt, denn das Remote-Plugin 0.2.0 lädt automatisch eine entsprechende Keymap...

Gruß
Oliver

Hi,

soviel ich weiß, wird der NMI bei PCs normalerweise überhaupt nicht genutzt.
Klingt verdächtig nach einem Hardwarefehler.

Versuch mal folgendes:
- Speichertest: memtest86 einige Stunden laufen lassen.
- Alle Karten herausnehmen und einzeln wieder einbauen. Sicherstellen, daß sie richtig im Sockel sitzen!
Nach dem Einbau einer Karte prüfen, ob der Fehler wieder auftaucht.
- Netzteil tauschen.

Gruß
Oliver

Zitat

Original von white-
Das war mir klar. Die ersten beiden Timer liefen ja auf dem selben Transponder. Also haetten sie auch auf einem Device aufgenommen werden sollen. Dem war aber nicht so, denn sonst haette der 3. Timer funktioniert.

BR-Alpha und RTL liegen nicht auf demselben Transponder. Transponder ist nicht gleich Polarisationsebene.

CU
Oliver

Zitat

Original von jarny

Deine oben zitierte Erklärung versteh ich nicht ganz. Ich glaube kaum, dass die Daten beim Betrachten des gleichen Kanals anders behandelt werden als Daten eines anderen Kanals.

Doch, genau das passiert!

Zitat

Da werden glaub ich sog. Filter in der Kartenhardware gesetzt und so die Datenströme gelenkt. Der Kanal den man anschaut bleibt in der Karte und wird direkt in den Mpeg-Dekoder übertragen. Wenn man den gleichen Kanal aufnimmt, wird er halt auch in den Speicher übertragen und von dort auf Platte geschrieben.

Was ich geschrieben habe, stimmt. Man kann sich leicht davon überzeugen, indem man einen Blick ins Logfile wirft. Dort stehen Meldungen wie "transfer thread started", "transfer thread stopped". Der Kanal wird nur dann kartenintern behandelt, wenn er nicht aufgezeichnet wird.

CU
Oliver

Zitat

Original von kuehnch
Vor einiger Zeit hatte ich mal diverse Probleme mit doppelten Eingaben, welche hier offiziell als keybdev-Probleme besprochen wurden und werden. Eine Lösung war bislang die Kompilierung des entsprechenden Event-Features als Modul und dessen Deaktivierung. Mit dem Kernel 2.6.0 scheint keybdev nun nicht mehr modular zu sein. Die Keyboard-Unterstützung wird standardmässig in den Kernel mit einkompiliert und lässt somit keinerlei Eingriffe zu. Hat schon jemand einen Lösungsansatz für diese Sache gefunden ?

Aha, ein Wagemutiger, der sich unbedingt schon 2.6 antun will.

Unter 2.6 laufen nun alle Tastatureingaben über keybdev. Daher funktioniert der o.g. Ansatz nicht mehr. Glücklicherweise gibt es im 2.6er Kernel die neue Möglichkeit, sich den Zugriff auf ein Device exklusiv zu sichern. Patche das Remote-Plugin mal hiermit. Diese Funktion wird so (oder so ähnlich) in Remote 0.2.1 enthalten sein.

Gruß,
Oliver

Zitat

Original von boardman
was ich aber niicht verstehe, warum geht alles gut, sobald das Livebild auf einen anderen Sender gestellt wird? Das Livebild hat dioch nichts mit der Platte zu tuen?

Das liegt einfach daran, daß die Systemlast höher ist, wenn Du das, was gerade aufgezeichnet wird, ansiehst.
Bei Aufzeichnungen werden die Daten ja von der Karte auf den PC übertragen. Schaut man dieses Programm gleichzeitig an, so werden die Daten zwecks Anzeige wieder vom PC auf die Karte übertragen. Nennt man Transfer-Mode. (Nur so läßt sich Timeshift realisieren.)

Schaltet man nun auf einen anderen Kanal (ohne daß dieser aufgezeichnet wird), so brauchen die Daten nicht erst zum PC-Prozessor und wieder zurück übertragen zu werden. Dies erklärt, warum 2 Programme aufzeichnen und ein drittes ansehen weniger Last erzeugt als zwei aufzeichen und eines davon ansehen.

Ob ein Prozessor der P200-Klasse hierfür ausreicht, hängt vom System ab (Chipsatz, Platte). Man bewegt sich dabei jedenfalls am Limit. Hatte früher selbst so ein System, war sehr knapp bei zwei Aufnahmen. Manche alten Chipsätze sind nicht besonders gut, was PCI-Transfers angeht.

Evtl. hilft in so einem Fall folgendes:
Das Ansehen der Aufnahme im Timeshift-Modus belastet das System weniger als im Live-Modus. Vielleicht genügt es also, die Aufnahme einfach 10s zeitversetzt anzusehen. Eventuell hilft es auch, dem Treibermodul "dvb-ttcpi" den Parameter latency=128 mitzugeben.

Hoffe, daß es nun etwas klarer ist.

Gruß,
Oliver

Zitat

Original von slapmonster
also ist es normal das das plugin nicht mit dem vdr user funzt!? hattet ihr das auch alle oder bin ich wieder der einzige.

Das Plugin selbst läuft ohne Probleme auch als Nicht-root-User.
Problem ist das Laden der Keymap: Der ungepatchte Treiber erlaubt nur root das Laden der Keymap.
Also entweder den Treiber-Patch einspielen oder - wie früher - av7110_loadkeys zum Laden einer Keymap verwenden.

Zitat

wie sieht das make der plugins dann aus?
plugin entpacken, patch einspielen und dann kompilieren?

Wie bereits gesagt wurde, es reicht aus, den Treiber zu patchen und neu zu übersetzen.

Zitat

2. dann noch was zum skript runvdr. mit diesem starte ich den vdr mit dem vdr user. schaue ich mir alle prozesse mit vdr an, fällt mir auf das das runvdr mit root rechten läuft. liegt das daran, das es aus dem inittab skript aufgerufen wird, welches von init aufgeruft wird,was mit root rechten läuft?

Ja. Muß auch so sein, da nur root die Treiber laden kann.

Gruß
Oliver

Zitat

Original von Torsten/WarEagle
also ich nutze debian seit ca. 3 Jahren, habe immer die Option aktiviert gehabt.
Der Vorteil wäre höchstens, das man "fremde" module aus anderen Kernels laden kann, aber wer bitte will das? Klar der Compile wäre bei einer Kernelversionänderung auch schneller, aber bitte, wieoft kommt sowas vor? einmal im Jahr? zweimal?

Ohne diese Option kann man nicht sicher sein, daß die Module tatsächlich zum Kernel passen. Falls sich z.B. irgendwelche Kernel-Datenstrukturen geändert haben, kann das nette Effekte haben.
Das reicht vom Absturz bis zu ganz subtilen Fehlern. Sollte man also nur machen, wenn man wirklich weiß, was man tut.

Gruß,
Oliver

Zitat

Original von slapmonster
also ich interpretiere das mal so als das du es mit eingeschalteter option geschafft hast!

Richtig interpretiert.

Oliver

Zitat

Original von haruspex
...
-P 'remote -i /dev/input/event0'
...
Ohne die Angabe des input Devices startet der Lernvorgang immer wieder, weil vdr sich intern nicht selbst entscheiden kann und eben einfach wieder abfragt.

Es ist völlig egal, ob "/dev/input/event0" als Input-Device angegeben wird oder nicht. Davon kann man sich leicht im Source-Code des Remote-Plugin überzeugen: "/dev/input/event0" wird automatisch genommen, wenn sonst nichts angegeben wurde...

Oliver

Zitat

Original von slapmonster
Hallo Leute,
baue mir gerade nen VDR Kernel mit debian. Habe im Linux Mag gelesen, das man set version information on all module symbols unter loadable module support deaktivieren soll. habe ihr das auch gemacht? ich finde eigentlich, das es aktiviert sein sollte.

Sehe keinen vernünftigen Grund, das zu deaktivieren.

Zitat

wo finde ich dann noch die Event Device Support option???

Unter "Input core support".

Oliver

Zitat

Original von marauder
erstam danke für die Hilfe aber es geht leider immer noch nicht. Und wegen dem S-VHS das steht nun mal auf dem Kabel deswegen dachte ich es heißt auch so...könnte sonst noch etwas funktionieren damit ich endlich "S-Video" Ausgang habe?

Bist Du sicher, daß das Kabel überhaupt funktioniert?

Oliver

Zitat

Original von vdrfan
du mußt den Treiber neu kompilieren. im DVB Verzeichnis

Unsinn. Es reicht, den Parameter zu übergeben.

Oliver

Zitat

Original von marauder
also ich habe jetzt im "Makefile" unter dem Pfad /usr/local/src/DVB/drivers/av7110
folgendes eingetragen:

insmod:
insmod input; \
insmod evdev; \
insmod dvd-ttpci.o vidmode=2;

Danahc habe ich make rmmod und make insmod ausgeführt und bekomme immer noch kein Bild über S-VHS. Ich bekomme aber egal auf welchen vimode ich schalte z.B. vidmode=1, vidmode=2 usw. immer ein Bild über den VHS Ausgang auf meiner TV-Karte. Normal wenn der Befehl gehen würde dürfte ich doch über den VHS gar kein Signal mehr bekommen oder? Kann mir mal jemand weiterhelfen oder eine andere möglichkeit vorschlagen? Hat jemand das gleiche Problem oder eine Antwort an was es noch liegen könnte?

Danke

Alles anzeigen

Es muß
insmod dvb-ttpci.o vidmode=2;
heißen!

Falls das oben nur ein Schreibfehler war, prüf mal nach, ob bei 'make rmmod' der Treiber wirklich entladen wird. Das klappt nämlich nur, wenn vdr nicht mehr läuft! Wenn Du nicht sicher bist, einfach die Maschine neu booten.

CU
Oliver

Zitat

Original von dream_dancer
ihr habt recht, der DMA-Modus war nicht an.

Ich habe versucht ihn zu aktivieren. Als root habe ich eingegeben:

hdparm -d1 /dev/hda

Ausgabe:
/dev/hda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

Was habe ich da falsch gemacht?

Alles anzeigen

Eigentlich nichts. Vermutlich unterstützt Dein Kernel den Chipsatz des Boards nicht. Dann läßt sich DMA auch nicht aktivieren.

Zitat

Wenn ich z.B. das Knoppix von CD boote, kann ich den DMA-Modus umsetzen. Dann steigen auch die Übertragungsraten. Aber auf meinem aktuellen System klappt es nicht (weder bei /dev/hda noch /dev/hdb). ???

Dieser Kernel unterstützt den Chipsatz offenbar.

Abhilfe:
Kernel bauen/laden, der den Chipsatz des Boards unterstützt.

HTH
oliver

Zitat

Original von winni
Kann man das CI-Modul einer Nova mit VDR nutzen

Nein (es sei denn, Du schreibst einen Treiber ;D).

Zitat

oder gehts nur mit einer full featured und zugehörigem CI?

Ja.

CU
Oliver