Posts by gerald

    Hi,

    auf einem neu installierten Rechner (gentoo distribution) habe ich das Problem das keine peer-to-peer Verbindung zustande kommt mit einem anderen Rechner funktioniert es, alles laufen auf mit gentoo, aktueller Stand. Der Server und der 1. Desktop Rechner funktionieren auch. auf dem neuen kann auch svdrpsend -d <server> Befehle abgesetzt werden die auch funktionieren.

    Bin für jeden Tip dankbar.


    Ausgabe aus der Server Log

    ==> /var/log/messages <==

    Sep 30 16:23:09 grde01s002 vdr[13953]: [14001] SVDRP grde01s002 < 10.76.0.68:53439 discovery received (SVDRP:discover name:grde01c002 port:6419 vdrversion:20702 apiversion:30005 timeout:300)

    Sep 30 16:23:09 grde01s002 vdr[13953]: [14001] ERROR (svdrp.c,204): Verbindungsaufbau abgelehnt

    Sep 30 16:23:09 grde01s002 vdr[13953]: [14001] SVDRP grde01s002 > 10.76.0.68:6419 ERROR: failed to create client for 'grde01c002'

    Sep 30 16:23:09 grde01s002 vdr[13953]: [14001] SVDRP grde01s002 > 10.76.0.68:6419 client destroyed for 'grde01c002'

    [/code]

    Ausgabe auf dem Client

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3906] SVDRP server handler thread started (pid=3873, tid=3906, prio=low)

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 opening port 6419/tcp

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 listening on port 6419/tcp

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3907] SVDRP client handler thread started (pid=3873, tid=3907, prio=low)

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3907] SVDRP grde01c002 opening port 6419/udp

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3907] SVDRP grde01c002 listening on port 6419/udp

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3907] SVDRP grde01c002 > 255.255.255.255:6419 send dgram 'SVDRP:discover name:grde01c002 port:6419 vdrversion:20702 apiversion:30005 timeout:300'

    Sep 30 16:48:10 grde01c002 vdr[3873]: [3873] OSD size changed to 1920x1080 @ 1

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37408 client connection accepted

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 > 127.0.0.1:37408 server created

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37408 connection closed

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37408 server destroyed

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37424 client connection accepted

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 > 127.0.0.1:37424 server created

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37424 message 'Warning: VDR process died.'

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37424 connection closed

    Sep 30 16:48:11 grde01c002 vdr[3873]: [3906] SVDRP grde01c002 < 127.0.0.1:37424 server destroyed

    Sep 30 16:48:11 grde01c002 vdrwatchdog[3922]: VDR has been restarted


    Danke für den Tipp, hab mal in der ddbridge-max.c den parameter fmode mit 3 initialisiert und jetzt haben die 2 Aufnahmen funktioniert.

    Danke vielmals, werde das mal per Mail weitergeben, an den Herrn mit dem ich in Kontakt bin von Digital Devices

    :) :thumbup:

    Hallo,

    zur Zeit baue ich einen neuen Server, in den auch eine neue Sat Karte kommt, mein altes System 2 Cine S2 mit 1 Duoflex S2 also insgesamt 8 SAT-Anschlüssen (die sind auch alle mit einem Splitter Verbunden) funktionieren mehr oder weniger 4 Eingange der 8 sind in der zwischenzeit defekt, aber dafür gibts ja Parameter -D.

    in meinem neuen System befindet sich eine DD Max SX8, betreiben möchte ich sie mit "fmode=3" also nur ein Kabel am obersten Anschluss der Karte damit ich 8 Tuner benutzen kann.

    Hab die VDR Konfiguration meines alten Systems welches mit den CineS2 Karten funktioniert kopiert, und die scr.conf angepasst.

    Habe dann auf dem neuen System auf "Das Erste HD" und auf "ZDF HD" eine Aufnahme gestartet (was am alten System funktioniert), eine Aufnahme gestartet, hier stürzt vdr mit emergency exit ab. Eines der beiden aufnahme Verzeichnisse ist leer.
    Habe dann auch mit "fmode=3" und ein 2 Sat Kabel am zweiten Anschluss von oben angeschlossen, jetzt funktionieren 2 Aufnahmen.

    Ist die Karte evtl defekt oder stimmt mit dem Rest etwas nicht (Treiber sind aus dem git von Digital Devices, keine Kernel Treiber).

    Oder muss ich bei VDR doch etwas anderes machen.

    Anschluss:

    Quattro LNB -> Multiswitch -> DdCSS Switch -> DUR-Line Splitter (D3FV) -> Sat-Karte

    LNB und Switche von Televes.

    Eigentlich will ich ja minisatip machen, damit funktioniert das alte System super, das neue mit der Max SX8 Karte stürzt ab auch hier bei der Nutzung von z.B. 2 Aufnahmen.

    Gruß Gerald

    insgesamt sind ja Adapter 0-3 an der Kombination Cine S2 DuoFlex vorhanden, von diesen ist Adapter 0 und Adapter 2 defekt, also ein Port auf der Cine und einer auf der DuoFlex. Für dies Kombi habe ich bisher VDR benutzt.

    Weiterhin ist noch ein alte TT S2-3200 vorhanden die ich mit minisatip betreibe, diese Karte wollte ich schon durch eine TWIN-Karte ersetzen.

    Ich könnte jetzt die TT S2-3200 durch die teildefekte Kombi von oben ersetzen und mir eine neuere Cine S2 und DuoFlex Karte kaufen.

    Meine Frage ist könnte ich auch eine DD MAX S8 zulegen die an einer TechniSwitch Kaskade hängt und 6 der 8 Tuner mit VDR nutzen und 2 Tuner für minisatip nutzen.

    Hi,

    Befehlszeile:
    lircd --version
    modinfo lirc_dev bzw. modinfo lirc_serial

    da steht dann auch was mit filename dieser Treiber aus dem angezeigten Verzeichnis wurde automatisch geladen. Du kannst auch mit find /lib -name lirc_* nach Treibern im lib Verzeichnis suchen evtl. wird ja ein falscher geladen.

    Soweit ich mich erinnern kann funktioniert aber nur noch lirc-0.9.0 mit einem Kernel grösser 2.6.36.

    Falls Du mehrer Lirc Treiber findest könntest Du auch lirc stoppen und mit rmmod lirc_serial und rmmod lirc_dev diese entladen und mit insmod <Pfad zu anderen Treibern>/lirc_dev.ko und dann noch insmod <Pfad zu anderen Treibern>/lirc_serial.ko diese laden und lirc wieder starten.

    gruß gerald

    Hi,

    ab Kernel 2.6.36 sind die Treiber für Lirc im Kernel und funktionieren nur noch mit Lirc 0.9.0.
    Ich hatte ebenfalls einen gekauften Home-Brew Receiver, der funktioniert allerdings gar nicht auch nicht mit dem neuesten Kernel, da ich auch noch einen selbst gelötet habe war das nicht so wild, der funktioniert. Ich weis nur nicht mehr ab welcher Kernel Version mit der 2.6.36 lief der selbst gelötete ebenfalls nicht.

    Entweder Downgrade vom Kernel kleiner 2.6.36 oder Upgrade von Lirc auf 0.9.0

    Gruß
    Gerald

    hallo

    schaue schon eine weile TV und hab wild herumgezappt und immer wieder das OSD aufgerufen.
    irgenwann blieb das Bild komplett stehen. Nach einer weile schlug der VDR Watchdog zu und VDR hat einen Neustart gemacht. Im Syslog hat es mit folgenden Meldungen vom Treiber angefangen keine Fehlermeldung zuvor von VDR

    treiber saa716x_ff habe ich mit folgenden options saa716x_ff verbose=1 int_type=1 geladen
    alle anderen benötigten Treiber ohnen options

    Treiber sind mit saa716x_ff_demux_worker_test_2.diff Patch von UFO jedoch nicht saa716x_ff_demux_worker_test_1.diff

    Watchdog ist bei mir auf 60 Sekunden eingestellt, da mein vdr start skript die Treiber grundsäztlich entfernt und neu lädt und ich zwischendurch auch sleeps eingebaut habe sind die Fehlermeldung auch gekommen als vdr selbst schon beendet war. Meldung kamen bis Treiber entladen wurden.

    Da das Artefakteproblem per Stop/Start nicht so einfach in den Griff zu bekommen ist,
    hier ein etwas anderer Ansatz, um den Workaround ganz zu vermeiden.

    Der Datenpuffer muß nun nicht mehr mit einem Sync-Byte beginnen, d.h. Pakete dürfen unaligned sein.

    Bitte den angehängten Patch testen.

    CU
    Oliver

    habe jetzt ein paar tests gemacht funktioniert wesentlich besser beim neustart, und auch beim wechseln der Tonspur bei Sendern mit hoher Datenrate. Hatte da manchmal schwarze Ausgabe oder Artefakte.

    gerald

    OK, guck ich mir mal an

    MSI geht jetzt auch:

    Auszug dmesg:

    Auszug cat /proc/interrupts

    Code
    CPU0       CPU1       CPU2       CPU3       
     44:   16362901   16360504   16356017   16362729   PCI-MSI-edge      SAA716x Core

    der Treiber saa716x_ff wird mit type=1 geladen.

    Quote


    Ist der Fehler auch in Aufnahmen vorhanden - reproduzierbar immer an der gleichen Stelle?
    Falls ja, eine solche Stelle bitte ausschneiden und irgendwo hochladen.

    habe mal ein Stück hochgeladen ca. 39mb (ist jedoch was altes .vdr). Bei 43 sek. bleibt das Bild hängen, am Receiver bleibt DD5.1 an. Beende ich das apspielen bleibt der Bildschirm dunkel. Der Treiber saa716x_ff muss man entladen VDR beenden Treiber wieder laden und VDR starten dann funktioniert wieder alles.

    Dieselbe Aufnahme funktioniert mit vdr-1.7.18 mit einer SD-FF Karte sowie mit vdr-xine (vaapi oder ohne vaapi), beides mal mit Version vdr-1.7.18

    cu
    gerald

    Edit: link gelöscht da Datei nicht mehr vorhanden ist und Problem gelöst ist.

    Hallo

    habe das Image openwrt-vdr-1.7.14.tgz auf einen BA USB Stick installiert.
    Das Image kann ich im Boot Menü auswählen, es wird auch gelesen vom USB Stick.

    Es wird jedoch nichts am Fernseher angezeigt. Ping auf die UFS IP geht.

    Meine Frage ist:
    1. ist das Image für eine UFS910 14W geeignet.
    2. falls ja kann man mir die Bootargumente mitteilen

    oder müssen evtl. Dateien ausgetauscht werden für die UFS910 14W Version

    Gruss
    Gerald

    PS:
    schönes neues Jahr

    Hi,

    Quote

    Original von LordJaxom
    Falls mir gestern eine Mail zugegangen ist schonmal sorry im Voraus, aber irgendwie beschleicht mich der Eindruck dass es ganz gut wäre wenn man mich über solche Patches (korrektur von spumux-xml) auch mal informiert, damit ich sie im Plugin auch korrigieren kann :D

    hatte noch keine Mail gesendet, ist aber unterwegs da noch andere Punkte nicht astrein sind, so das mit burn-plugin erstellte DVD an möglichst vielen Geräten bzw. Softwareplyern läuft.

    cu
    gerald

    derTHOMMESisses

    das liegt daran das der spumux nicht korrekt erstellt wird für standalone player.

    irgendwo im source code muss was stehen mit

    Code
    <spu start="00:00:00"

    der Teil muss erweitert werden um

    Code
    end="00:00:10"

    der hintere Teil gibt die Anzahl Sekunden an. für Standaloneplayer (nicht für alle) muss eine Ende Zeitangabe gemacht werden. Wenn ich mich noch richtig erinnere müssen das mind. 4sec sein. Ausserdem muss noch ein Pause="0" für pgc entries eingetragen werden.

    So wie das burn-plugin zurzeit die xml Dateien erstellt werden Menüs bei dir nicht funktionieren.

    edit:
    evtl reicht in config.c folgende Einträge zu ändern: