Beiträge von Egalus

Zitat

Original von gda
Das hört sich für mich eher so an als wäre ACPI im BIOS ausgeschaltet.

Das ist definitiv an, lief ja seit ca. 2 Jahren mit etch und nachher mit lenny.

Zitat

Hmmm, der ist auch per default installiert. Hoffentlich hast du damit nicht irgendwie die Konfiguration kaputt gemacht. Wurdest du bei der Installation des acpid gefragt, ob du Konfigurationsdateien überschreiben willst?

Eine solche Abfrage kam definitiv nicht.
Wenn mir gerade einfallen würde in welchem Log noch gleich das Installationslog von apt versteckt wird würd ich mal eben nachgucken.

Zitat

Das absolut unnötig, weil der User vdr gar nicht dahin schreibt sondern root. Der user vdr benutzt dazu einen SUID-Wrapper. Mir ist völlig unklar was du da gemacht hast um in diese Situation zu kommen.

So kenne ich das auch von e-tobis Paketen und den shutdown-hooks.
Lustigerweise meckert der acpi-wakeup shutdown-hook aber nicht wenn ich vdr zum owner mache und schreibt dann auch brav die Weckzeit rein.
Mit owner root bricht der shutdown wie im oberen Log gezeigt einfach ab.

Zitat

Original von gda

Das verstehe ich nicht. Aus welcher Quelle hast du das denn nachinstalliert? Das ist doch per default installiert. Die Probleme, die du hast, gibt es nicht nach einer normalen yaVDR-Installation.

Gerald

Vielleicht war es ja schon installiert, das war letzte Nacht um 2 oder so
Nachdem ich gelesen habe "ACPI Needed!" bin ich davon ausgegangen das es nicht installiert ist und hab ein apt-get install acpid gemacht.

Ich hab jetzt erstmal ein
chown vdr /sys/class/rtc/rtc0/wakealarm
in meine rc.local gepackt.

Nun stehe ich vor dem nächsten Problem.
s2disk scheint solange zu funktionieren wie kein timer exisitert. Existiert ein Timer so wird brav nach wakealarm geschrieben und der Rechner scheint auch sonst das meiste des shutdowns durchzuführen, der Rechner geht aber niemals aus und bleibt pingbar (sonst geht aber nix mehr).

Danke für den Tip, es war die Edid bin. Wusste bis dato nicht das yavdr sowas speichert und natürlich passte die von meinen Wohnzimmer Fernseher nicht zu der von meinem Arbeitsmonitor.

Nu hab ich wenigstens schonmal Bild und muss nur noch rausfinden warum ein
sudo s2disk wunderbar bei laufendem vdr wunderbar funktioniert und auch den Server abschaltet (zumindest in den letzten 5 Versuchen jedesmal), über VDR selbst aber spätestens beim 3. mal der Server nicht aus geht.

Die Frustrationsgrenze ist immer schnell erreicht wenn man wenig bis garnicht dokumentierte Funktionen zu verstehen versucht.

Ich hab z.B. bisher keinen Schimmer welche Routinen yavdr genau ausführt wenn ich s2disk aktiviert habe und den vdr runterfahre, noch an welcher Stelle da die force-reload-modules.list oder force-reload-services.list ausgewertet werden. Das macht eine Analyse der Fehlfunktion nicht gerade einfacher.
Natürlich ist es WAF mässig enorm von Vorteil nicht immer 1000 Ausgaben über den Bildschirm huschen zu sehen wenn der Rechner runterfährt, aber ein Switch zum reaktivieren aller Ausgaben wäre einfach enorm hilfreich

Hallo,

so langsam krieg ich hier die Krise.
Da will ich debuggen warum zum Henker s2disk nicht richtig funktioniert (der Rechner schaltet nicht ab und bleibt pingbar) und acpi-wakeup auch rumzickt und dann tut sich das nächste schwarze Loch auf.

Da mein VDR im Keller steht, der TV aber im Wohnzimmer an der Wand hängt habe ich mir das Debuggen einfacher vorgestellt wenn ich einfach mit meinem FullHD PVA Monitor und meinem Laptop bewaffnet in den Keller gehe und den Monitor statt den Fernseher an den VDR klemme.
Nette Idee, aber nachdem das Bios und Grub noch wunderbar dargestellt werden ist nach dem Starten von vdr nur noch gestreifter Müll (der sich je nach Content ändert) auf dem Bildschirm. Das erinnert ein wenig an die uralte Premiere Verschlüsselung als das noch analog passierte.
Auch wackelt das "Bild" hoch und runter obwohl es doch eignetlich über HDMI -> DVI angeschlossen ist.

