Beiträge von rockclimber

    Zitat

    Original von lola
    gibt es eigentlich schon eine Lösung für ältere Aufnahmen mit falscher index.vdr?


    ja das wäre schön, wenn man die bestehenden Aufnahmen korrigieren könnte. Mit genindex klappt das ja leider nicht.
    Hat da jemand vielleicht eine Lösung?


    Gruß
    Clemens

    hallo nochmal (nach langer Zeit...)


    hatte zwischenzeitlich mal noch ein paar Test's durchgeführt und rausgefunden, dass es an irgend einem (oder mehreren) patch(es) aus dem extensions-patch liegt. Mit vanilla-vdr 1.6.0 hatte es funktioniert. Habe dann einen nach dem anderen patch aus dem extensions durchprobiert, aber keine endgültige Lösung gefunden.


    Verwende lirc an /dev/ttyS0, sollte sich eigentlich nicht beißen - hat mit vanilla-vdr ja auch funktioniert


    Wäre an einer Lösung auch sehr interessiert. Dann können die beiden LED's in der VDR-front auch endlich mal ihren vorbestimmten Zweck erfüllen (habe zwei SAT-Karten, für die mit einer Aufnahme beschäftigte Karte soll jeweils die entsprechende LED leuchten)


    Gruß
    Clemens

    ja, den thread kenne ich und hab das auch schon getestet.
    Und wie Thomas dort schreibt, werden mit dmesg -n1 nur die kernel-Ausgaben unterdrückt.
    Das Problem ist aber, dass vdr und alle über vdr gestarteten scripte/plugins ihre Ausgaben auf das vdr-terminal senden, welches auch für die Tastatureingabe an vdr verwendet wird. Man könnte nun hergehen und alle betroffenen plugins und scripte entsprechend patchen, bzw. umzuschreiben. Aber ich denke, das ist zu ineffektiv.
    Vielleicht gibt es ja eine globale Methode?

    Zitat

    Original von TheChief
    Auf ne andere Konsole wechseln?


    Anders gefragt: Ich möchte GrapfTFT benutzen. Damit mir die vdr-Konsole nicht mein GraphTFT 'zumüllt', stelle ich eine andere Konsole ein, z.B. mit chvt 7 (ich benutze Gen2VDR, aber das dürfte egal sein). Nun habe ich aber das Problem, dass ich die Konsole manuell wechseln muss, um mit der Tastatur Eingaben an vdr zu schicken, was mir wieder das GraphTFT zumüllt.


    Gibt es eine Möglichkeit, Ausgaben von VDR (und allen scripten, die über vdr aufgerufen werden, z.B. mplayer.sh) auf Konsole 'x' auszugeben und Eingaben von Konsole 'y' entgegenzunehmen?
    Würde alternativ die Umleitung ALLER Ausgaben nach /dev/null oder eine andere Datei funktionieren und wie müsste ich dazu vdr starten?

    Zitat

    Originally posted by lexi
    Absoltut unklar irgendwann liefen die karten wieder oder der wechsel in ein weiteres board (gleicher Typ) brachte erfolg.

    das hört sich nach einem Defekt des besagten Boards an. Möglicherweise hing es aber auch mit der BIOS-Version zusammen. Die allerersten BIOS-Versionen liefen nicht so besonders. Das changelog der Hersteller verrät nicht immer alles...
    btw, welche Version ist denn jetzt drauf? bei mir ist es die F6.


    Gruß Clemens

    Zitat

    Original von lexi
    ohne jeglichen mod! "nosmp" sagt mir rein gar nichts. Musste da auch nichts umschiffen. Allerdings hatte ich auch einige Anlaufschwierigkeiten mit diesen board. dvb karten wollten einfach nicht mehr...


    Wie sahen denn die Anfangsschwierigkeiten aus? Und vor allem, was war die Lösung?
    Bei mir wollte es am Anfang nämlich auch nicht so richtig. Bild war nach Einschalten schwarz, VDR manchmal nicht bedienbar und nach Neustarten von VDR hat es dann meistens geklappt. Während des Betriebs gab's dann immer wieder mal kurze Aussetzer, Bildfehler und Treiberresets, selten auch gar kein Bild mehr.
    Nach ein bischen stöbern im forum habe ich einen workaround gefunden. Ähnliche Symptome mit einem DualCore-Prozessor: DVB-S Hauppauge Nexus-S rev. 2.1 problem
    Wie gesagt, Die Probleme werden damit (größtenteils) 'umschifft'. Leider nicht ganz. Aber vielleicht spielt hier ja noch etwas anderes mit rein.


    Hier ist die Ausgabe von lspci:

    Code
    01:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
            Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5
            Flags: bus master, medium devsel, latency 32, IRQ 5
            Memory at fb000000 (32-bit, non-prefetchable) [size=512]
    
    
    01:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
            Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge WinTV-NOVA-S DVB card
            Flags: bus master, medium devsel, latency 32, IRQ 10
            Memory at fb001000 (32-bit, non-prefetchable) [size=512]

    TT 1.5 steckt im Slot 1, die Nova im Slot 3


    Ach ja, Wärmeprobleme schließe ich definitiv aus, da die beiden Karten im alten System in der ungünstigsten Lage (MB senkrecht) im geschlossenen Gehäuse eingebaut waren. Mit g2v 1.2 gab es keine derartigen Effekte. Jetzt stehen beide Karten senkrecht, ein freier PCI-Slot dazwischen und noch keine Haube auf dem Gehäuse. (altes System war BX-2000+ mit PIII-CPU)


    Grüße Clemens

    hi,


    sorry, hab nicht die 1.3'er, sondern die 1.5'er im VDR. Die 1.3'er (mit Spannungsmod) liegt momentan rum und wartet auf eine Reparatur - Fehler ist noch nicht ganz klar, am LNBP liegt's erstmal nicht.
    Das Problem besteht dennoch.


    lexi,


    nutzt Du den original-Treiber, der bei Gen2VDR dabei ist? und wie hast Du das Problem mit dem bei mir notwendigem 'nosmp' umschifft?


    Gruß Clemens

    habe hier die gleichen Probleme, wie theblackraven.
    Treiberreset ist aktiviert. Das Problem tritt trotzdem sporadisch auf.


    Hardware: 1x TT Rev 1.3, 1x Nova; M61P-S3 mit AMD X2 CPU, Gen2VDR 2.0


    Am Anfang wollte es gar nicht richtig laufen. Bei jedem Neustart des Rechners war der Bildschirm erstmal schwarz. Nach Suchen im Forum brachte die Kerneloption 'nosmp' Besserung, so dass beim Starten des Rechners auch gleich ein Bild kommt (nosmp schaltet die Dualcore-Unterstützung aus).


    theblackraven,


    hast Du schon eine Lösung gefunden?

    hab jetzt nochmal etwas getestet - leider immer noch ohne Erfolg ;(
    da mir meine Platte abgeschmiert ist, hab ich Gen2VDR sogar nochmal komplett neu aufgesetzt und das plugin gleich als erstes getestet, mit folgendem Ergebnis:
    wenn das config-file nicht nicht gefunden wird, dann beendet sich vdr mit der Meldung:

    Code
    setup file for serled not found!

    mit config-file startet vdr auch immer wieder durch und hinterlässt im syslog folgendes:

    hat jemand das plugin am Laufen oder kann sonst irgendwie helfen?

    Hallo frausch,


    wollte Dein plugin jetzt auch einsetzen, um 2 Record-LED's anzusteuern. Leider funktioniert es nicht. Sobald ich das plugin aktiviere, gibt es beim Starten des VDR einen segfault, bzw. general protection.

    Code
    Feb 26 21:23:06 [vdr] [15567] starting plugin: serled
    Feb 26 21:23:06 [vdr] [15567] starting plugin: admin
    Feb 26 21:23:06 [vdr] [15567] setting current skin to "soppalusikka"
    Feb 26 21:23:06 [vdr] [15567] loading /etc/vdr/themes/soppalusikka-orange.theme
    Feb 26 21:23:06 [lircd-0.8.3pre1] accepted new client on /dev/lircd
    Feb 26 21:23:06 [vdr] [15567] switching to channel 10
    Feb 26 21:23:06 [kernel] vdr[15567]: segfault at 0820dfe5 eip b7f41428 esp bf88fdec error 7

    Ich benutze Gen2VDR 2.0 mit dem extensions patch 40 (Standard). VDR-Version ist 1.4.7
    Habe das Plugin auch noch einmal neu kompiliert. Ist fehlerfrei durchgelaufen.
    Die Konfigurationsdatei liegt hier: /etc/vdr/serled und hat folgenden Inhalt:

    Leider bekomme ich es nicht zum laufen, auch nicht mit der serled.example. Gibt es hier eventuell Unverträglichkeiten?


    Gruß
    Clemens

    Hi,


    habe heute über einen nfs-mount Dateien kopieren wollen. Das ging allerdings seeeehr langsam mit weniger als 1 MByte/s. Da stimmt doch was nicht!


    folgende Punkte waren alle i.O.:
    - richtiger Netzwerktreiber
    - richtige Geschwindigkeit eingestellt -> 100Mb/s
    - Performance mit netio gemessen (Packet size 1k bytes: 10504 KByte/s Tx, 11455 KByte/s Rx. )


    Sieht ja auf den ersten Blick ganz gut aus. Nur warum ist nfs dann so Schneckenlangsam?


    Nach weiteren Recherchen bin ich dann auf die Optionen in /etc/exports gestoßen:

    Code
    /video	  *(rw,no_root_squash,async)


    hier habe ich anstelle sync async eingetragen (und rw für Schreibzugriff)


    Jetzt habe ich eine Transferrate von über 6 MByte/s. Das ist zwar immer noch nicht das maximal mögliche, könnte aber auch an dem einen (etwas älteren) Rechner liegen.


    Grüße,
    Clemens


    PS: Basis ist Gen2VDR 2.0