Beiträge von somebody101

    hi
    hatte vor kurzem ein ähnliches problem. eine frage: nutzt du den suse standartkernel oder hast du dir vor kurzem einen eigenen gebacken ?
    Bei mir lags nämlich am kernel. der suse standartkernel der version 8.1 und 8.2 (2.4.19 bzw. 2.4.20) ist mit patches versehen...u.a. auch mit acpi-patches. die kernel von kernel.org beinhalten diese patches nicht. acpi wird in den original-kerneln erst ab der 2.4.22 unterstützt (ist jedenfalls mein wissensstand...korrigiert mich, wenn ich falsch liege). Jedenfalls hat sich das bei mir genauso geäussert: rechner direkt nach dem anschalten wieder ausgeschaltet...wakeup-events funktionierten. Rechner hochgefahren und mit shutdown wieder runtergefahren...kein wakeup-event ging !
    ich hab mir dann den 2.4.22er geholht, kompiliert und schon ging's wieder...


    vielleicht isses das ja.


    gruß
    rob.

    hallo zusammen,


    ich kriege das mit streamdev irgendwie nicht ans fliegen. bei mir sieht's wie folgt aus:


    VDR_Server steht im Keller (siehe Signatur), streamdev (modifiziert wg. Autopid) ist installiert, in den Options ist der VDR-to-VDR-Server gestartet (Port usw. auf default)


    2. Rechner ist ausgestattet mit eine DVB-S 1.3 (fullfeatured), allerdings ist da kein Sat-Kabel angeschlossen !. Hier hab ich erstmal versucht, den VDR so wie auf dem Server zu installieren (allerdings ohne die meisten Plugins) und ebenfalls nochmal Versucht, einen vanilla zu installieren. Beidesmal hab ich hier den VDR-to-VDR-Client gestartet und die IP des Servers angegeben. Weiterhin hab ich noch die channels.conf des Servers in das /video-Verzeichnis des Clients kopiert. Soweit so gut, ich konnte beidesmal den VDR auf dem Client starten, jedoch bekomme ich kein Bild. Ich habe die EPG-Synchronisation aktiviert, die funktioniert auch. Wenn ich also umschalte, sehe ich die EPG-Daten, jedoch kein Bild und kein Ton. Mir ist hier noch einiges unklar...z.B. muß der client auch autopid-gepatched sein, wenns der server ist ?
    Ich habe den verdacht, der client versucht das programm über die eingebaute dvbs zu bekommen (was nich geht, weil kein satkabel dran ist) und nicht über streamdev.....
    ...was mach ich nur falsch ?


    hier mal ein auszug meiner log:



    gruß
    rob.

    hi zusammen,


    also der xntpd läuft bei mir nicht. ich glaube aber, den übeltäter gefunden zu haben:
    in den files /etc/init.d halt sowie in /etc/init.d/reboot in folgende zeile enthalten:


    /sbin/hwclock --systohc $HWCLOCK


    ...sowie in dem file /etc/init.d/boot.clock:


    /sbin/hwclock --adjust $HWCLOCK
    /sbin/hwclock --hctosys $HWCLOCK


    ...da ich momentan nicht zuhause bin und nur übern webmin auf meine kiste zugreife, kann ich die files nicht editieren. ich habe aber mal /sbin/hwclock umbenannt, sodaß es von den skripten nicht mehr gefunden wird, und siehe da, die zeit stimmt wieder nach einem reboot...die einträge werd ich heut' abend rausschmeissen und hoffen, daß es dann klappt....ich verstehe nur nicht, warum das bis gestern keine probleme verursachte....an den dateien habe ich sicherlich nicht rumgespielt... :(


    hmmm
    gruß
    rob.

    hi,


    danke für die rasche antwort. ich denke aber, das hat nix mit set_timer zu tun. ich stelle das datum mittels date und auch mittels hwclock --set --date blabla. dann mache ich einen reboot....set_timers wird hier also gar nicht aufgerufen. Den set_timer aufruf beim systemstart (vor dem vdr) habe ich ebenfalls rausgenommen...also ist nach meinem verständnis set_timers überhauptnicht im spiel...und trotzdem ist die zeit falsch...


    gruß
    rob.

    hi zusammen,


    wiedermal ein nettes problemchen bei mir:
    da nvram-wakeup von meinem board nicht unterstützt wird, hab ich bei mir die set_timer-geschichte konfiguriert. klappte auch bestens. gestern war nun nach einem reboot die zeit plötzlich falsch. mit date wieder gesetzt, jedoch nach einem reboot wieder falsch. das spiel wiederholt sich nun nach jedem reboot:


    Auf dem system die zeit gestellt, danach gibt date und hwclock folgendes aus:

    Code
    > date
    Tue Oct 14 14:03:18 CEST 2003
    > hwclock
    Tue Oct 14 14:03:26 2003  -0.251327 seconds


    dann rebootet, und date und hwclock sieht wieder so aus:

    Code
    > date
    Sat Oct  4 17:37:46 CEST 2003
    > hwclock
    Sat Oct  4 17:37:53 2003  -0.770784 seconds


    hat jemand ne idee ??


    gruß
    rob.

    hi micmac,


    danke für die schnelle antwort. der download der 2.4.22-sourcen läuft schon (hehe)


    ich sach bescheid, ob's geklappt hat...


    gruß
    rob.


    ps. den 2.4.21 hab' ich mir bereits selbst gebastelt. hab zwar erstmal make oldconfig gemacht, bin dann aber nochmal mit make menuconfig alles durchgegangen und hab noch einiges rausgeschmissen. aber bei acpi hab ich nix verändert und die config sieht für mich auch so aus, als wär' sie so ok...naja...gucken wir mal, was die 2.4.22 bringt...ansonsten habe ich gerade eben mein suse 9.0-päckchen bekommen...damit wird's hoffentlich gehen ;-.)

    hi zusammen,


    hab wiedermal ein tolles problemchen.
    Aufgrund eines Boadwechsels musste ich auf einen neuen Kernel updaten. Hierfür habe ich mir die Sourcen von kernel.org des 2.4.21 runtergezogen und mit make oldconfig usw. einen neuen Kernel gebastelt, der auch eigentlich wunderbar funktioniert. Jetzt habe ich aber ein problem mit dem acpi, daß sich wie folgt darstellt:


    wenn ich das system mit shutdown -h now (oder poweroff) runterfahre, reagiert keine Wake-Event mehr. Sprich, nach einem shutdown kann ich die Kiste weder mit WakeonLan, noch mit WakeonKeyboard (oder auch WakeonRTC) starten. Es muß mit dem Kernel zu tun haben, da ich folgende Tests durchgeführt habe:


    Rechner einschalten und im GRUB-Bootmenü wieder ausschalten (mit PWRButton) ---> Alle Wake-Events funktionieren !


    Rechner mit meinem alten Suse-StandartKernel (2.4.19) starten und Linux mit shutdown -h now runterfahren ---> Alle Wake-Events funktionieren !


    Rechner mit meinem neuen Kernel starten und Linux mit shutdown -h now runterfahen ---> KEIN Wake-Event funktioniert.


    Kann imir jemand sagen, welcher Kernel-Parameter hierfür verantwortlich ist ?


    Bei mir sieht's etwa so aus:



    Ich weiß nicht, was sonst noch relevant ist....vielleicht kann mir ja jemand helfen...


    Danke im voraus


    Gruß
    Rob.

    Hallo zusammen,


    nachdem Olaf hier über seine schlechten Erfahrungen beim Boardtauschen berichtet hat, will ich hier auch mal die Geschichte meiner drei letzten Tage zum Besten geben...
    ALSO, ich hatte mir das ASUS A7N8X-Deluxe (Rev. 2) mit nem 2600er Athlon zugelegt. Nachdem auch ich mich vorher informierte, das es unter Linux recht unproblematisch ist, ein Board zu tauschen, hab ich einfach d'rauflosgetauscht. Nachdem das Board eingebaut war und alles notwendige verkabelt war, kam nach dem Einschalten gleich der erste Schock. Segmentaition faults noch und nöcher. Nach unzähligen Fehlermeldungen kam aber tatsächlich der Login. Beim nächsten Start dann ACPI ausgeschaltet, und schon sah es etwas sauberer aus (aber immernoch mind. 7 Segfaults beim hochfahren). Dann erstmal die Netzwerktreiber für Linux auf dem Win-Rechner auf CD gebrannt, um die dann auf dem Linux Rechner zu installieren. Beim mounten der CD gab's dann nen Komplettabsturz. Nix ging mehr...nur noch der Reset-Knopf. Beim Versuch, den Fehler zu beheben hat sich das spielchen mehrmals wiederholt was mich wahnsinnig freute, da ich noch eine 160Gig Platte als ext2 hatte und er jedesmal einen fsck machte, der fast ne halbe Stunde dauerte (mittlerweile hab ich's auf ext3 umgestellt ;-)...letztlich lag's am DMA-Modus, den ich nicht aktivieren durfte, wenn ich das DVD-Laufwerk nutzen wollte...Soweit, so gut, Netzwerk ging dann und das System lief erstmal....allerdings alles andere als stabil. Innerhalb von ca. 10 Stunden Testberieb hat sich der Rechner 5 mal komplett aufgehängt...ohne ersichtlichen Grund...auch in den Logs was nix zu finden. Der nächste Hammer war dann, das man im Bios des Asus Boards für WakeonRTC (Wake on Alarm) keinen Tag einstellen kann...sprich: nur Stunde, Minute, Sekunde...man kann also nur eine AlarmZeit für den gleichen Tag einstellen...KO-riterium für nvram-wakeup. Das und die Instabilität des Boards unter Linux (selbst eine Neuinstallation führte zu abstürzen) brachte mich dann zum entschluss, das Teil wieder auszubauen. Testweise habe ich dann ein Tyan Tiger mit 2 Athlon CPU's eingebaut. Selbes Spiel. SegFaults ohne ende. Also wieder mein altes, ursprüngliches QDI-Board eingebaut und schon schien die Sonne wieder (dank restore). Alles lief wieder, nur eben uf der alten Hardware. Das Asus-Board habe ich dann wieder schön eingepackt und meinem Händler zurückgebracht. Einen Versuch wollte ich noch machen, und so habe das Asus dann gegen ein Epox 8KRA2+ umgetauscht.
    So, und hier muß ich sagen, das auch alle, die meinten, ein Boardtausch unter Linux sei unproblematisch, ebenfalls recht haben. QDI-Board wieder ausgebaut, Epox-Board eingebaut, angeschaltet und der Rechter fuhr ohne auch nur eine einzige Fehlermeldung hoch...VDR gestartet..und gefreut.
    So habe ich mir das vorgestellt !! Natürlich habe ich die ganzen Funktionen, die dieses Board mitbringt (SerialATA-Raid, UDMA-Raid, USB2.0, Firewire...usw) noch nicht getestet, und auch nvram-wakeup ist noch nicht eingerichtet (wenns interessiert, kann ich noch darüber berichten), aber davon war ich auch beim Asus-Board noch weit entfernt. Das Epox läuft zumindest jetzt erstmal...seit ca. 8 Stunden, ohne Absturz.
    Also, es kommt wohl auf das Board an (oder auf den Chipsatz), das man verbaut. Eine Regel gibt es aber wohl nicht.


    so long.
    rob.

    Hi zusammen,


    es ist zum verrücktwerden ! Ich bin jetzt nun seit mehreren Tagen auf der Suche nach einem vernünftigen neuen Board, welches mit meinem VDR und nvram-wakeup zusammenarbeitet...ich komm auf keinen grünen Zweig, weil's meistens daran hängt, das unklar ist, ob nvram-wakeup damit läuft.
    Ich benötige:


    Athlon-Board (mind 2600+, möglichst mit Barton-Unterstützung)
    mind. 5 PCI-Slots (6 wären besser)
    unbedingt 2 Serielle Schnittstellen
    nvram-wakeup (mit oder ohne reboot) muß funktionieren


    Nette goodies, aber nicht lebensnotwendig wären:
    LAN on board
    Firewire
    Raid
    Sound on board


    Das Asus A7V8x bzw. A7N8x scheiden aus, da nur 1 serielle Schnittstelle. Vom A7N8x gibts ne Deluxe-Version mit 2 seriellen Schnittstellen...aber keine info bezüglich nvram-wakeup bzw. eventuelle Probleme mit Suse (?)


    Im Rennen sind neben besagter Asus-Deluxe-version noch:


    Epox EP-8KRA2+
    Gigabyte GA-7N400 Pro


    Aber auch hier keinerlei Infos bezüglich der Funktionsfähigkeit mit nvram-wakeup vorhanden.
    ALSO: sollte einer eines der genannten Boards mit nvram-wakeup am laufen haben, BITTE Bescheid sagen !!!


    Wer noch weitere Boards kennt oder hat, die oben genannte Kriterien erfüllen und noch erhältlich sind..bitte ebenfalls posten...


    Danke schonmal im voraus...


    Gruß aus Frankfurt
    Rob.

    also ich kann das zunächst mal nicht bestätigen. requant lieferte bei mir bisher ziemlich gute ergebnisse ab. der tip mit der demo ist nicht zu verachten ;-)...sollte der demomodus im sourcecode nicht deaktiviert worden sein, gibts regemäßig so etwa alle minute eine ziemliche klötzchenbildung....aber wie gesagt, mit abgeschaltetem demo siehts ziemlich gut aus...aber vielleicht habe ich auch einfach nur weniger anspruch bezüglich der filmqualität...


    gruß
    rob.

    hi zusammen,


    bei meiner suche nach einem neuen board für meinen vdr bin ich über oben genanntes board gestoltert. Ist für Athlon CPU's, hat usb2.0, firewire, lan und raid...und kostet gerade mal 49 euro...und ist somit sehr interessant :)


    Leider konnte ich bezüglich der zusammenarbeit mit nvram-wakeup weder hier im board etwas finden, noch steht es in der aktuellen nvram-wakeup-mb.c drin.


    Hat jemand dieses board oder kann mir etwas dazu sagen ??


    Gruß
    rob.

    hi zusammen,


    ich habe vor, mir ein neues Mainboard samt schnellerem Prozessor zuzulegen. Dabei würde ich mich gerne auf den Hardwareumbau beschränken...soll heißen, ich will mein Linux nicht neu aufsetzen. Hat schon jemand Erfahrung gesammelt, ob es klappt, das Board zu tauschen ( iss dann auch ein anderer Chipsatz), ohne linux (Suse 8.1) neu zu installieren. Ich weiß, daß Windows einem einen Boardtausch recht übel nimmt...er erkennt zwar dann alles neu, iss aber meistens ziemlich unstabil, sodaß man windows letztlich doch neu installieren muß...nur wie ist das bei linux ??


    gruß
    rob.

    hi,


    also, da muß irgendwo der wurm drin sein. mein vdr läuft seit januar diesen jahres...und zwar rund um die uhr (wird 2x pro woche per cron durchgebootet). er ist die einzige tv-quelle für das ganze haus (im wohnzimmer steht zwar ein receiver als backup, ich kann mich aber nicht mehr erinnern, wann ich den das letzte mal eingeschaltet habe).
    bisher habe ich noch keine programmierte sendung verpasst, die ich sehen wollte...er hat immer alles aufgezeichnet.
    ich kann nur sagen...der läuft extrem stabil (da hatte ich früher mit meinen humax und hyundai und d-boxen wesentlich öfter abstürze).
    der vdr auf linux ist so ziemlich das beste, was mir je unter die finger gekommen ist....wenn du ein hw-problem ausschliessen kannst, probiers mal mit ner vollständigen distri (hab die ct nicht installiert)...und du wirst staunen...


    gruß
    rob.

    hi BugB,


    das problem mit dem 'xste-palette.rgb' - file hatte ich anfangs auch. das file müsste zum zeitpunkt, wenn dvdauthor gestartet wird, unter /tmp liegen. Im skript vdr2dvd.sh einfach mal schauen, wo der aufruf für den dvdauthor ist. in diesem aufruf wird das betroffene file mit $XSTE_PALETTE aufgerufen....


    Code
    nice -${PRIO} $DVDAUTHOR -v $DVDNORM+$ASPOPT -a $AUDIO_OPTS -o ${UniqueDVDDIR} -m -b 420x450-450x480,vts1 -b 420x500-450x530,vmgm1 ${UniqueDir[Number]}/${Titel}_menu.mpg $postaction_menu -p $XSTE_PALETTE -t -c `cat ${UniqueDir[Number]}/chapters.vdr` ${UniqueDir[Number]}/${Titel}.mpg $postaction >> $LOGFILE 2>&1


    ...hier habe ich dann einfach mal in allen dvdauthor-aufrufen im skript vdr2dvd.sh das $XSTE_PALETTE ersetzt durch /tmp/$XSTE_PALETTE...


    ...dann gings auch weiter...


    gruß
    rob.