Kann mir einer sagen was da nun wieder schief läuft?
Ich hab im webfrontend schon alle möglichen Einstellungen für die Nvidia ausprobiert aber nichts hilft.

Es ist definitiv eine Installation vom ISO.

Zitat

Original von ofenheizer
Hi.

Mal ne ganz blöde Frage. ACPI hast Du aber in der entsprechenden Datei auf 'enable' gestellt (/etc/vdr/vdr-addon-acpiwakeup.conf)?

Gruss
Markus

Ja, habe ich, auch acpi selbst habe ich nachinstalliert und aktiviert.
Wie im 2. Posting gesagt meckert VDR ja auch nicht mehr das es da nicht reinschreiben kann wenn ich händisch dem User VDR Schreibrechte auf /sys/class/rtc/rtc0/wakealarm gebe.

Ich hab zwar noch nicht getestet ob der Rechner dann auch wirklich aufwacht, aber das was in wakealarm geschrieben wird lässt sich per /proc/device/rtc wieder auslesen.

Ein wenig weiter ausprobieren zeigt mir, dass sich die richtige Stelle in /proc/driver/rtc ändert wenn ich in /sys/class/rtc/rtc0/wakealarm schreibe - allerdings geht das Schreiben nur als root.
Wenn ich mal ein chown vdr auf wakealarm mache kann auch acpi-wakeup schreiben und fährt runter.

Wo muss ich nun bei yavdr dran drehen damit vdr immer auf wakealarm schreiben darf?

Hi,

ich bin gerade dabei meinen ehemals SD only VDR von debian mit e-tobi nach yavdr umzuziehen.
Da acpi-wakeup mit debian funktioniert bin ich gerade der Verzweiflung nahe, denn bei yavdr erhalte ich immer folgendes im Log:

Jan 29 01:27:59 video vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup as shell script
Jan 29 01:27:59 video vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2011-01-29 01:00:00
Jan 29 01:27:59 video vdr-addon-acpiwakeup: No writeable /proc/acpi/alarm or /sys/class/rtc/rtc0/wakealarm found. ACPI needed!!!
Jan 29 01:27:59 video vdr-shutdown: Shutdown aborted by /usr/share/vdr/shutdown-hooks/S90.acpiwakeup with exitcode 1

Dabei gibt es das /sys......

goebel@video:/lib$ ll /sys/class/rtc/rtc0/wakealarm 
-rw-r--r-- 1 root root 4096 2011-01-29 01:25 /sys/class/rtc/rtc0/wakealarm

Allerdings bringt ein cat davon immer genau nichts als Rückgabewert.
Da ich bei der Kernelumstellung von /proc/acpi/alarm auf /sys/class/rtc/rtc0/wakealarm damals (unter Debian) schon Probleme hatte das zum laufen zu kriegen habe ich dort weiterhin /proc/acpi/alarm genutzt. Das steht mir mit dem yavdr Kernel aber nicht zur Verfügung.

Ich habe schon HPET im Bios deaktiviert (obwohls früher mit wunderbar lief) und hpet=disabled als Kernelparameter übergeben. Es ändert sich aber leider nichts.

Habt ihr eine Idee für mich was ich noch falsch machen könnte? Board ist ein Asus M3N-H HDMI.

Hi,

wie schon im Threadtitel steht, sobald ich das Plugin aktiviere und dann das VDR Backend neu starte schmiert selbiges immer wieder ab um dann gleich wieder neu gestartet zu werden. Sobald das plugin deaktiviert wird läuft auch vdr wieder.

Ich nehme an das da irgendwo etwas an der config gedreht werden muss hab nur keinen Schimmer wo.

Lösung:
Wie schon in anderne Threads beschrieben - sorry, ich hab mich beim Suchwort bei der Suche vor dem Posten vertippt - muss man die plugin.upnp.conf anpassen. Siehe z.B. hier: http://www.vdrportal.de/board/…?postid=902012#post902012

Traurig ist allerdings das das UPNP Plugin alte Aufzeichnungen (prä .ts Ära) einfach ignoriert und nur 2x gespult werden kann (zumindest mit meinem Mediaclient). Schade, so ist das unbrauchbar.

Hm

beides gibts bei mir garnicht. Gibts die Ausgaben nur bei aktivieren HDMI Audio Passthrough?
Mein syslog bzw. dmesg ist jedenfalls "HDMI" frei.

Und unter /proc/asound gibts nur card0 und dort kein auch nur annähernd eld#1.0 genanntes fiehandle.

