Beiträge von Wundertuete

Hallo Marc,

tja, dass das Problem nur bei mir auftritt, verstehe ich eigentlich auch nicht, aber da ich ja auch noch beinahe das komplette Innenleben meines Rechners getauscht habe, ist das Verhalten zumindest fast auf zwei verschiedenen Rechnern getestet...

Gruß
Wundertüte

Hallo Marc,

die ""MarginStart" bleibt übrigens nur bei Timern von VPS-Aufnahmen unberücksichtigt. Bei anderen würde es klappen. Somit wäre es wirklich sinnvoll den Aufwachzeitpunkt ein paar Minuten nach vorne zu ziehen. Das Problem mit dem Stundenversatz habe ich übrigens immer noch, obgleich ich die Ergänzungen in der /etc/default/rcS vorgenommen habe.

TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes
VERBOSE=no
FSCKFIX=no
HWCLOCKACCESS=no

Ich habe die Probleme insgesamt jetzt erstmal dadurch gelöst, dass ich folgende Korrektur in die shoutdown.sh vorgenommen habe. Ob diese allerdings mit der Winterzeit funktioniert weiß und glaube ich nicht.

# final test
if [ $WAKEUPTIME -gt $1 ] && [ $1 -gt 0 ]; then
WAKEUPTIME=$1
fi

# Korrektur
WAKEUPTIME_1=$(($WAKEUPTIME - 60 * 65))
#logger "Korrektur: $WAKEUPTIME_1 + " / " + $WAKEUPTIME"
WAKEUPTIME=$WAKEUPTIME_1

Nun ja, schrecklich elegant sind meine Künste wohl nicht

Übrigens, was ist eigentlich mit dem Server "http://gentoo.fh-luh.de/" los? Ich bekomme da seit Freitagabend keine Verbindung mehr.

Gruß
Wundertüte

Hallo!

Habe meinen Rechner mit Kubuntu 8.04 neu aufgesetzt. Wie hier bereits besprochen habe ich die Probleme mit der lirc-0.8.3pre3-Version in den Griff bekommen. Musste allerdings das x-vdr-Lirc-Script (/etc/init.d/lirc) verwenden, damit es geklappt hat, die Scripte von lirc-0.8.3pre3 haben die devices nicht richtig angelegt. Warum ist mir auch nicht wirklich klar.

Habe gestern auch noch mas weitere Tests mit dem ACPI-Wakeup gemacht. Leider hatte ich Deine Posting dazu übersehen (X-VDR und ACPI-WAKEUP). Werde mir das aber nochmals angucken. Bisher hat sich folgendes ergeben:
- Die Angabe der Variablen "MarginStart" der setup.conf bleibt generell unberücksichtigt
- Nach dem Ersetzen von UTC durch CET beim ACPI-Aufruf habe ich egal ob Timer- oder Intervall-Aufwachzeit noch eine Stunde Differenz.

Ich werde mal prüfen, ob die anderen Einstellungen aus dem genannten Link noch was bewirken.

Gruß
Wundertüte

marc

Zitat

Eventuell das UTC mal weglassen oder gegen CET tauschen...

Den "Puffer beim Aufwachen" kannst du doch im Setup einstellen. nvram-wakeup packt da dann nochmal was drauf.

Okay, das mit UTC / CET werde ich mal ausprobieren und Feedback geben.

Welche Variable definiert denn den "Puffer beim Aufwachen"? Findet sich diese in der setup.conf?

Gruß
Wundertüte

Hallo Marc,

nachdem ich nun mit meinem neuen Motherboard statt NVRAM auf ACPI umgestiegen bin, ergeben sich neue Probleme mit dem shutdown-Script. Während mein BIOS die auf GMT-Zeit steht, rechnet mein Rechner alles auf CET um. Beim NVRAM hat das alles auch funktioniert. Einschränkung war hier lediglich die Aufwachzeit nach Intervall-Definition. Bei ACPI wird nun aber immer die CET benutzt, der Rechner wacht also immer 2 Stunden zu spät auf. Außerdem existiert kein zeitlicher Puffer beim Aufwachen. Man würde also immer den Anfang vom Film verpassen. NVRAM scheint diese Punkte wohl in sich selbst berücksichtigt zu haben.

Viele Grüße
Wundertüte

Hallo Marc,

hier das gewünschte Ergebnis:

Fr 18. Apr 04:00:00 CEST 2008

