Beiträge von gabe

Zitat

Original von drhookson
mittels

Code

hwclock --systohc

kann man ja die RTC mit der systemzeit synchronisieren, aber das immer händisch zu machen, macht auch nicht spass.

gibts irgendwo eine einstellung, mit dem man so eine synchronisierung aktivieren kann?

Also ich lasse bei mir in einem Shutdown-Hook vom VDR die Zeit der RTC aktualisieren. Habe die Zeitsynchronisation von VDR über EPG an. Ohne die Aktualisierung der RTC verweigert NVRAM den Dienst, wenn die Abweichung zwischen Systemzeit und RTC zu groß ist. Deshalb muss der Shutdown-Hook eine niedrigere Zahl als der NVRAM-Shutdown-Hook haben.

Habe mir dazu die Datei /usr/share/vdr/shutdown-hooks/S10hwclock angelegt und folgendes reingeschrieben:

#
# VDR Shutdown Hook to set hardware clock (RTC)
# ---------------------------------------------
#
hwclock --systohc
exit 0

Bye, gabe!

Zitat

Original von linux?
Also mich stört es doch garnet das er mir den empfang klaut ! Mich stört das er nachdem er fertig ist nicht wieder zurückschaltet. Würde er das automatisch tun dann hätte ich kein problem damit.

Tja, soweit mir bekannt ist, gibt es da keine Möglichkeit. Ist so ähnlich wie ein Bildschirmschoner am PC: wenn eine bestimmte Zeit keine Benutzereingaben erfolgen, dann wird im Hintergrund der EPG-Scan gestartet, was bei einer Karte zu einem schwarzen Bild führt (deshalb auch der Vergleich mit dem Bildschirmschoner 8)). Und das ganze macht er so lange, bis wieder eine Benutzerinteraktion kommt. Ein Bildschirmschoner wartet ja auch auf Mausbewegungen oder Tastatureingaben und schaltet nicht nach einem Durchlauf ab. Und der Scan läuft dann wahrscheinlich eher in so einer Art Endlosschleife. Das praktische: mit einem Ein-Karten-System hat man gleich noch einen Bildschirmschoner für den Fernseher

Also die einzigste Möglichkeit, die ich da sehe, ist höchstens das Patchen des VDR-Quelltexts. Aber ich glaube Aufwand und Nutzen stehen da in keinem Verhältnis.

Du kannst aber auch mal ausprobieren, wie sich der manuelle EPG-Scan mit

svdrpsend.pl SCAN

auswirkt. Vielleicht kehrt der ja zum ursprünglichen Sender zurück, wenn er einmal durchgelaufen ist.

Bye, gabe!

Zitat

Original von Helmchen
Ist geklärt.

[gelöst] Ein erneutes "apt-get update" hat wohl einen eingespielten Fehler wieder beseitigt.

Ehm, naja, eigentlich macht apt-get update nichts am VDR. Es holt normalerweise nur die aktualisierten Paketlisten von den Quellen. Kann mir nicht vorstellen, dass das Probleme mit NVRAM auslöst und behebt. Genaueres zur Paketverwaltung steht unter http://www.vdr-wiki.de/wiki/in…_zur_APT-Paket-Verwaltung

Bye, gabe!

Zitat

Original von champpain
1) Doppelte epg-einträge
Neben doppelten Inhaltsbeschreibungen, habe ich z.B.auf Pro7 auch öfters ZWEI anfangszeiten ein und derselben sendung mit abweichungen zwischen 1 und max. ca. 10 Minuten.

Dafür gibt es den Patch "disableDoubleEpgEntries". Falls du dich weniger mit selberkompilieren beschäftigst, würde ich dir das zu ct-vdr kompatible Repository von http://www.e-tobi.net/ empfehlen. Ich verwende davon selber den Bigpatch, der diese disableDoubleEpgEntries-Patch enthält. Wie aber das Update von ct-vdr-1 funktioniert, weiß ich nicht genau. Die Version ist dann doch etwas alt und kann mehr Probleme beim anpassen machen. Also vor Experimenten dann doch lieber ein Backup machen.

Hinweise zum neuen Repository unter http://www.e-tobi.net/cgi-bin/main.cgi/=repository-struktur und http://www.e-tobi.net/cgi-bin/…=Grosses%20Herbst-Update.

Allgemeines zum Umgang mit APT und VDR unter http://www.vdr-wiki.de/wiki/in…_zur_APT-Paket-Verwaltung damit am Ende auch alle Plugins wieder gehen

Viel Erfolg,
gabe!