Zitat

Original von steffen_b
Du kannst mal im Log schauen, das hört sich ganz danach an als wenn nur Stereo akzeptiert wird. Also anstelle HDMI Passtrough HDMI Stereo aktivieren. Vermutlich gibt dein Fernseher kein 5.1 weiter und kann selber nur Stereo.

Ich werds nochmal testen, aber eigentlich bin ich mir sicher das Passthrough anderer Quellen mit DD und DTS über den Fernseher an den Verstärker funktioniert.
Welches Log ist denn das richtige für die Suche? Und wie lautet wohl ungefähr der Suchbegriff nach dem ich in dem Log suchen muss?

Zitat

Original von halbfertiger
Die schwarzen Ränder ringsrum sendet der Sender so, wenn du die Bilder mit Skalierung und automatischem Zoom aufbläst, hast du eventuell die ganze Bildschirmfläche ausgefüllt aber eventuell indiskutable Breitmaulfrösche auf dem Fernseher. Außerdem wird dabei das Bild skaliert, also entspricht nicht mehr jedes gesendete Pixel einem angezeigten Pixel. Das ist für manche der schlimmste Sündenfall.
Abhilfe wenn ein Sender so sendet - einfach weiter zappen.

Naja, zumindest bei SD-Programmen (und das sind ja bisher die einzigen verfügbaren bei mir) ist ja eh ein gesendetes Pixel != ein dargestelltes Pixel. Ist 576i nicht 720x576? Dann wären das beim Skalieren auf 1080p ja eh 2,667 angezeigte Pixel pro echtem Pixel.

Aber schon seltsam das die TV-Sender das nicht gescheit hinbekommen. Ich tippe dann mal das bei analogen Röhren einfach immer ein relativ großer Overscan aktiviert ist so das mir das bisher im SD-TV über Scart nie aufgefallen ist.

Ich hab nochmal ein wenig mit Overscan rumgespielt und netterweise verändert das wenigstens nur das TV-Bild und nicht das OSD.
Ich hab jetzt erstmal 5% Overscan, anamorphic und automatisches beschneiden von 4:3 auf 14:9/16:9 aktiviert. Das sieht so schonmal viel besser aus - allerdings braucht die Automatik einige Sekunden zur Anpassung, was wiederum seltsam aussieht Das sieht allemal alles besser aus als das TV-Out der FF (also nalog) an den LCD angeschlossen.

Hi,

ich hab direkt noch ein Problem.
DD 2.0 bzw. PCM über HDMI funktioniert wunderbar, sobald ich aber DD 5.1 auf einem beliebigen Sender aktiviere höre ich nur noch Knattern am TV bzw. am Verstärker wenn ich Audio Passthrough am TV aktiviere.
Gebe ich den gleichen Ton über SPDIF aus kommt der Ton wunderbar beim Verstärker an.
Hat jemand eine Idee woran das liegt?

TV ist überigens ein Sony Bravia KDL32-EX500.

Hi,

nachdem ich meine anfänglichen Probleme bezüglich Instabilitäten des nvidia Treibers beseitigt habe (warum auch immer war die GF8300 im Bios wohl übertaktet, ich hoffe mal 500/1500 MHz sind die Normalewerte, mein Handbuch schweigt sich da aus) habe ich jetzt zwei andere Probleme die ich mir nicht erklären kann.

Mein System ist das aus der Signatur, also zunächst nur SD DVB-S Karten nun aber mit yavdr 3.0 per HDMI an einem FullHD LCD TV.

Problem 1:
Bei Live-TV kämpft mein TV-Bild mit sich laufend in der Größe verändernden schwairzen Balken an allen Seiten. Z.B. gerade bei RTL (einer der Sender die gerade Bildschirmfüllenden Inhalt senden) wandert der Rand des Inhalts an allen Seiten langsam hin und her. Das betrifft allerdings nur das LiveTV Bild, das OSD wird immer komplett und bildschirmfüllend angezeigt. Mir will einfach nicht in den Kopf gehen warum das Live-TV Bild sich ständig bewegt. Die Quelle aus der die Pixel kommen ist doch digital, nämlich DVB-S. Nun müsste es doch möglich sein diese Pixelanzahl einfach auf 1080i oder p hochzurechnen, also wieso ändert sich der Rand des Live-TV Bides?
Bringt hier die Overscan Einstellung etwas? Oder beeinflusst die auch das OSD?