Gruß
Wundertüte

Hallo!

Habe die Tage x-vdr-0.7.47 neu aufgesetzt. Als Basis habe ich Kubuntu-7.10 verwendet. Hat ein paar kleiner Probleme geben, aber läuft soweit. Was mir aufgefallen ist, ist ein Fehler im Shutdown-Script. Ich nutze immer die "Intervall"-Einstellung. Hier gibt es wohl ein Problem mit der Sommerzeit, denn obgleich eine Aufwachzeit von 3:00 Uhr angegeben ist, wacht das System um 1:55 Uhr auf. Konnte das Problem leider nicht weiter eingrenzen.

Grüße und besten Dank für den tollen x-vdr!
Wundertüte

Okay, beginne den Gedankgang zu verstehen.

Wobei:
- Swappen doch bei dem heutigen Hauptspeicher kein Thema mehr ist
- Bei größer werdenden Flashspeichern das Argument immer mehr schwindet

Aber Logging etc. bleibt natürlich erstmal bestehen. Mit den entsprechen Möglichkeiten das zu vermeiden.

Gut, ich sehe soweit klar! Danke

Hm, hinsichtlich Lebensdauer liest sich das Wiki jetzt aber auch nicht so negativ, oder?

1) Ich habe den Tread nicht eröffnet, habe mich nur eingeklinkt, da mich das Thema interessiert

2) Die Kostenaspekte brauchen wir eigentlich nicht mehr klären, da es vollkommen klar ist, dass die Lösung nicht sehr wirtschaftlich ist

3) Auch unter Performanceaspekten dürfte eine Flash-Lösung nur mit der aktuellsten Technologie Verteile bringen, die dann aber noch teurer ist. Kostengünstigere Flash-Lösungen sind dann wohl gerade beim Schreiben deutlich langsamer

4) Mir ist immer noch unklar, warum Schreibzugriffe gemieden werden sollten. Habe bisher nirgends gelesen, dass diese die Lebensdauer extrem beeinträchtigen sollen. Gibt es da eine Quelle?

Beim Preis hast Du natürlich vollkommen recht, der ist nicht gerade attraktiv.

Was spricht Deiner Ansicht nach gegen das Schreiben von Swap und Logs? Führt das häufige Schreiben zur einer deutlichen Verkürzung der Lebensdauer oder hemmt die geringere Schreibgeschwindigkeit der Medien? Würdest Du die Argumentation auch für Solid State Disks geltend machen? Immerhin würde das deren gepriesen Vorteile ja doch etwas ad absurdum führen.

halbfertiger:

Dachte gerade das Flashspeicher wegen der fehlenden Mechanik eine besonders lange Lebensdauer besitzen. Das soll ja auch der Vorteil von SSDs sein. Liege ich da falsch?

Einfach mal ein dickes: Danke!

Hm, um die Frage mal selber zu beantworten. Es gibt auf der ASUS-Homepage noch gar keine Treiber für das M3N78-EMH HDMI. Da hätte ich wohl nicht mal eine Audio-Unterstützung unter der KDE, oder?

Hallo zusammen,

plane derzeit den Neuaufbau meines VDR, aufgrund eines Hardwaredefekts.Leider kommt mir das gerade gar nicht recht, da ich die Entwicklungen in Richtung HDTV eigentlich noch aussitzen wollte.

Jetzt also die Frage: Welches der Mainboards würdet Ihr empfehlen?

Ich bin mit darüber im Klaren, dass das M2N-VM HDMI derzeit besser unterstützt wird, könnte mir jedoch auch vorstellen noch eine Weile mit der FF-Karte zu leben, bevor ich den HDMI-Ausgang zum Laufen bekomme.

Viele Grüße
Wundertüte

Hallo zusammen,

nach dem Niedergang meines derzeitigen VDRs beschäftige ich mich gerade mit dem Neuaufbau und bin dabei über das Board M2N-VM HDMI gestoßen. In diesem Zusammenhang habe ich ein paar Fragen und wäre für Feedback sehr dankbar.

Mein neues Grundsystem würde so aussehen:
- M2N-VM HDMI, 2 GB RAM, ATHLON X2 BE-2400
- 2 x SATELCO EasyWatch PCI DVB-C
- Transcend ExpressCard™|34 Solid State Disk 16 GB (Hätte ich zumindest hier noch rumliegen)