Also für mich hört sich das ganze wie ein hoffnungsloser Fall an. Ich will dir aber nicht gänzlich den Mut nehmen. Ich habe mich auch seit ct-VDR 3 mit APM, Poweroff und nicht mehr aufwachenden VDR trotz korrekter NVRAM-Funktionalität rumgeärgert. Wie es scheint, hat sich am APM manches geändert. Wenn der Weg mittlerweile so schwierig bis unmöglich scheint, wie wäre dann ein anderer? ACPI scheint soweit ja zu funktionieren. Es gibt doch auch ein vdr-addon-acpiwakeup im ct-Repository. Vielleicht das mal probieren? Aber mehr kann ich dazu nicht sagen, da ich das selber nicht testen kann (ACPI funktioniert bei mir nicht fehlerfrei).

Bye, gabe!

Zitat

Original von DonCamillo
Der VDRadmin läuft bei mir sowohl unter der vdr als auch unter vdrdevel. Das Problem mit den LIRC Antwortzeiten tritt jedoch ausschließlich unter vdrdevel auf. Daher kann es imho nicht nur am VDRadmin liegen.

Aber XXV steht trotzdem auf der Update-Liste

Also LIRC benutze ich gar nicht, sondern nur das Remote-Plugin. Was auch nur wieder die These unterstützt, dass die Hänger verscheidene Ursachen haben. vdrdevel läuft bei mir auch nicht, hab genug mit vdr 1.2.6 zu experimentieren.

XXV werde ich auch irgendwann mal testen, bin aber momentan froh, dass der VDR erstmal wieder einsetzbar ist.

Bye, gabe!

Zitat

Original von MartenR
Das Problem das in diesem Thread diskutiert wird ist alt bekannt.
Ursache ist vdradmin der nach autotimern sucht und sich epg-daten vom VDR über SVDRSP holt. Während dieser Zeit(je nach Anzahl der Sender und Autotimer einige Sekunden) ist die Auswertung der Fernbedienung über Lirc blockiert.
Abhilfe könnte XXV sein, der inteligenter die Daten vom VDR über SVDRSP holt.

Das klingt logisch und mag ja auch sein. Hatte bis Mittwoch auch einen Autotimer im VDRAdmin drin. Vielleicht ist es durch das Löschen dieses Autotimers auch weniger geworden.

Ich denke aber, dass das Problem mehrere Ursachen hat, denn beim Multipatch trat es doch viel extremer auf als beim Bigpatch. Und während ich das getestet habe, hatte ich keine Autotimer mehr. Und wie gesagt, gestern ging auch alles glatt, bis auf das eine mal. Deshalb muss SWAP jetzt erstmal weichen und ich werde das weiter beobachten.

Also für mich sieht es so aus, dass da durchaus mehrere Ursachen dasselbe Sympthom hervorrufen. Deshalb müssen alle bekämpft werden um die Auswirkungen zu unterdrücken.

Bye, gabe!

Also das Multipatch die schlimmeren Probleme hervorgerufen hat, steht außer Frage. Weiß eh nicht so genau, ob mir der gegenüber Bigpatch einen nennenswerten Vorteil bringt.

Hab gestern Abend nur einen einzigen Hänger gehabt. Und ich habe die ganze Zeit besonders auf die RAM Nutzung geachtet. Vor dem Hänger war mein RAM noch nicht voll und SWAP noch auf 0 MB. Nach dem Hänger war SWAP plötzlich auf 2 MB. Vermute jetzt mal, dass er diese Hänger durch das Auslagern von Speicher hat. Werde demnächst mal von 128 MB auf 256 MB RAM aufrüsten.

Vielleicht ist das auch mit ein Grund, dass das entfernen von Text2skin manchmal etwas bringt, weil er ja dadurch weniger Speicher belegt. Wenn ich genau zuückdenke, dann habe ich diese Hänger seit ich mir mit InfoSatEPG 7 Tage im voraus Programminfos hole. Es deutet vieles auf die Speichernutzung hin.

Wie sieht die Belegung bei euch aus? Habt ihr genug RAM-Reserven oder wird bei euch auch auf SWAP zurückgegriffen?

Bye, gabe!

Habe jetzt mal den aktualisierten DVB-Treiber 1.1.1 von der ct-Seite heruntergeladen (ftp://ftp.heise.de/pub/ct/proj…1.1+cvs-041202-4_i386.deb) und installiert. Anschließend noch die aktuelle Firmware 261d von http://www.linuxtv.org/downloads/firmware/ geholt und verlinkt. Siehe dazu auch http://www.vdr-portal.de/board/thread.php?threadid=30543&sid=&hilight=linuxtv+dvb+ct+modules+2+4+27+ctvdr+1+1+1+1+cvs+041202+4+i386+deb

Außerdem habe ich auch von Tobi's Multipatch auf Bigpatch umgestellt. Und ich muss sagen, dass die Umschaltzeiten deutlich besser geworden sind. Und auch die Hänger treten noch nicht wieder auf. Aber das muss ich noch ausgiebiger testen, nur so ist es schonmal besser.

Bye, gabe!

Zitat

Original von DonCamillo
Das Problem mit der Antwortzeit und Absturzverhalten im Zusammenhang mit dem Multipatch Repository hatte ich auch.

Es hat sich nachhaltig gebessert, nachdem ich auf das Bigpatch Repository (wie Multipatch, ohne AutoPID) umgestiegen bin. Seitdem bin ich mit Stabilität sehr zufrieden.

Okay, das ist sicherlich einen Test heute nach Feierabend wert. Vielleicht sind deshalb auch die Umschaltzeiten schlechter geworden (AutoPID?). Aber vorher hatte ich ct-VDR mit elchiospip-Patch und da waren auch die Probleme da, aber nicht so häufig.

Zitat

Original von RaK
Ist wie ein stochern im Nebel, deshalb will ich euch meine Beobachtungen nicht vorenthalten ;).

Ich hab text2skin nicht mehr in Gebrauch und seitdem gehts besser (zumindest kommt es mir so vor). Zudem hab ich ne wirklich lahme Kiste (Epia ME6000).

Ja, ich tappe auch voll im dunkeln. Ich habe auch nur eine "lahme" Kiste (K2-450 MHz -> sollte aber eigentlich ausreichen). Text2skin habe ich meines Wissens nach nicht installiert. Wollte demnächst auch mal probieren, ob 256 MB gegenüber jetzt 128 MB eine Verbesserung bringt.

So, jetzt warte ich nur noch auf Feierabend und dann gehts los mit Testen
Bye, gabe!

Das Problem hat sich verschlimmert. Habe auf e-tobis Multipatch-Testing-Repository geupdated und seitdem hängt der VDR viel öfter und auch länger. Aber wie vorher: er reagiert für ein paar Sekunden nicht auf die Eingaben per Fernbedienung, aber anschließend führt er alle Aktionen aus. Also eigentlich kriegt er alle Befehle mit.

Sonst was neues?
Bye, gabe!

Zitat