Problem2: Bei vielen Sendern passt die Bildgröße bis auf Problem 1 sehr gut, aber bei einigen scheint etwas gewaltig schief zu laufen. Freddy vs. Jason auf Kabel 1 hat z.b. gerade riesige schwarze Balken an allen 4 Seiten während die OSD Einblendungen volle Größe haben. Bei Vox dagegen habe ich nur an den Seiten dicke Trauerränder, das sieht irgendwie nach 4:3 auf nem 16:9 Fernseher aus. Über DVB-T vom Fernseher ist das Programm aber bildschirmfüllend.
Unter DVB habe ich das Videoformat 16:9 eingetragen.
In Xineliboutput das Seitenverhältnis Automatik, Schneiden Letterbox 4:3 zu 16:9 Nein, Software scaling nein, Overscan aus.
Stelle ich das Schneiden ein, so verschwinden (nach unschönen ca. 5 Sekunden auf dem Kanal) die seitlichen Trauerränder, an der "4:3" Darstellung ändert das aber nichts.

Ich bin noch sehr frisch im HDTV Bereich unterwegs also hoffe ich ihr verzeiht mir falls ich "dumme" Fragen gestellet habe.

Danke für eure Hilfe,
Norbert

Zitat

Original von Soulfly2xs
Ich habe das gleiche Phänomen gehabt....aber immer noch keinen Treiber Rebuild gemacht.

Ich konnte mein Problem durch

Code

sudo apt-get install xineliboutput-sxfe yavdr-essential xine-ui libxineliboutput-sxfe yavdr-addon-pip libxine1-xvdr libxine2

beheben.

Mal eine generelle Frage:

Startest du XBMC als Frontend? Denn so trat das Problem bei mir auf...konnte aber feststellen das Kommandos der Fernbedienung angenommen wurden.

Alles anzeigen

Soweit XBMC zu testen war ich noch nicht, es haperte ja schon am TV-Gucken. Ich wollte gerade heraufinden warum das per DVB-S als SD empfangene Programm auf meinem per HDMI angeschlossenen FullHD schwarze Balken rund ums gesamte Bild zeigt als schon nix mehr ging.
Das sah für mich (auch von der Bedienung her) nach nem schnöden VDR aus - ob nun über xine oder xinelibouput kann ich nicht sagen, das was nach ner Installation von yavdr halt stadardmässig an ist.

Ich werd deinen Tip ausprobieren - wird aber heute nix mehr draus da Frau nicht auf den VDR verzichten wollen wird

Zitat

Original von zebulon
und Du bist sicher, das kein fsck läuft? Wie lange hast Du nach dem Bootversuch gewartet?

Wenn da einer läuft, dann braucht der extrem lang (20+ Minuten für ne 20GB Partition auf ner 1TB SATA Platte).
Und spätestens da wäre es sehr praktisch was sehen zu können
Auch die HDD LED hat die ganze Zeit keine Aktivität vermuten lassen.

Es scheint am Nvidia-Treiber zu liegen, ich hatte eben mal im chroot von lenny aus ein apt-get update && apt-get upgrade gemacht.
Danach konnte ich dann wenigstens mal kurz wieder remote auf die Box weil sich der Treiber darüber beschwerte das API Version und Treiberversion nicht übereinstimmten.
Ich Depp habe das dann mit nem dkms rebuild behoben - jetzt geht wieder fast nix. Schwarzer Bildschirm aber diesmal gibts ne IP, nur sind schon die Pings im LAN zwischen 300 und 5000ms und ein SSH Login oder Webinterfacezugriff ist auch nach 5 Minuten Wartezeit nicht drin.

Irgendwie bestärkt mich das in der Ansicht das doch nix über ein ausführliches Bootprompt geht, dann kann man wenigstens darüber debuggen. Momentan sehe ich mal wieder nur schwarz.

Ich hab jetzt rein aus Spaß den 195er Ubuntu nvidia-current installiert (per chroot) und dabei hat dkms mal wieder versagt so dass ich jetzt wieder kein Bild aber dafür Zugriff aufs System habe. Im Log finden sich dann die Zeilen
Jan 9 01:01:26 video kernel: [ 83.010596] NVRM: API mismatch: the client has the version 195.36.24, but
Jan 9 01:01:26 video kernel: [ 83.010600] NVRM: this kernel module has the version 260.19.29. Please
Jan 9 01:01:26 video kernel: [ 83.010604] NVRM: make sure that this kernel module and all NVIDIA driver
Jan 9 01:01:26 video kernel: [ 83.010607] NVRM: components have the same version.

