Beiträge von xweber

    Zitat

    Original von TomG
    Welche Versionen von folgenden Paketen sind bei dir installiert?


    y4mscaler
    i 8.1-2


    mjpegtools
    i 1:1.8.0-0.1


    libxine-dev
    i 1.1.1-1vdr2+net1



    btw: das xine plugin (das ich auch selbst übersetzt habe) funktioniert, sobald ich das vdr (binary) von Dir benutze.


    Alex

    Servus,


    ich wollte meinen 1.3.37er mal auf den 1.3.45er updaten. Vital benötige ich das xine pluging um lokal vdr schauen zu können.


    Aufgrund meiner experimentierfreudigkeit compile ich das .deb paket (den source davon) selber. Das hatte bei vorherigen Versionen immer wunderbar funktioniert. Bei der 1.3.45 bekomme ich mit dem selbstgebackenen vdr leider kein TV Bild. Lediglich das Menü wird angezeigt.


    Um die Ursache zu verfolgen starte ich den vdr manuell im Terminal:


    Code
    frame: (0, 0)-(720, 576), zoom: (1,00, 1,00)
    StillPicture: 0xb4792390, 100
    FIXME: xineDevice.c:1063
    GrabImage ...


    dann eine Ausgabe von y4mtoppm]

    Code
    pnmcut: EOF / read error reading magic number
    pnmtojpeg: EOF / read error reading magic number
    
    
    GrabImage failed.


    Was mache ich denn anders als e-tobi bei erstellen des .deb?


    Alex

    Zitat

    Original von chris610
    ... Could not read stream parameters from ...
    Vielleicht weiß ja mitlerweile jemand einen Rat?


    Da ich gerade an der gleichen Stelle war und es mir gelungen ist zumindest diese Meldung wegzubekommen: es war die ACL - also im feed1.ffm Teil. Nachdem ich dort auch die native IP Adresse dazugemacht habe, ging das.


    Leider komme ich alles weitere dann (noch) nicht ans Laufen.


    *EDIT:
    also die obige Fehlermeldung hängt nicht mit der ACL zusammen, sondern mit der Umgebungsvariablen "http_proxy". Scheinbar wird auch versucht 127.0.0.1 via proxy zu erreichen was logischerweise fehlschlägt.


    Alex


    PS: Sorry fürs ausgraben des alten Topics, aber vielleicht geht es noch jemanden wie mir der zum Thema nur die "alten unbeantworteten" findet.

    sorry, ich nochmal.


    ich lese hier:

    Zitat

    bei der Abfrage der VDR-IP Adresse geb ich die Adresse des VDR ein: 192.168.0.100.


    ok. Im Wiki steht:

    Zitat

    d.h. die IP des Servers wird in dieser Lösung fest einkompiliert; es gibt aber bereits einen Patch, der eine dynamische Zuweisung erlaubt.


    Ich tippe mal darauf, das du diesen Patch benutzt hast. Weder im Wiki noch auf Deiner Site wird der aber angegeben (oder ich übersehe es).


    Könntest du bitte den Link einmal posten?



    Dann auch eine Verständnisfrage. Ich habe meine Desktop PC (debian und ein vdr mit xine plugin - keine FF Karte in diesem PC). Wenn ich nun auf meinem Laptop mit xine das Programm vom Desktop schauen will, dann muss ich:
    - das spezielle netwerk-xine auf dem Server compilen
    - auf dem Notebool den speziellen xine netzwerk client compilen.
    oder wo ist da ein denkfehler?


    Danke vorab
    Alex

    Hallo cooper,


    Zitat


    ... ich weiß ja nicht wie deine Zeitrechnung aussieht, aber die Version 0.96, die ich für den Artikel benutzt habe, ist rein zufällig die aktuelle. Ergo: Das Problem gibt es heute genauso wie in den Vorgängerversionen.


    .97 ist aktuell (vom 21. Juli) - mit der Version hat ich es hier letzens zu tun.


    Zitat


    Keines der fünf Mainboards, weder meine drei privaten noch die zwei der Labor-Testrechner, wurde automatisch erkannt. Zwei mal Elito-Epox, ein mal Asrock, ein mal Gigabyte. Das fünfte hab ich nicht mehr im Kopf. Keins der Boards war neuer als 6 Monate.


    Autsch - da hat ich dann wohl wirklich Glück das es bei "meinen" boards eigentlich immer prima ging. Einmal war da auch ein ASRock dabei (das ist das was den reboot brauch)t. Da musste man den Board-Typ als commandozeilen Parameter mitgeben.


    Zitat


    ... wie ich ja im Artikel hypothetisch beschrieben habe (weil ausprobieren konnte ich's mangels Auto-Erkennung nicht)


    Dieses shell script "guess-helper.sh" hattest du mal probiert um so ein "manuelles" conf File zu erstellen?


    Zitat


    Es gibt kein Lilo bei LinVDR.


    Ja, out of the box nicht - ist aber machbar (schonmal gemacht und der Aufwand hielt sich in Grenzen). Wird bei der 0.7 ein gepatcher Grub dabei sein?


    Zitat

    Als Plan B bleibt erst mal nur Settime, so lange ich Nvram auf die Leute nicht wirklich loslassen kann. Denk bitte dran, du hast es hier oft mit Linux-Laien zu tun.


    Jau, ich les hier auch das ein oder andere Posting ;)
    Von daher denke ich aber es wäre den meisten schonmal geholfen wenn man in der setup Maske irgendwo "ankreuzen" kann was man von beiden denn gerne nutzen möchte. Bestimmte notwendige Parameter könnte man dann entsprechend "von Hand" eintragen lassen oder der User muss nur das conf-File anpassen (gibts ja schone einige fertige im nvram-Forum). Ich denke am meisten schreckt ab, das man unter Linux selbst was installieren muss. So ne halb vorgefertigte Sache wo dann nur "noch" kleines Feintuning nötig ist gibts ja auch an anderen Stellen (z.B. graphLCD usw.).


    Alex

    Hallo Mirco,


    Das mit dem 5 mal booten bei nvram - das ist schon ne Zeit lang her. Mittlerweile läuft die Erkennung der Boards viel besser (sofern es schon eingebaut ist). Das findet man recht einfach heraus, indem man "nvram-Wakeup" mal ohne Parameter startet. Auch gibt es einen Kommandozeilenschalter, mit dem man (sofern die automatische Erkennung fehlschlägt) den Boardtyp angeben kann. Dafür bräuchte man aber eine Liste mit den "bekannten" Boards. Keine Ahnung ob sowas schon existiert. Ich werd mich aber gerne an einem script versuchen.


    Das wirkliche Problem beim nvram: Bei manchen Boards ist der "Reboot" beim Runterfahren nötig, damit die Daten auch wirklich weggeschrieben werden. Dafür bräuchte man dann
    a) einen weiteren Kernel (kein Problem, weil da gibts was fertiges) und
    b) lilo um auch wunschgemäß den alternativen Kernel zu starten (Grub kann in der 0.6er linvdr beiliegenden Version leider nicht das Kommando zum automatischen Umstellen des Boot-Kernels).
    Die Umstellung auf b) ist ein wenig "tricky", aber machbar. Jedoch das nur via script zu machen stell ich mir ein wenig zu aufwendig vor.


    Mit dem in dem von mir im zitierten Thread als unkonventionelle Lösung beschriebenen Weg bin ich zumindest bei dem Pundit um dieses Reboot Problem drumherum gekommen. Ein Freund von mir hat ein Board, bei dem er den Reboot braucht. Ich werd ihn mal überzeugen das er seinen linvdr zum Testen mitbringt. Wenn das da dann auch gehen sollte könnte es sein, daß nun ein Weg existiert, der b) umgeht.


    Alex

    Ich hab hier als "Gastrechner" einen Asus Pundit zum vdr-nisieren bekommen. Um auch die Timer fürs Einschalten korrekt und mit Datum ans Rennen zu bekommen hab ich einen etwas unkonventionellen Weg gewählt.


    - APIC alleine schafft es max. die Uhrzeit zu sezten. Datum bzw. wenns im BIOS auf disabled steht bekommt er nicht verändert. Jedoch wird korrekt eingeschaltet.


    - NVRam-Wakeup bekommt zwar die BIOS Einstellung hin, jedoch interessiert ihn das nicht sonderlich. Der Rechner will sich nicht einschalten.


    Bevor ich dann anfangen wollte mit lilo + einem poweroff Kernel zu spielen wollt ich was anderes probieren. Die Mischung machts.


    Also in die poweroff.pl noch eine Zeile dazu die vor dem APIC noch das nvram-wakeup ausfüht... und siehe da: es funktioniert wunderprächtig.


    Micro-HowTo:
    1.) von der sourceforge Seite die nvram-wakeup_0.97-1_i386.deb runterladen und auf dem linvdr plazieren.
    2.) dieses Paket installieren mit "debtool -f nvram-wakeup_0.97-1_i386.deb"
    3.) mit einem Editor (ich mache das mit dem Midnight-Commander) die Datei "/usr/bin/poweroff.pl" editieren.


    Dazu nach

    Code
    if(-e $PROC_ALARM) {
    system(sprintf("echo \"%s\" > %s", strftime("%Y-%m-%d %H:%M", localtime($Next)), $PROC_ALARM));
     } else {


    suchen und ergänzen damits dann so aussieht

    Code
    if(-e $PROC_ALARM) {
        system(sprintf("/usr/sbin/nvram-wakeup -s %s ", $Next));
        dprint("activating nvram /usr/sbin/nvram-wakeup -s ", $Next);
    system(sprintf("echo \"%s\" > %s", strftime("%Y-%m-%d %H:%M", localtime($Next)), $PROC_ALARM));
      } else {


    speichern und viel Erfolg beim Ausprobieren.


    Bitte beachten das für nvram-wakeup der Timer mind. 11 Minuten in der Zukunft liegen muss. Dazu kommen dann noch 5 Minuten die das Script als vorlauf automatisch miteinstellt. Summa sumarum: Nicht mit Timern probieren, die nicht mind. 16 Minuten in der Zukunft liegen.


    Alex