Beiträge von Eckieck

  • diverse Fehler im Syslog bei Verwendung von Yakumo Quickstick DVB-T als 2. Budgetempfänger im VDR

    Huch dort wird ja auf mein Patchfile verlinkt, dessen wirkliche Quelle dieser Thread ist.


    Also ich habe 4 Sticks seit meinem letzen Post hier so im Einsatz. Um den Patch anzuwenden brauchst du die Sourcen von vdr (in meinem Fall vdr 1.4.7) und ggf. den Patch (http://tafe.unkelhaeusser.de/vdr/dvbdevice.c.patch) bzw wie hier beschrieben dvbdevice.c Datei anpassen, ist dasselbe.


    VDR entpacken und in das neue VDR-Quellverzeichnis wechseln und dann einfach "patch < ../dvbdevice.c.patch" - kennst Du oder?


    Dann VDR "übersetzen", da gibts im Wiki hier ne Menge Lektüre zu. Wenn Du eine Frage dazu hast, nur zu.

  • Softdevice xv: Bild nach OSD-Aufruf weg/überdeckt

    Ich habe bei mir noch einen Snapshot von ffmpeg vom 23.10.2007 gefunden und damit den heutigen softdevice snapshot neu übersetzt. Immerhin hat sich das Problem jetzt verändert.


    Über XV habe ich jetzt zusätzlich auch kein OSD mehr, also ein Rückschritt. Nur den Bruchteil einer Sekunde ist kurz das Kanal-info OSD zu sehen - diesmal auch hier mit vertauschten Farben genau wie vorher nur im ShmClient.
    Wie der Stream aussieht kann ich nicht sagen, da ich das OSD nicht aufrufen kann um die Wiedergabe kurz zu stoppen.


    Mittels ShmClient habe ich jetzt wenn ich das OSD aufrufe ein transparentes OSD mit dem aktuellen Stream im Hintergrund (Farben sind aber weiterhin vertauscht, nicht nur vom Stream, auch vom OSD, so ist das OSD statt gelb himmelblau.
    Die Freude war groß :> Aber sobald ich das OSD wieder ausblenden lasse ist der Stream zu 99% von der nahezu schwarzen Fläche überdeckt - wie zuvor. Sound läuft wie eh und je weiter. OSD neu einblenden lassen funktioniert dann auch nicht mehr.


    Edit: Die oben bescheibene Änderung lag leider nur an der Option softdevice.OSDalphablend = 1 bzw 0 (pseudo oder software). Also hat sich im Grunde auch mit dem neuen Snapshot von ffmpeg nix geändert.

  • Softdevice xv: Bild nach OSD-Aufruf weg/überdeckt

    Wenn ich als Ausgabe shm verwende kommt ein Bild, wenngleich auch die Farben nicht stimmen (Blau ist Rot z.B.) und sobald ich einmal das OSD aufrufe ist auch hier das Fernsehbild wie bei vo: xv überdeckt von diesem schwarz-gelb.


    Das Problem scheint also irgendwo im Alpha-Blending zu stecken. Bei vo: xv wird direkt beim Start das OSD angezeigt, bei ShmClient nicht, deshalb wird es da gehen bis ich das OSD aufrufe oder umschalte - da wird eben auch das OSD aufgerufen.


    Leider funktioniert bei mir mit der alternativen Blending-Option "software" nichtmal das OSD, also auch keine Lösung QQ


    Hin und wieder wenn ich ShmClient einfach weiterlaufen lasse (10+ Minuten) nachdem das Bild durch einen OSD Aufruf verdeckt wurde erhalte ich wieder ein Bild, wenn auch merkwürdig proportioniert, siehe Bild:


    [Blockierte Grafik: http://img12.myimg.de/17022008364074a6_thumb.jpg]


    ShmClient meldet im selben Moment:


    dsyslog:[VideoOut]: 704x576 [0,0 704x576] -> 720x576 [220,0 277x576]


    Weiß irgendwer wo ich ansetzen könnte bzgl. der fehlerhaften Transparenz? Oder kennt eine Distibution für die S100 welche softdevice verwendet - vielleicht kann ich mir da was abschauen.
    Habe mir bisher zwei angesehen (u.a zenslack). Beide verwenden xine, jedoch ist da das Bild imho sehr verschwommen/weichgezeichnet. Das Bild über softdevice (das ich kurz habe wenn ich auf pause drücke *g*) gefällt mir hingegen sehr gut.

  • [erledigt] Systemlast kurz nach vdr-Start auf Maximum/Hänger (dvb_usb_dtt200u)

    Rev 3 wird bereits seit einiger Zeit unterstützt.


    Aber: Das Problem existiert (leider)
    nicht mehr. Selbst wenn ich den vorherigen Kernel boote mit den alten
    Modulen etc unverändert wird der Stick korrekt nur noch 1x erkannt und
    bislang keine Timeoutmeldungen.


    Alles was ich seit vorgestern morgen als es zum letzten mal aufgetreten ist
    gemacht habe war kurz ein anderes Netzteil - mittlerweile wieder das
    alte - die Firmware von Rev2 und Rev1 geladen und natürlich den "neuen"
    Kernel kompiliert um die Option zu finden die das Problem verursacht,
    was nicht erfolgreich war, weil selbst mit der alten config der Kernel
    plötzlich mit dem Stick klarkommt. Sicherheitshalber alle Sticks
    durchprobiert etc, Problem ist _derzeit_ einfach weg. VDR lief jetzt also knapp zwei Tage ohne das von mir beschriebene Problem.


    Falls ich die Ursache des einstgen Fehlers finden sollte werde ich es hier posten.

  • Softdevice xv: Bild nach OSD-Aufruf weg/überdeckt

    Hallo,


    ich versuche derzeit auf meiner S100 unter Debian vdr aus den Quellen mit streamdevclient-plugin und softdevice-plugin nachzuinstallieren. Ich habe jetzt zwar sowohl OSD und Ton, aber max bis auf einen kleinen halben cm hohen Streifen kein Bild. Bild mit MMS und mplayer ist anstandslos (so die letzten Monate im Einsatz gehabt).


    Wenn ich im Menü von softdevice Wiedergabe auf "pausiert" stelle sehe ich das aktuelle Standbild des Fernsehprogramms, stelle ich wieder auf "aktiviert" ist das Bild wieder wie von einer grau-gelben (fast schwarz) Fläche verdeckt. Ich habe auch immer kurz ein Bild (keine Sekunde) wenn ich das Bildschirmformat im Softdevice plugin umstelle. Meist habe ich nach dem Umstellen des Bildformats unten einen kleinen Streifen sichtbar vom aktuellen Stream.


    Beispielvideo


    Jemand eine Idee?


    vdr 1.4.7, streamdev-client 20070921, softdevice-0.4 + snapshot sowie ffmpeg 20060823 & 20070307 & snapshot der letzten Tage, welche ja wie bekannt ist noch nicht kompatibel sind mit softdevice, X 7.1.1

  • [erledigt] Systemlast kurz nach vdr-Start auf Maximum/Hänger (dvb_usb_dtt200u)

    Der Vollständigkeit halber:


    Alle späteren Versuche scheiterten, wenn nicht schon eher, spätestens nach Beginn eines größeren Dateitransfers von der SATA-Festplatte mit o.g. Problem.


    Das Problem konnte ich nur mit Revision 3 des Sticks reproduzieren. Sowohl die steigende Load bei > 500interrupts/5s von usb (also die -110er/Timeout Fehler) als auch das der Stick doppelt erkannt wurde. Mit Revision 2 (lt. lsusb, kein entsprechener Vermerk auf dem Aufkleber des Sticks über die Revision) kein Problem. Leider habe ich 3x Rev 3 und nur einmal Rev2 ;)


    Das Problem tritt auch auf der alten Hardware auf mit SATA - wenn auch deutlich seltener. Vermutlich hatte ich die letzten vier Monate nur Glück weil als primäres device ein Rev2 Stick verwendet wurde und der Rev3 nur selten von vdr bei zwei gleichzeitigen Aufnahmen unterschiedlicher Transponder (kann leider nicht mehr mit Sicherheit nachvollziehen welche Revisionen ich im alten System verwendet habe).


    Aus purer Verzweiflung habe ich heute früh nochmal mit einer komplett leeren Kernel-Konfiguration begonnen und die läuft noch anstandslos, aber das hies ja bisher auch nichts. Sollte das Problem wirklich nicht mehr auftreten werde ich die funktionierende als auch die alte Config für die Nachwelt posten.

  • [erledigt] Systemlast kurz nach vdr-Start auf Maximum/Hänger (dvb_usb_dtt200u)

    Danke, dass Du an meinem Leid teilnimmst :D


    Zitat

    Altes System, nur neue Software oder auch Hardware?


    Hardware ist auch neu, lief vorher auf einem Alton XP 3000+ mit nforce Chipsatz und IDE-Festplatte.


    Zitat

    Es sieht irgendwie so aus, als ob die Probleme anfangen, nach dem der zweite Stick erkannt wird.


    Die erste -110er Fehlermeldung ist einmal direkt nach dem Einstecken/Erkennung lt. anderer Berichte vollkommen normal, hatte ich auch auf dem alten System.


    Mir ist mittlerweile auch aufgefallen, wenn ich den Rechner mit der hohen load/den 110er Fehlern neu boote aber den Stick nicht entferne steigt die load direkt nach dem Reboot wieder an, egal ob vdr oder irgendwas anderes an DVB verwendet wird. Erst wenn ich den Stick entferne und neu einstecke beruhigt sich das ganze wieder.


    Meine Theorie derzeit: Es hat was mit USB und dem Mainboardchipsatz zu tun. Wenn ich den Rechner mit noapic (+routeirq bringt spürbar keine Verbesserung) starte kann ich VDR reproduzierbar länger ohne steigende Load/110er Fehler nutzen als ohne. Im BIOS habe ich schon rumgespielt, ohne Erfolg. EAPIC lässt sich dort nicht ausschalten, wenngleich es als Option vorhanden ist, aber ausgegraut.
    Ich hätte meinem Prinzip treu bleiben sollen und kein MSI-Board mehr kaufen sollen ;)


    Als nächstes werde ich vermutl. die SATA-Festplatte auf eine IDE-Platte kopieren und auf der alten Hardware mir mal die Ergebnisse ansehen.


    Was mich nach wie vor verwundert: Ich habe schon testweise eine Stunde mit tzap einen Kanal aufgenommen und hatte keine Probleme :/

  • [erledigt] Systemlast kurz nach vdr-Start auf Maximum/Hänger (dvb_usb_dtt200u)

    Mittlerweile bekomme ich immer kurz vor/während der 110er Fehlermeldung von vdr "PES packet shortened"


    --
    ==> /var/log/vdr.log <==
    Feb 10 19:37:30 keller vdr: [1722] frontend 0 timed out while tuning to channel 1, tp 198
    Feb 10 19:37:31 keller vdr: [1730] 14 cRepacker messages suppressed
    Feb 10 19:37:31 keller vdr: [1730] cAudioRepacker(0xC0): skipped 320 bytes to sync on next audio frame
    Feb 10 19:37:32 keller vdr: [1722] frontend 0 regained lock on channel 1, tp 198
    Feb 10 19:37:33 keller vdr: [1730] PES packet shortened to 1606 bytes (expected: 2894 bytes)
    Feb 10 19:37:33 keller vdr: [1722] frontend 0 lost lock on channel 1, tp 198
    Feb 10 19:37:35 keller vdr: [1722] frontend 0 regained lock on channel 1, tp 198


    ==> /var/log/kernel <==
    Feb 10 19:37:35 keller last message repeated 444 times
    Feb 10 19:39:27 keller kernel: dvb-usb: recv bulk message failed: -110
    Feb 10 19:39:27 keller kernel: dvb-usb: bulk message failed: -110 (4/0)


    ==> /var/log/vdr.log <==
    Feb 10 19:39:29 keller vdr: [1722] frontend 0 lost lock on channel 1, tp 198


    ==> /var/log/kernel <==
    Feb 10 19:39:29 keller kernel: dvb-usb: bulk message failed: -110 (1/0)
    Feb 10 19:39:33 keller last message repeated 2 times
    Feb 10 19:39:33 keller kernel: dvb-usb: bulk message failed: -110 (4/0)
    Feb 10 19:39:35 keller kernel: dvb-usb: bulk message failed: -110 (1/0)
    Feb 10 19:39:39 keller last message repeated 2 times
    Feb 10 19:39:39 keller kernel: dvb-usb: bulk message failed: -110 (4/0)
    --


    oder auch schon mal:


    --
    Feb 10 20:16:22 keller vdr: [1461] cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed
    Feb 10 20:16:23 keller vdr: [1461] cAudioRepacker(0xC0): skipped 1262 bytes to sync on next audio frame
    Feb 10 20:16:23 keller vdr: [1461] PES packet shortened to 2392 bytes (expected: 2894 bytes)
    Feb 10 20:16:23 keller vdr: [1461] PES packet shortened to 1790 bytes (expected: 2894 bytes)
    Feb 10 20:16:23 keller vdr: [1461] PES packet shortened to 672 bytes
    etc
    --


    Wenn ich sobald die load steigt, also die o.g. 110er Fehlermeldung kommt, vdr beende und dann femon eingebe (tzap hängt an dieser Stelle wenn ich es damit versuche):


    --
    FE: WideView USB DVB-T (DVBT)
    status | signal 4646 | snr b9b9 | ber 00489946 | unc 00009946 |
    status | signal 4646 | snr b9b9 | ber 00489946 | unc 00009946 |
    status | signal 4646 | snr b9b9 | ber 00489946 | unc 00009946 |
    status | signal 4646 | snr b9b9 | ber 00489946 | unc 00009946 |
    --


    Nachdem ich den Stick entfernt habe (dauert ca 30s bis das Entfernen des Sticks vom System verarbeitet wurde):


    --
    status 1f | signal 3939 | snr a7a7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal 3939 | snr a7a7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal 3939 | snr a7a7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal 3838 | snr a7a7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal 3939 | snr 9f9f | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal 3939 | snr a7a7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    status 1f | signal 3939 | snr a7a7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
    --

  • [erledigt] Systemlast kurz nach vdr-Start auf Maximum/Hänger (dvb_usb_dtt200u)

    Die Bildstörungen mit vdr bin ich mittlerweile los, die hohe load kurz nachdem vdr gestartet wurde bleibt leider.


    30-70x / sekunde
    --
    dvb-usb: recv bulk message failed: -110
    --


    Aktuelle v4l habe ich mittlerweile auch zum laufen bekommen, leider keine positiven Änderungen, habe jetzt folgende kernel durch:


    2.6.24, 2.6.24.1, 2.6.19, 2.6.23.14 sowohl mit im kernel enthaltenen als mit den aktuellen v4l treibern inkl. 87 Bootvorgängen lt meinem Dateisystem :>


    Mir ist außerdem aufgefallen, das nach dem laden des Treiber dvb_usb_dtt200u idR zwei adapter "registriert" werden - es ist aber nur ein Stick eingesteckt:


    --
    dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state.
    dvb-usb: will use the device's hardware PID filter (table count: 15).
    DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom))
    DVB: registering frontend 0 (WideView USB DVB-T)...
    input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:10.4/usb5/5-4/input/input3
    dvb-usb: schedule remote query interval to 300 msecs.
    dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected.
    dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state.
    dvb-usb: will use the device's hardware PID filter (table count: 15).
    DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom))
    DVB: registering frontend 1 (WideView USB DVB-T)...
    input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:10.4/usb5/5-4/input/input4
    dvb-usb: schedule remote query interval to 300 msecs.
    dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected.
    dvb-usb: recv bulk message failed: -110
    --


    und beim entladen:
    --
    usbcore: deregistering interface driver dvb_usb_dtt200u
    dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully deinitialized and disconnected.
    dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully deinitialized and disconnected.
    --


    Ich kann zwar über beide mit tzap tunen, aber vielleicht ist es das was vdr zu schaffen macht. Kann ich vdr anweisen nur ein bestimmtes dvb device zu verwenden?


    Edit:


    Habe es jetzt mal rabiat mit rm -rf /dev/dvb/adapter1/ gemacht (heute auf udev umgestiegen).


    Jemand eine Idee woran das liegen könnte, dass er aus meinem einzelnen Stick zwei Stück macht (nicht immer ...) nachdem die Firmware geladen wurde?


    Für knapp 30 Minuten lief es so tatsächlich tadellos. Load war max 0.02 und nur die "-75" Fehlermeldungen. Nach knapp einer halben Stunde jedoch das alte Bild mit der "-100" Fehlermeldung und steigender Load:


    ----
    <vdr start>
    Feb 10 06:57:53 keller kernel: dvb-usb: recv bulk message failed: -75
    Feb 10 06:58:38 keller kernel: dvb-usb: recv bulk message failed: -75
    Feb 10 07:02:56 keller last message repeated 406 times
    Feb 10 07:06:33 keller last message repeated 140 times
    Feb 10 07:06:43 keller last message repeated 705 times
    Feb 10 07:27:43 keller kernel: dvb-usb: recv bulk message failed: -110
    <ab hier wieder steigende load, tastatur hänger etc>
    Feb 10 07:28:15 keller last message repeated 24 times
    Feb 10 07:29:17 keller last message repeated 46 times
    Feb 10 07:30:19 keller last message repeated 47 times
    Feb 10 07:31:21 keller last message repeated 46 times
    .
    .
    .
    Feb 10 14:30:51 keller last message repeated 47 times
    Feb 10 14:31:53 keller last message repeated 46 times
    Feb 10 14:32:55 keller last message repeated 46 times
    ----


    > Freu mich schon wenn ich den Rechner morgen wieder hochfahre und
    > das wie vorher ist :>


    Ich hatte recht ;)

  • [erledigt] Systemlast kurz nach vdr-Start auf Maximum/Hänger (dvb_usb_dtt200u)

    Hallo,


    ich bin nach einer erfolgreichen viermonatigen Testphase von vdr derzeit dabei ein neues System aufzusetzen, dass in Zukunft als VDR-Server in unserem Haus fungieren soll.


    Mein Problem derzeit: Nachdem ich vdr (1.4.7) starte steigt reproduzierbar kurze Zeit später die Load des Systems kontinuierlich auf 2 (CPU-Last nahezu 0%) - die Tastatur reagiert nur noch mit ~5s Verspätung etc, dementsprechend sehen auch die Testaufnahmen mit VDR aus (entweder sehr viele Klötzchen, einfach eine leere Datei, manchmal auch für einige Minuten super Bild über streamdev!). Auch nach neun Stunden sinkt die Load nicht. Sobald ich VDR beende UND das Kernel-Modul für meinen USB-DVB-T Receiver entlade sinkt die Load wieder. VDR beenden reicht nicht.


    AMD Athlon64 X2 BE-2350, 1GB RAM, MSI K9MM-V K8M800,
    Freecom USB DVB-T Stick (rev3 derzeit), Distribution: LFS
    Als Kernel verwende ich derzeit 2.6.24 und die in diesem enthalten DVB-Treiber, da ich sowohl mit 2.6.23 als auch 2.6.19 und 2.6.24 mit den aktuellen v4l hg jedesmal beim Laden des Kernelmoduls dvb-usb-dtt200u meines DVB-T-Sticks OOOPs begrüßen durfte (das Kernelmodul dtt200u ist jedoch soweit ich das mit diff sehe mit dem in v4l-dvb und 2.6.24 identisch)


    Den Stick habe ich in doppelter Ausführung bereits auf dem alten System erfolreich laufen gehabt. Kernel war dort 2.6.18-4 von Debian.


    Nach dem Start des Systems und einstecken des USB-Sticks werden die notwendigen Module geladen (siehe auch dmesg.txt).


    --
    dvb-usb: schedule remote query interval to 300 msecs.
    dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected.
    dvb-usb: recv bulk message failed: -110
    --


    Mit tzap switche ich jetzt auf einen Sender und zeichne diesen mittels "cat /dev/dvb/adapter0/dvr0" auf - einwandfreies Bild, load maximal bei 0.2. Kernel-Log spricht derweil:


    --
    dvb-usb: recv we made it: 0 (<- von mir hinzugefügte dbg msg in dvb-usb-urb.c)
    last message repeated 201 times
    last message repeated 793 times
    .. etc
    --


    Also alles ok.


    Ich beende tzap und starte vdr, Kernel-Log:


    --
    dvb-usb: recv bulk message failed: -110 (<- kurz nach vdr start:)
    last message repeated 32 times
    last message repeated 62 times
    usw, sprich knapp mehr als 1x pro Sekunde diese Fehlermeldung
    --


    VDR meldet derweil gelgentlich das was ich auch idR sehe: video data stream broken (siehe auch Anhang).


    Beende ich jetzt vdr, bleibt die Load oben. Entferne ich das modul dvb_usb und dvb_usb_dtt200u sinkt die Load. Steigt jedoch sofort wieder an wenn ich das Modul wieder lade, unabhängig davon ob ich vdr starte oder nicht.


    Periodische Debug-Meldung in diesem Zustand vom Modul, mit der ich nichts anfangen kann:


    --
    key: ff ff af f8 12
    dvb-usb: recv bulk message failed: -110
    dvb-usb: recv bulk message failed: -110
    --


    Jemand eine Idee warum nur durch vdr dieser Fehler und die damit verbundene hohe load/Hänger des Systems zustande kommt? Bin aktuell etwas verzweifelt.


    Wollte es mal mit dem Debian Kernel meines alten vdr versuchen, jedoch unterstützt dieser SATA meines Mainboards noch nicht. Stecke ich den Stick in das alte System funktioniert VDR wieder anstandlos (mal von der sterbenden Festplatte abgesehen)


    Jeder noch so kleine Hinweis .. ist hilfreich :/


    Edit2:
    Das Streamen geht in den ersten 1-2 Minuten nach dem Start von VDR und sieht so aus:


    [Blockierte Grafik: http://img11.myimg.de/0902200834633189_thumb.jpg][Blockierte Grafik: http://img11.myimg.de/09022008347e0888_thumb.jpg][Blockierte Grafik: http://img11.myimg.de/09022008348bdcaf_thumb.jpg]
    Beispielaufnahme


    Wie gesagt, wenn ich hingegen einen Sender mit tzap einstelle und dann mittels "cat /dev/dvb/adapter0/dvr0 > test.mpg" aufzeichne ist Bild+Ton 1A.


    --
    Feb 9 22:22:13 keller vdr: [2566] switching to channel 1
    Feb 9 22:22:13 keller vdr: [2566] setting watchdog timer to 30 seconds
    Feb 9 22:22:13 keller vdr: [2566] ERROR: no OSD provider available - using dummy OSD!
    Feb 9 22:22:23 keller vdr: [2566] max. latency time 1 seconds
    Feb 9 22:22:41 keller vdr: [2575] Streamdev: Accepted new client (HTTP) 192.168.1.5:4813
    Feb 9 22:22:41 keller vdr: [2617] streamdev-writer thread started (pid=2566, tid=2617)
    Feb 9 22:22:41 keller vdr: [2618] streamdev-livestreaming thread started (pid=2566, tid=2618)
    Feb 9 22:22:41 keller vdr: [2619] receiver on device 2 thread started (pid=2566, tid=2619)
    Feb 9 22:22:41 keller vdr: [2620] TS buffer on device 2 thread started (pid=2566, tid=2620)
    Feb 9 22:22:41 keller vdr: [2570] frontend 0 lost lock on channel 1, tp 198
    Feb 9 22:22:42 keller vdr: [2570] frontend 0 regained lock on channel 1, tp 198
    Feb 9 22:23:25 keller vdr: [2573] frontend 1 lost lock on channel 1, tp 198
    ===> Ab hier dann gar keine Ausgabe mehr über streamdev (standbild im vlc)
    Feb 9 22:23:26 keller vdr: [2573] frontend 1 regained lock on channel 1, tp 198
    Feb 9 22:24:07 keller vdr: [2573] frontend 1 lost lock on channel 1, tp 198
    Feb 9 22:24:07 keller vdr: [2573] frontend 1 regained lock on channel 1, tp 198
    Feb 9 22:24:29 keller vdr: [2573] frontend 1 lost lock on channel 1, tp 198
    Feb 9 22:24:31 keller vdr: [2573] frontend 1 timed out while tuning to channel 1, tp 198
    --


    Spätestens wenn gar kein Bild mehr kommt steigt die Load nach und nach an und die Tastatur reagiert kaum noch (s.o.).


    channels.conf von vdr

    Zitat

    PHOENIX;ARD:198500:C23D23M16B7T8G4Y0:T:27500:301:302=ger:304:0:3:8468:0:0


    channels.conf für tzap

    Zitat

    PHOENIX:198500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:301:302:3


    Edit3: w_scan (hatte vorher scan verwendet) hat mir eine etwas andere channels.conf generiert, trotzdem leider keine Änderung. Abgesehen davon, dass es gelegentlich für 2-3 Minuten mit klarem Bild geht.


    Zitat

    PHOENIX;ARD:198500:I999B7C23D23M16T8G4Y0:T:27500:301:302=ger:304:0:3:8468:17920:0

  • Wandernde Schlieren/Schatten/Streifen im Bild

    Vielen Dank für die Tips! Zwar hat es nicht geholfen den VDR mittels Verlängerungskabel am selben Anschluss mit Strom zu versorgen oder alle Antennenanschlüsse zu entfernen (VDR hat derzeit nur DVB-T), aber nachdem ich das Antennenkabel vom Fernseher abgezogen habe sind die Schlieren und das Brummen weg. Da muss dann wohl ein neues Kabel mit so einem Mantelstromfilter her, danke!

  • Wandernde Schlieren/Schatten/Streifen im Bild

    Hallo,


    ich verwende eine gebrauchte Dxr3-Karte zum Anschluss meines VDRs an den Fernsehe mittels S-Video. Das Bild ist bis auf grau bzw schwarze und weiße Schlieren ok (berauschend ist es nicht). Sie wandern von unten langsam nach oben und erscheinen dann wieder unten (etwa zwei gleich große und ein größerer Dritter in der Mitte zwischen den anderen beiden, zusammen nehmen sie etwa 50% des Bildes ein). Besonders zu erkennen sind sie natürlich bei sehr hellen oder sehr dunklen Passagen während eines Films, ebenso bei "ruhigen" Stellen und in Comics.


    Die Schlieren sind sowohl über Wiedergabe mittels VDR als auch mittels mplayer direkt sichtbar.


    Ich habe viel mit den Optionen der Module experimentiert, die Schlieren wollten jedoch nicht verschwinden.


    Die Aufnahmen, z.B. über nfs an einem PC betrachtet enthaltenen keine Schlieren, ebenso Live-Streaming nicht.


    Optionen für die Karte:

    Zitat

    options adv717x pixelport_16bit=0 pixelport_other_pal=1 output_mode=svideo
    options em8300 dicom_fix=1 dicom_control=1 dicom_other_pal=1 audio_driver=oss


    Jetzt stelle ich mir die Frage, ob die Ursache vielleicht auch am S-Video Kabel liegen könnte. Es ist ca 10m lang, mein VDR steht einen Stock höher in einer kleinen ausgebauten Galerie unter dem Dach. Zu lange?


    Das ist vielleicht auch hilfreich: Sobald ich das Audio-Chinch-Kabel an den Fernseher anschließe brummt es - zwar leise aber hörbar. Dafür brauch ich einen entsprechenden Filter lt dem was ich im Netz gefunden habe. Hängen die beiden Probleme miteinander zusammen?


    Jemand ein paar Tips für mich? Kenne mich leider mit den Eigenarten der Anschlüsse nicht aus.

  • analogtv + mp1e = Streifen/Flackern im Bild

    Um die 40% lt vmstat - Load schwank seltsamerweise sehr zw knapp 1 und knapp 2


    Ausgabe von mp1e bei der Arbeit:

    Zitat

    48,5 MB V:0:00:54.567 V:0:00:54.634 V-V:0:00:00.066 D:14,03% CPU:100,0%



    So langsam glaube ich wird das nichts mit dem zweiten Leben für diese Karte ;)


    Edit: Load bleibt mittlerweile unter 0.5

  • TV-Out mittels softdevice: kein Signal/rauschen

    Sieht nicht so aus (s.u).


    Denkst Du denn der Tv-Out ist aus? Ich dachte zuerst, dass vielleicht das übertragene Signal nicht "korrekt" ist, weil ich auf einem Fernseher durch ein rauschen hindurch schwach das OSD des vdr erkennen kann.


  • TV-Out mittels softdevice: kein Signal/rauschen

    Hallo,


    mein Testsystem mit Budgetkarten unter Debian für VDR steht soweit - von ein paar kleineren Krankheiten abgesehen. Nun wollte ich das System an einen Fernseher anschließen über den TV-Out meiner Radeon 9500 und komme hier nicht weiter.


    Zum Testen hatte ich das ganze an einem Monitor über VGA-Kabel angeschlossen.
    Dazu lade ich das FB-Modul für meine Grafikkarte ("modprobe radeonfb") (sobald das Modul geladen wurde ist das Signal auf dem TVOut der Grafikkarte weg). Dann starte ich vdr mit -P "softdevice -vo dfb:" und erhalte eine vernünftiges Bild auf dem Monitor über den VGA-Anschluss. TVOut bleibt schwarz (kein Signal). An einem anderen Fernseher habe ich auf dem TVOut dann sowas wie analoges Rauschen. Man sieht teilweise etwas gelbes, wie das gelb vom OSD von vdr. Das "Rauschen" verändert sich, wenn ich mit fbset "herumspiele", jedoch war ich trotz intensiver suche im Netz nicht in der Lage durch ein entsprechendes fbset das Signal am Tv-Out herbeizuzaubern.


    Flags von softdevice habe ich mehrere blind durchprobiert: "-vo fb:", "-vo dfb:viat", "-vo vidix:", "-vo dfb:triple" - jedoch brachte keines ein Signal auf dem TVOut und nur "-vo dfb:" ein vernünftiges Bild über VGA.


    "atitvout" half mir nicht weiter (keine Veränderung).


    imho relevante Versionen:
    vdr 1.4.4
    softdevice 0.4.0
    directfb 0.9-25 (debian)
    kernel 2.6.18-4


    AMd AthlonXP 3000+, 1GB RAM


    Zitat

    02:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 NE [Radeon 9500 Pro]
    02:00.1 Display controller: ATI Technologies Inc Radeon R300 [Radeon 9500 Pro] (Secondary)


    Ausgabe von vdr/softdevice


    Vielleicht ist das auch noch relevant: Oft, nicht immer, bekomme ich so kein Fernsehbild, nur das OSD. Starte ich eine Aufnahme und schalte dann auf einen Sender geht es direkt ("video now synced"-Meldung).


    Jemand eine Idee?

  • analogtv + mp1e = Streifen/Flackern im Bild

    Hallo,


    ich beschäftige mich seit einigen Tagen intensiver mit dem Aufbau eines VDR-Servers unter Debian.


    Mit den digitalen Karten hat es soweit sehr gut funktioniert - dank dem Wiki und den zahlreichen Threads hier! Nun versuche ich seit zwei Tagen meine alte analoge WinTV PC Karte (kein PVR) in vdr einzubinden.


    Zitat

    Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
    Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)


    Nachdem ich mir die vergangene Nacht vergebens um die Ohren geschlagen habe das ganze mit ffmpeg zu realisieren (vdr Dateien blieben leer/0Byte, ffmpeg wurde beim Aufnahmeende nicht beendet etc) habe ich jetzt mit mp1e Erfolg gehabt (1.9.5cvs).


    analogtv-Plugin ist Version 1.0 - bis auf den Aufruf von mp1e unverändert (enthielt inkompatible flags, gleichwohl ich auch die mp1e-Snapshots des AnalogTV-Plugin-Entwicklers getestet hatte).


    Das letzte klitzekleine Problem, das ich aber nicht gelöst bekomme: Mit mp1e habe ich gelegentlich Bildfehler. Manchmal innerhalb von 10 Sekunden mehrmals, mal ist auch eine halbe Minute gar nichts auszumachen - Beispiel:


    [Blockierte Grafik: http://img6.myimg.de/mp1e3d1b3.gif]


    kurzes Beispielvideo


    Mein mp1e-Aufruf zum Testen außerhalb von vdr sieht derzeit so aus:


    Zitat

    mp1e -m 3 -s 720x576 -b 6000000 -c /dev/video0 -a 0 -p /dev/dsp1 -S 44100 -C k7 -v -o /videarchiv/mp1test.avi


    Die Bildfehler habe ich nicht wenn ich ffmpeg manuell verwende und direkt in eine Datei schreiben lasse. Nur leider funktioniert bei mir ffmpeg zusammen mit dem analogtv-Plugin nicht :> Aber wenigstens sagt mir das, dass meine Karte schonmal nicht der Verursacher der Fehler ist.


    Jemand eine Idee woher diese Bildefehler mit mp1e rühren könnten? Bin für jeden noch so kleinen Tip dankbar.