1) Hat jemand Erfahrung mit dem Booten von einem USB-Device? Mein bisheriges Mainboard mochte das überhaupt nicht.

2) Bzgl. der Audio-Ausgabe bin ich mir noch unsicher. Funktioniert die denn auch über HDMI z.B. mit Ubuntu-7.10?

3) Noch eine Frage zum zukünftigen Handling. Ich verwende derzeit den VGA-Anschluss an einem 17-Zoll LCD-Bildschirm und möchte zukünftig über HDMI an meinen Fernseher. Das wirft noch ein paar Unterfragen auf:
- Audio: Klappt es problemlos den Ton über HDMI bzw. S/P-DIF auszugeben,
wenn dieser sowohl vom VDR als auch z.B. von amarok stammt?
- Bild: Für die zwei Bildschirme benötige ich eine entsprechende Konfiguration
des X-Servers. Klappt dass denn in der Praxis den VDR auf den zweiten
Bildschirm zu bekommen?

Viele Grüße und Danke für Eure Antworten!
Wundertüte

Hallo zusammen,

wollte nach einer neuen TV-Karte schauen und für die SATELCO EasyWatch gab es doch einige Empfehlungen. Allerdings gibt es die Karte ja gleich in mehreren Ausführungen:
- SATELCO EasyWatch PCI DVB-C "Basic Edition"
- SATELCO EasyWatch HDTV PCI (DVB-C)
- SATELCO EasyWatch PCI DVB-C HDTV "Basic Edition"

Über die Hilfefunktion bin ich zu folgender Schlussfolgerung gelangt:
Es handelt sich dabei immer um die identische Karte mit unterschiedlichen Beigaben.

So habe ich da zumindest interpretiert.Stimmt das?
Schon mal Dank für Eure Antworten.

Gruß
Wundertuete

Hallo zusammen,

ich kann leider keine solch guten Verbesserungen vorweisen. Allein die Treiber aus dem Refactorin-Verzeichnis bringen keine Verbesserung. Von der in einem vorherigen Posting beschriebenen Verschlechterung würde ich jedoch mittlerweile abrücken. Ein anderer Ansatzpunkt hat jedoch bei mir zu einer spürbaren Verbesserung geführt. Die Kompilierung des Kernels mit gcc in der Version 3.3 führt gegenüber der Version 4.1 bei mir dazu, dass es bei einer gleichzeitigen Aufnahme nur dann zu Fehlern kommt, wenn der Datenstrom größer 7 Mbit/s wird. Dies Verhalten konnte ich mit Kerneln der Versionen 2.6.17 und 2.6.18 beobachten. Mit einem Kernel der Version 2.6.16.16 hatte ich zusätzlich beobachtet, dass der Effekt nur bei einem vdr mit bigpatch auftritt. Diesen Effekt kann ich nun nicht mehr nachvollziehen.

Grüße
Wundertüte

Hallo Marc,

erstmal vielen Dank für Deine tolle Arbeit! Ich habe gestern die Version 0.7.5 getestet. Soweit klappt alles prima. Insbesondere die Intervall-Funktion für einen EPG-Scan ist jetzt so, wie es sein sollte. Folgende Punkte für Verbesserungen habe ich gefunden:
- Da ich grundsätzlich meinen Rechner nur über Lirc steuere, habe ich in der /etc/default/vdr folgenden Wert gesetzt: KEYB_TTY="". Dies führt bei der jetztigen runvdr dazu, dass der vdr nicht startet.
- Jetzt wird es schon eher philosophisch: Ich fand eigentlich Deine alten Scripte besser, die den kompletten Source-Code in den den Verzeichnissen beließen. Ich habe da z.T. weitere Plugins kompiliert usw. Vielleicht wäre ja ein seperates Aufräum-Script eine gute Variante?

Gruß
Wundertüte

Hallo!

Sorry, falls ich jetzt ganz blöd frage, aber nachdem ich mich durch den Thread den kompletten Thread gelesen habe und das Ganze getest habe, bin ich nun doch etwas verwirrt.

Ist es richtig dass ich lediglich die Dateien unter http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring downloaden muss? Habe ich da noch einen Patch vergessen?

Ich habe dann ein "make" und "make install" durchgeführt.

Wie beschrieben war das Ergebnis schlechter als mit den Quellen des Kanotix 2.6.18 Kernels, da selbst ohne Aufzeichnung bereits buffer overflows aufkamen.

Gruß und Dank
Wundertüte