Original von ulho
Eigendlich bleiben dann nur noch die Platten über ?(.
Das kann ich kaum glauben (kein Interrupt-Sharing bei den Platten ...)

Auch wenn das jetzt vielleicht ein bisschen seltsam klingt: wenn du einfach mal die beiden Platten vertauchst?

Bye, gabe!

Zitat

Original von madle
ok hab jetzt die verion -4 drüber gespielt!
die änderungen in der vdr-nvram-wakeup.conf gemacht, frage dazu muss man die specialshutdown option aktivieren?

Das hängt davon ab, ob er ohne einen Reboot aufwacht. Wenn du NVRAM auf der Konsole mit der Option "--debug" startest müsstest du sehen, ob beim Feld "need_reboot" dein Board einen Reboot braucht oder nicht. Wenn der Wert nicht 0 ist, musst du Specialshutdown setzen.

Seit ct-VDR 3 ließt man aber auch immer wieder von Aufwachproblemen, obwohl die Boards kein Reboot benötigen. Hierfür ist die Option "force_reboot" in der Config da, damit man einen Reboot erzwingen kann. Dann benötigt man aber auch noch den Power-Off-Kernel.

Bye, gabe!

Vielleicht hilft dir meine Erfahrung: http://www.gabe.gmxhome.de/vdr/addons.htm

Falls dein Board aber nicht automatisch erkannt wird, kann ich dir leider auch nicht weiterhelfen.

Bye, gabe!

Zitat

also das Problem hat sich erledigt nach dem ich in der intrefaces mit WINSCP3 die netmask nur die 255.255.255.0 überschrieben habe ging es. Entweder habe Tomaten auf den Augen oder mann konnte den Fehler nicht sehen.

Klingt so, als ob sich ein Windows-Zeilenumbruch in eine Linux-Textdatei eingeschlichen hat. Deshalb nehme ich nur noch Editoren auf der Konsole.

Die Netzwerkeinstellungen kann man bei ct-VDR aber auch mit Dem Befehl

dpkg-reconfigure etherconf

anpassen. Aber ich weiß nicht, wie er damit klarkommt, wenn du schon manuell was an den Konfigurationsdateien geändert hast.

Bye, gabe!

Durch das Update des VDR (und nebenbei wird sich wahrscheinlich auch noch die Patchvariante geändert habe), müssen alle Plugins aktualisiert werden. Da, wo sich die Versionsnummer ändern, müsste er automatisch das neuere Plugin holen. Wo die Versionsnummer gleich bleibt, muss man sich trotzdem das Plugin neu holen, da es mit dem richtigen Patchlevel kompiliert sein muss.

Probier mal ein vdraptrefresh, das soll das glaub ich lösen. Weitere Hinweise stehen auch hier: http://www.vdr-wiki.de/wiki/in…_zur_APT-Paket-Verwaltung

Ansonsten bringt apt-get install <plugin> meistens auch nichts, sondern man muss explizit eine Neuinstallation anornden: apt-get install <plugin> --reinstall

Bye, gabe!

EDIT: wilderigel: war wohl zu langsam

Verwendet ihr ACPI? Vielleicht solltet ihr versuchen, mal ohne ACPI zu starten (und APM natürlich an). Falls das nichts bringt, vielleicht mal genau umgekehrt testen: ohne APM aber mit ACPI.

Wie verhält sich dann shutdown -h now?

Bye, gabe!

Du kannst mal noch einen anderen Power-Off-Kernel probieren: http://www.e-tobi.net/vdr/sarg…eroff-2.4.24_0.1_i386.deb

Weiß aber nicht, ob es dadurch besser geht. Bei mir persönlich läuft der Kernel ftp://ftp.heise.de/pub/ct/proj…eroff-2.4.18_0.1_i386.deb ohne Probleme mit einem Asus P5A. Aber den müsstest du eigentlich schon haben.

Bye, gabe!

Zitat

wobei manche anscheinend ihre Traumwerte angegeben haben

Ja, davon träume ich auch

Naja, egal. Habe ja schon beschrieben, dass man durch Suspend-To-RAM wohl mehr Probleme hat. Da muss man sich dann so tief mit Linux auseinandersetzen, dass man gleich einen optimal abgespeckten Kernel bauen kann.

Bye, gabe

Also prinzipiell find ich die Idee ganz gut, aber ich seh da auch so manche Probleme.

Die Aufwachgeschwindigkeit hängt von der RAM-Größe ab: habe ich 512 MB, so muss er auch 512 MB von der Festplatte lesen. Beim Start des VDR muss er da nie im Leben so viel reinladen. Weiß nicht, ob VDR selber überhaupt mehr als 64 MB braucht (mein System läuft mit 128 MB RAM). Der andere Speicher wird er für Caching verwendet, welcher sich aber erst im Betrieb füllt. Also hätte man dadurch schon eine zusätzliche Verzögerung.

Ein anderes Problem ist die Firmware für die FF-DVB-Karte. Die ist ja nach dem Ausschalten des Stroms aus der Karte und müsste neu initialisiert werden. Und genau das passiert ja beim Booten. Also ein normaler Suspend-To-RAM (vielleicht noch mit ACPI) würde da nicht mehr reichen. Weiß noch, dass ich damals beim Betrieb unter Windows auch kein Standby oder ähnliches überlebt hab, wenn die TV-Software lief.

Also müsste man dann doch wieder wie ein bissl booten und unnötig viel Speicher von der Festplatte auslesen, so dass es meines Erachtens keinen Vorteil bringt. Ich persönlich hab so ca. 50 Sekunden mit ct-VDR. Manchmal hilft auch das einfach entrümpeln des Systems, indem man sich von unnötigen Diensten trennt. Wobei LinVDR und ct-VDR seit Version 3 da schon gut entrümpelt sind.

Manchmal sollte man auch einfach mal die lilo.conf anschauen. Denn bei ct-VDR steht da z.B. nach der Installation eine Wartezeit von 10 Sekunden drin. Diese verzögert den Start des VDR nur unnötig, da er ja da nix weiter macht.

Außerdem isses nunmal ein PC, wo das BIOS auch erstmal ein paar Sekunden frist, bis es überhaupt mit dem Bootvorgang von der Festplatte beginnt. Hängt also auch vom verwendeten Board ab.

Interessant ist http://www.vdr-wiki.de/wiki/index.php/VDR_Bootzeiten da haben die Leute schon das maximale aus ihren Komponenten rausgeholt, dass schafft kein Suspend-To-RAM!

Bye, gabe!

EDIT: Link korrigiert