Update: So langsam komme ich der Sache auf die Spur.
Kurz nachdem ich gerade mit dkms den 195er nvidia-current gebaut und per modprobe geladen hatte wars wieder aus. Die gerade noch benutzte ssh console wurde unbrauchbar. Pings gingen erst von 1-3ms auf 300-5000ms rauf und lieferten nach ner weiteren Minute nur noch Destination Host unreachable.

Was mache ich bei meinem Asus M3N-H HDMI mit GF8300 Grafikchip, 2x 1GB DDR2 800, Athlon II X2 250, ner FF und 2 Budgets im System also grundlegend falsch? De GF8300 hab ich im Bios ne Arperture Size von 512MB eingeräumt.

Hi,

nun hatte ich eben mal ein laufendes yavdr bis ich auf der Suche nach dem Overscan über den Deinterlacer (ich hatte da sehr unschöne Artefakte) gestolpert bin und ihn für SD Material auf temporal_spatial umgestellt hab.
Beim Aktivieren der Option sollte wohl vdr beendet und neu gestartet werden, der Restart klappte aber nicht - und auch sonst ging danach garnix mehr außer den Rechner hart auszuschalten.

Und jetzt kommt nach grub noch ganz kurz "yavdr wird gestartet" oder so ähnlich oben links, dann ein Wechsel zu einem schwarzen Bildschirm und das wars. Der Rechner reagiert weder auf den Wunsch auf eine Console zu wechseln, noch ist er im Netzwerk erreichbar.
Auch SysReq Keys interessieren yavdr überhaupt nicht.
Da ich auf einer anderen Partition noch mein lenny drauf habe hab ich versucht die Einstellung wieder rückgängig zu machen und habe dazu den temporal_spatial Eintrag in /var/lib/yavdr..... (geht gerade nur ausm Kopf, aber ich nehme an ihr kennt das configfile besser als ich) geändert. Leider ändert das am Bootverhalten nichts. Muss ich danach noch irgendetwas anderes ausführen?

Hi,

ich habe mich eben an der Installation von yavdr 0.3.0a auf meinem Asus M3N-H HDMI versucht.
Anfangs habe ich es nicht hinbekommen nach dem Booten ein Bild via HDMI auf dem Fernseher zu sehen - ich nahm an das lag dran weil noch ein 15er Monitor am VGA hing.

Da half nur Ausstecken des VGA vor dem Einschalten des Rechners.

Nun hatte ich also ein Bild - Ton gabs noch nicht, keine Ahnung ob das an den 3 IPTV Kanälen lag, jedenfalls habe ich erstmal nen wirbelscan über dvb-s gemacht. Das schien mein 2 jähriger Sohn zu langweilig zu finden und hat einfach mal eben das gemacht was er nicht darf, den Powerschalter am Fernseher umgelegt.

Und nun habe ich das Dilemma. Nach dem wieder Einschalten des TV und Wechsel auf HDMI2 (da hängt der VDR dran - ich hab aber auch alle anderen HDMIs ausprobiert) gibts kein Bild mehr aufm TV.

Das wirft natürlich 2 Fragen auf:
a) Passiert das jetzt jedesmal wenn man den Fernseher während des VDR Betriebs mal kurz ausschaltet? Wenn ja, dann ist das extrem WAF untauglich.
b) Gibt es einen anderen Weg als einen Reboot um die TV-Ausgabe zu reaktivieren?

Zitat

Original von videoman
sodala, muß mal meine Fragen nochmal hochholen....

Die Frage die sich mir jetzt stellen sind:

1) wie schaffe ich es, das der vdr dann auch seine Videoverzeichnisse automatisch einliest sobald die LW gemountet sind?

2) gibt es sowas eigentlich auch für ext.Festplatten? Oder wie löst man das denn da?

da steh ich nämlich echt aufm Schlauch...

Danke

Alles anzeigen

zu 1)
touch /PfadzumVideoRootVerzeichnis/.update
sollte vdr dazu verführen alle Verzeichnisse ab /PfadzumVideoRootVerzeichnis/ neu einzulesen.

Und du hast doch als Programmierer die Wahl ob du nen einfachen neuen Thread startest oder dir per fork nen neuen Prozess bastelst.
Ich versteh da dein Problem nicht so ganz.

Einfach mal rumgesponnen:
Der Vorteil an Prozessen dürfte sein, dass hier einzig das OS das Scheduling übernimmt und statistisch bei einem ausgelasteten System VDR durch das starten mehrerer Prozesse mehr CPU Zeit bekommt, da der Scheduler jedes Plugin einzeln betrachtet.