Posts by gromit

    Hallo zusammen,


    für das osdpip plugin will ich das notwendige Paket mpeg2dec-0.4.0
    installieren.
    Ich habe es unter /usr/local/src/mpeg2dec-0.4.0 entpackt und dann


    ./configure --prefix=/usr
    make


    ausgeführt. Doch make bricht dann mit dem Fehler:


    .../i486-suse-linux/bin/ld: cannot find -lslang
    ab.
    Den genauen Auszug kann ich später noch nachreichen.


    Weiß jemand Rat ???
    Ich benutze SuSE 8.2 Prof. mit einem 2.4.22 Kernel von ftp.kernel.org.


    Gruss,
    Gromit

    Habe es doch noch geschafft indem ich die Dateien per cp einfach kopiert habe und dann lilo mit dem MLD installer auf die CF Karte installiert habe.


    Der VDR bootet nun von CF, die Addons werden auch entpackt,
    auf dem TV sehe ich wie der Treiber startet, aber dann kommt kein Bild.
    Bleibt alles schwarz. Habe noch nicht herausbekommen was er für ein Problem hat........muss mal in der Doku schauen, ob auf anderen Konsolen irgendwelche Meldungen ausgegeben werden..........



    Gruss,
    Gromit

    Der MLD installer kann die Partitionen nicht mounten, es erscheint die Meldung


    VDR Partition mounten : mount : Mounting /dev/hda5 on /mnt2/system failed


    ???


    Ich denke die Dateien sind richtig drauf, aber lilo noch nicht installiert bzw. der MBR. Habe wie gesagt ein lauffähiges SuSE Linux von dem ich lilo aus installieren könnte. Bin mir aber nicht sicher wie........



    Gruss,
    Gromit

    Hallo !
    Ich möchte die MLD 0.2.1 auf eine Compact Flash Karte, die über einen
    IDE-Adapter angeschlossen ist, installieren.
    Wenn ich benutzedefinierte Installation wähle, erhalte ich
    schon bei der Partitionierung Fehler.


    Also habe ich eine alte HD an den Rechner angeschlossen und auf
    diese die Installation gemacht, hat auch wie erwartet ohne Fehler funktioniert.


    Wie bekomme ich die MLD nun von der HD auf meine CF-Karte drauf ?
    Habe von einem bestehenden Linux auf der CF Karte Partitionen erstellt (hda5 und hda6)
    und diese mit ext2 formattiert. Anschließend dann
    dd </dev/hdg1 >/dev/hda5
    ausgeführt (war das richtig ?), die Dateien waren dann auf der CF Karte
    zu sehen.
    Nun muß ich die CF KArte noch bootfähig machen, d.h.
    lilo einrichten. Wie mache ich das von meinem bestehenden Linux System ohne mir dieses zu
    zerschießen ?
    Der Installer kann die CF Partitionen offenbar nicht mounten, ich erhalte dann immer Fehler
    wenn ich dort den Bootblock schreiben will.



    Gruss,
    Gromit

    Hallo !
    Das gleiche habe ich mich auch schon einmal gefragt,
    mit dem Komplettpatch bin ich zwar zufrieden,
    speziell den WarEagleIcon Patch möchte ich aber nicht haben.


    Ich befürchte aber, dass als Alternative nur bleibt, die einzelnen Patches separat
    auszuführen. Falls es aber eine Möglichkeit gibt den Komplettpatch entsprechend
    zu modifizieren, dass die Patches einzeln anwählbar sind bin ich daran sehr interessiert.



    Gruss,
    Gromit....

    Hallo !
    Also ich habe seit kurzem das gleiche Problem auf meiner SuSE 8.2 Prof.
    aber bisher leider keine Lösung bzw. Erklärung dafür gefunden.
    Die Meldung kommt merkwürdigerweise auch nur wenn ich mich als root unter X anmelde. Ich habe noch einen vdruser eingerichtet unter dem der vdr gestartet wird, wenn ich mich damit anmelde kommt die Meldung nicht.


    Das letzte was ich installiert habe ist vdrconvert inkl. allen notwendigen Paketen......das waren 'ne Menge.
    Ich habe schon vermutet das vdrconvert etwas damit zu tun hat, gerade weil man damit auch Konverierungen nach mp3 vornehmen kann.


    Das Merkwürdige ist außerdem, das ich keine Soundkarte in dem Rechner habe und in der Beziehung bisher (bewußt) nichts eingerichtet hatte - und wozu dann der "Sound Server"....?????


    Weiß jemand Rat ???


    Gruss,
    Gromit..............

    Hallo zusammen,
    ich habe das gleiche Problem, ich möchte zwecks besser Nachvollziehbarkeit
    alle Plugin Ausgaben vom vdr die bei mir auf tty8 geschrieben werden, zu
    testzwecken in ein Log schreiben lassen.
    Die oben erwähnte Lösung mit >> /var/log/vdr.log 2>> /var/log/vdr_error.log
    habe ich nicht hinbekommen.
    Der vdr sollte übrigends weiterhin über das runvdr Skript gestartet
    werden.


    Weiß jemand Rat bzw. kann jemand die Lösung genauer beschreiben wenn das mit der obrigen Zeile irgendwie gehen soll ?


    Oder kann man Linux irgenwie beibringen das alles von einer Konsole gleichzeitig in ein Log geschrieben wird ???


    Gruss,
    Gromit...

    Bistr-o-Math


    Bin nun endlich einmal dazu gekommen den 2.4.22 Kernel zu installieren.
    Nach einigen kleineren Problemen hat es auch geklappt,
    der neueste ACPI-Patch habe ich ebenfalls eingespielt.
    Leider bringt auch der neue Kernel keine Veränderung an dem
    Aufwachverhalten meines Boards. Habe sowohl
    mit shutdown -h now und dem halt (Skript in meiner SuSE 8.2 Installation)
    Kommado in der vdrshutdown getestet.
    Naja, nehme ich halt weiterhin mein geändertes Shutdown Skript.
    Aber trotzdem Danke für den Hinweis.


    Gruss,
    Gromit.....

    Es funktioniert bei mir auch nur mit 'halt' im Grubmenü anstatt dem PowerOff Kernel wie ich jetzt ausprobiert habe.
    Dann liegt es also scheinbar doch nicht an meinem Kernel, sondern an meinem BIOS.
    Gibt es vielleicht noch eine andere Möglichkeit als mit


    shutdown -h now


    den Rechner auszuschalten ?
    Oder muß ich das jetzt so hinnehmen ? Naja es funktioniert ja schon, finde es nur die dauerenden Reboots etwas unschön....


    Gruss,
    Gromit.....

    OK, das leuchtet mir ein, werde weiter mein geändertes vdrshutdown
    benutzen.
    Dann muss ich nur noch herausfinden wie ich meinen Kernel so neukompiliere,
    dass das der Rechner nach dem ausschalten mit shutdown -h auch wieder aufwacht. Verwende im Moment den Standart Suse 8.2 Prof. Kernel.


    Kannst Du mir vielleicht einen Tip geben wie der Poweroff Kernel, der in nvram-wakeup enthalten ist, kompiliert wurde ??
    Damit funktionert es ja....


    Gruss,
    Gromit...

    Möglicherweise haben ja noch andere dieses Problem mit dem shutdown -h, diese könnten dann die neue Option direkt nutzen indem entsprechend kompiliert wird.
    Ansonsten muss jeder das vdrshutdown Skript abändern.
    Gut, dass ist zwar auch nicht das große Problem, aber ich zumindest finde es
    viel einfacher und intelligenter wenn dies direkt ins nvram-wakeup mit einfließt...


    c ya 2,
    Gromit

    Nun... auf die Idee bin ich auch schon gekommen, es funktioniert dann
    auch wie gewünscht.
    Nur finde ich die Lösung etwas unschön, ist es nicht
    vielleicht eventuell möglich dies in nvram-wakeup aufzunehmen ??? *fragendguck* ?(


    z.B. Als zusätzliche Option need_reboot=ALWAYS_WHEN_TIMER
    beim Kompilieren und dann im Coding entsprechend abfragen:


    if( TIMER && (b.need_reboot == ALWAYS_WHEN_TIMER) )
    need_reboot = b.need_reboot;


    an der richtigen Stelle sollte es gewesen sein. Die Abfrage ob ein Timer übergeben wurde hab ich jetzt nicht auswendig im Kopf, deshalb muß TIMER natürlich noch ersetzt werden.


    Was meinst Du, ist das machbar ? ;)



    Gruß,
    Gromit...

    Hi,
    habe es getestet und der Rechner wacht nicht mehr auf,
    es trifft also Deine 2. Vermutung zu.


    Offensichtlich funktioniert das Aufwachen bei mir *nie* wenn
    mit shutdown -h now ein halt ausgeführt wird, sondern
    nur wenn mit shutdown -r now ein reboot ausgeführt und der
    Poweroff-Kernel den Rechner ausschaltet.


    Habe zur Kontrolle mal ins Bios geschaut, dort ist Tag und Uhrzeit
    richtig eingestellt gewesen, das Schreiben ins nvram bzw. rtc hat
    also geklappt.


    Bei mir muß also immer wenn ein Timer übergeben wird, ein
    reboot ausgeführt werden und nur wenn kein Timer vorhanden ist
    darf ein halt ausgeführt werden.
    ;)


    Beste Grüße,
    Gromit...

    Danke für den Hinweis.
    Mit --debug wird nvram etwas gesprächiger. Unter /var/log/message.log
    finde ich folgende Zeilen. Obwohl ich need_reboot mit -1 (ALWAYS) angegeben habe
    sagt nvram in der letzten Zeile need_reboot: 0


    Weiß jemand Rat ?
    Wie sieht das auf anderen Systemen aus die immer einen Reboot brauchen wenn
    nach der 1.Aufnahme ein zweiter Timer gesetzt werden soll ????
    Gibt nvram dort eine 1 zurück (würde ich mal so erwarten...) ???


    Gruss.....Gromit




    Aug 27 15:25:02 linux nvram-wakeup[1625]: Opening /dev/mem in O_RDONLY mode...
    Aug 27 15:25:02 linux nvram-wakeup[1625]: _DMI_ table found: base: 0xF1F60, size: 0x546, count: 45
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Following DMI entries found:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: - Mainboard vendor: ASUSTeK Computer INC.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: - Mainboard type: <CUBX>
    Aug 27 15:25:02 linux nvram-wakeup[1625]: - Mainboard revision: REV 1.xx
    Aug 27 15:25:02 linux nvram-wakeup[1625]: - BIOS vendor: Award Software, Inc.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: - BIOS version: ASUS CUBX ACPI BIOS Revision 1008B4 (Tualatin) CMD 1.9.16
    Aug 27 15:25:02 linux nvram-wakeup[1625]: - BIOS release: 10/15/2001
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Using following bios info:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: need_reboot = -1
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_chk_h = 0x6C
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_chk_l = 0x6D
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_chk_h2 = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_chk_l2 = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_stat = 0x56
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_mon = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_date = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_wdays = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_hour = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_min = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: addr_sec = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_stat = 4
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_mon = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_date = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_wdays = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_hour = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_min = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: shift_sec = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc_time = 1
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc_date = 0x7F
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc_mon = 0x00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc_date_0_is_c0 = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc_mon_0_is_c0 = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: reset_date = 1
    Aug 27 15:25:02 linux nvram-wakeup[1625]: reset_mon = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_stat = 1
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_mon = 4
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_date = 5
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_hour = 5
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_min = 6
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_sec = 6
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_rtc_date = 6
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_rtc_mon = 5
    Aug 27 15:25:02 linux nvram-wakeup[1625]: nr_wdays = 7
    Aug 27 15:25:02 linux nvram-wakeup[1625]: bcd = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: date_no_chk = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: date_hack = 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Opening /dev/rtc in O_RDONLY mode...
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Hardware clock: 2003-08-27 15:25:02
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc.tm_isdst : 1
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtc.tm_gmtoff: 7200
    Aug 27 15:25:02 linux nvram-wakeup[1625]: diff : 0
    Aug 27 15:25:02 linux nvram-wakeup[1625]: RTC is running in localtime!
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Test (this should be the current time of the hardware clock): Wed Aug 27 15:25:02 2003
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Opening /dev/nvram in O_RDONLY mode...
    Aug 27 15:25:02 linux kernel: Non-volatile memory driver v1.2
    Aug 27 15:25:02 linux nvram-wakeup[1625]: The size of /dev/nvram is 128 bytes.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: value of the addr_stat byte is: 0x17.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: value of the rtc_date byte is: 0xA7.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: value of the addr_chk_h byte is: 0x08.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: value of the addr_chk_l byte is: 0x67.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Opening /dev/rtc in O_RDONLY mode...
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Checksum is: 0x0867.
    Aug 27 15:25:02 linux nvram-wakeup[1625]:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: All values are displayed as they are stored in the nvram/rtc.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: (and do not correspond necessarily to the system date/time)
    Aug 27 15:25:02 linux nvram-wakeup[1625]:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: WakeUp : Enabled (0x17)
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtcDate : 27 (0xA7)
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtcHour : 13
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtcMin : 39
    Aug 27 15:25:02 linux nvram-wakeup[1625]: rtcSec : 00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Checksum: 0x0867
    Aug 27 15:25:02 linux nvram-wakeup[1625]:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Enabling (0x17) WakeUp-on-RTC in nvram.
    Aug 27 15:25:02 linux nvram-wakeup[1625]: New rtcDate : 27 (0xA7)
    Aug 27 15:25:02 linux nvram-wakeup[1625]: New rtcHour : 20
    Aug 27 15:25:02 linux nvram-wakeup[1625]: New rtcMin : 09
    Aug 27 15:25:02 linux nvram-wakeup[1625]: New rtcSec : 00
    Aug 27 15:25:02 linux nvram-wakeup[1625]: New Checksum: 0x0867
    Aug 27 15:25:02 linux nvram-wakeup[1625]:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: RTC time is changed. Setting RTC alarm into /dev/rtc
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Setting RTC alarm into /dev/rtc...
    Aug 27 15:25:02 linux nvram-wakeup[1625]:
    Aug 27 15:25:02 linux nvram-wakeup[1625]: Opening /dev/rtc in O_RDONLY mode...
    Aug 27 15:25:02 linux nvram-wakeup[1625]: need_reboot: 0 ?( ?(

    Ich habe ein Reboot-Problem mit nvram-wakeup.
    Bemerken möchte ich noch, dass ich die die Werte für mein Asus CUBX Board
    selber bestimmt habe, da diese noch nicht in nvram-wakeup 0.90 vorhanden waren.
    Mit dem neuen nvram-wakeup 0.91 habe ich das gleiche Verhalten.
    Da nach mehreren Tests mein Board nur dann aufwacht wenn zuvor ein reboot
    in den Poweroff-Kernel geschieht, habe ich b->need_reboot = ALWAYS;
    gesetzt.
    Wenn ich eine Aufnahme programmiere und den Rechner herunterfahre (mit Poweroff
    im VDR manuell ausgelöst) funktioniert alles wie erwartet:


    Der Timer wird gesetzt, nvram-wakeup gibt eine 1 zurück worauf
    das vdrshutdown-Skript einen reboot veranlaßt und der Rechner
    mit dem Poweroff-Kernel ausgeschaltet wird. Ist alles soweit wie gewünscht.
    Der Rechner startet dann auch zur eingestellten Zeit und macht die Aufnahme.


    Das Problem tritt auf, wenn mehr als eine Timer-Aufnahme programmiert ist.
    In diesem Fall läuft die 1.Aufnahme wie erwartet und oben beschrieben.
    Wenn die 1.Aufnahme aber fertig ist, fährt der Rechner ja nun automatisch
    wieder runter, doch nun gibt nvram-wakeup eine 0 (!) zurück, woraufhin nur
    ein halt ausgeführt wird und der Rechner NICHT wieder aufwacht zur 2.Aufnahme.


    Ich habe zur Überprüfung im vdrshutdown-Skript die Übergabeparameter
    in eine Logdatei geschieben und festgestellt, das die 2.Timeraufnahme
    mit allen Parametern korrekt übergeben wird.
    Aber warum denkt nvram-wakeup scheinbar, dass kein Reboot erforderlich ist ???
    Der Rechner verhält sich scheinbar wo als hätte ich b->need_reboot = ON_STAT;
    gesetzt, es ist aber definitiv b->need_reboot = ALWAYS; gesetzt worden.


    Natürlich könnte ich vdrshutdown so abändern, dass immer ein Reboot
    gemacht wird, aber das ist ja nicht der Sinn der Sache.
    nvram-wakeup soll bitte dann auch eine 1 zurückgeben wenn noch ein
    weiterer Timer programmiert ist.


    Da ich mit Linux noch nicht so fit bin würde ich die Ausgaben die
    nvram-wakeup auf die Konsole scheibt gerne zur Kontrolle in eine Logdatei
    schreiben. Wie geht das ?
    Versuche mit der Zeile
    $NVRAMCMD -ls $1 | tee --append /var/log/vdrshutdown.log
    haben leider nicht funktioniert.


    Gruss,
    Gromit