VDR geht im Laufe der Jahre immer schlechter und jetzt gar nicht mehr

    Hallo,


    eigentlich bin ich ja eher ein "Oldie" statt ein "Newbie", weil ich VDR schon vor drei Jahren installiert habe - und damals ging auch alles ganz perfekt. Naja, meistens; gelegentlich war mal eine Aufzeichnung abgestürzt, aber sowas kommt ja in den besten Familien vor ;) (sogar mein separater Stand-Alone-DVD-Recorder stürzt gelegentlich ab).


    Irgendwie hat sich dann aber im Laufe des letzten Jahres eine "schleichende" Verschlechterung ergeben: Inzwischen sind eigentlich *alle* Aufzeichnungen nur noch 0 Bytes lang (außer vielleicht mal, wenn man VDR während einer Timer-Programmierung neu gestartet hat), und Live-Streaming geht auch höchstens nur noch einmal nach dem Neustart - wenn überhaupt. Eigentlich eher gar nicht mehr.


    Daß ich diesen Beitrag trotzdem in "Newbie" gestellt habe, liegt daran, daß ich VDR-mäßig nur "Dummuser" bin, der das alles einfach einmal installiert hatte, ohne so recht zu wissen, warum es funktioniert, und der sich einfach nur gefreut hat, *daß* es funktioniert ;)


    Tja, nur leider funktionierts jetzt nicht mehr. Bevor ich mir jetzt einen Reel NetCeiver o.ä. kaufe, wollte ich doch erst nochmal ausloten, ob man das ganze nicht wieder zum Laufen kriegen kann - eigentlich ist VDR doch ein sehr schönes System, und der Linux-Server im Keller läuft eh 24/7, also warum soll der nicht auch nebenbei noch ein bißchen Videorecorder spielen... und es ging doch schon mal (mitdemFußaufstampf).


    Ein paar Daten zu meinem System (und den Symptomen):


    Ich verwende Gentoo Linux (wobei ich eigentlich nicht glaube, daß es sich um ein Gentoo-spezifisches Problem handelt). Im Lauf der Jahre hat sich der Kernel von 2.6.18 auf derzeit 3.7.10 weiterentwickelt; allerdings kann man nicht sagen, daß die Probleme bei einem ganz bestimmten Kernel-Update gekommen/gewachsen sind - es ging einfach "schleichend" immer schlechter.


    Ein OSD habe ich nicht (auf dem Server ist auch kein GUI oder X installiert); die Kiste soll einfach nur aufnehmen (und ab und zu mal live-streamen übers LAN).


    VDR hatte ich die ganze Zeit 1.6.0_p2-r7 aus dem "stable" Gentoo-Repository; ich habe nun allerdings inzwischen 1.7.39 aus dem "vdr-devel"-Overlay installiert, um zu prüfen, ob es vielleicht an der VDR-Version liegt, aber das hat auch keine Änderung gebracht. Dazu epgsearch (bisher 0.9.25_beta17, jetzt 1.0.0-r1), streamdev (bisher 0.5.2, jetzt 0.6.0), und dummydevice 1.0.3. Dazu vdradmin-am 3.6.8 als Web-Frontend.


    Hardware ist ein Hauppauge DVB-T-Nova-TD-USB-Stick. Output von dmesg:



    (Eine IR-Fernbedienung gibts da natürlich nicht, daher die ganzen diesbezüglichen Fehlermeldungen.) Die ganzen USB-Treiber habe ich im Kernel natürlich geladen (vermutlich auch ein paar zuviele/überflüssige - war mir nicht ganz sicher mit den ganzen "DIB" 700 oder 7000 etc.); außerdem kann ich mich erinnern, daß ich damals eine Datei namens "dvb-usb-dib0700-1.20.fw" in das Verzeichnis /lib/firmware gelegt habe. lsmod zeigt auch an, daß von den Modulen fleißig Gebrauch gemacht wird:



    Beim Starten sieht eigentlich auch alles ganz normal aus (/var/log/syslog):



    Wie man sieht, klappt's auch mit dem Empfang - die Programmanzeige im Web-Frontend (mit vdradmin-am) funktioniert ganz wunderbar.


    Was geht nun nicht? Die Aufnahme und das Live-Streaming. Kurz gesagt, hat man nach einer Aufnahme eine (früher .vdr-, jetzt .ts-)Datei mit 0 Bytes Länge auf der Platte, und beim Live-Streaming erscheint zwar der Sendername im Titel, aber das Videofenster (z.B. VLC, mit anderen gehts aber auch nicht) bleibt schwarz.


    Beispiel: Wenn ich im Web-Frontend auf der Seite "Was läuft jetzt?" den Aufnahmebutton klicke, passiert folgendes:



    wobei die letzten beiden Zeilen immer wieder mal kommen. Ich habe dazu im /etc/vdr/setup.conf EmergencyExit=0 gesetzt, sonst hätte sich der VDR dauernd neu gestartet. Ok, vielleicht ist mein Empfang nicht so beliebig gut, aber früher gabs dann in der Aufzeichnung halt gelegentlich mal eine Klötzchenzeile im Bild und/oder ein Knacksen im Ton, das hat nicht weiter gestört. Inzwischen hat man dann einfach eine Datei "00001.ts", die exakt 0 Bytes lang ist.


    Sooo schlecht, daß er gar nichts aufzeichnen kann, kann der Empfang doch aber auch wieder nicht sein, denn sonst würde doch der EPG nicht so perfekt funktionieren, oder?


    Und wenn man das ganze live anschauen will, passiert folgendes:


    Code
    Mar 10 11:09:26 fileserver vdr: [27670] Streamdev: Accepted new client (HTTP) 10.15.5.50:53645
Mar 10 11:09:26 fileserver vdr: [28426] streamdev-writer thread started (pid=27644, tid=28426, prio=high)
Mar 10 11:09:26 fileserver vdr: [28427] streamdev-livestreaming thread started (pid=27644, tid=28427, prio=high)
Mar 10 11:09:26 fileserver vdr: [28428] receiver on device 2 thread started (pid=27644, tid=28428, prio=high)
Mar 10 11:09:26 fileserver vdr: [28429] TS buffer on device 2 thread started (pid=27644, tid=28429, prio=high)


    und in der VLC-Titelzeile steht sogar "MDR Thüringen", aber es kommen einfach keine Daten. Wenn man VLC dann schließt, passiert das hier:


    Code
    Mar 10 11:10:41 fileserver vdr: [27670] client (HTTP) 10.15.5.50:53645 has closed connection
Mar 10 11:10:41 fileserver vdr: [27670] streamdev-server: closing HTTP connection to 10.15.5.50:53645
Mar 10 11:10:41 fileserver vdr: [28427] streamdev-livestreaming thread ended (pid=27644, tid=28427)
Mar 10 11:10:41 fileserver vdr: [28429] TS buffer on device 2 thread ended (pid=27644, tid=28429)
Mar 10 11:10:41 fileserver vdr: [28426] streamdev-writer thread ended (pid=27644, tid=28426)
Mar 10 11:10:41 fileserver vdr: [28428] buffer stats: 0 (0%) used
Mar 10 11:10:41 fileserver vdr: [28428] receiver on device 2 thread ended (pid=27644, tid=28428)
Mar 10 11:10:41 fileserver vdr: [27670] buffer stats: 0 (0%) used


    Also alles ganz normal, nur daß eben keine Videodaten geliefert werden.


    Wenn ich sicher wüßte, daß es lediglich am schlechten DVB-T-Empfang liegt, würde ich mir ja sogar eine Schüssel an die Hauswand schrauben und einen DVB-S2-Empfänger installieren (gibts die auch als USB? Empfehlungen werden gerne entgegengenommen!). Allerdings gings ja früher mit exakt derselben DVB-T-Empfangsanlage; und der EPG wird ja auch heute noch fehlerfrei empfangen - sooo grottig kann der Empfang also nun auch wieder nicht sein, so daß ich eher auf "Verklemmungen" anderswo tippe...


    Jedenfalls bin ich jetzt mit meinem (Laien-)Latein am Ende und hab keinerlei Plan mehr, was ich noch untersuchen/testen/ändern/korrigieren könnte... ;(


    Hab' ich noch eine Chance, das (wieder) zum Laufen zu bekommen?


    Herzlichen Dank im Voraus für jegliche Unterstützung!


    Gruß Matthias.

    Moin,


    Zitat

    ...es ging einfach "schleichend" immer schlechter.


    was sagt denn femon auf der Konsole? Eventuell hat sich ja nur die Antenne verstellt.

    Zitat von mhanft

    Bevor ich mir jetzt einen Reel NetCeiver o.ä. kaufe


    Kuckst du hier.


    Ansonsten sieht das für mich nach schlechtem Empfang aus. Was sagt den femon?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Zitat von Saman

    was sagt denn femon auf der Konsole? Eventuell hat sich ja nur die Antenne verstellt.


    femon? Oh, das kannte ich ja noch gar nicht. Hier bitte:


    Ist das gut oder schlecht? ;)


    (Ein einziges Mal kam zwischendurch "status CVY | signal ffff | snr 0098 | ber 001fffff | unc 00000000 |". Was bedeuten eigentlich die ganzen Felder?)


    Danke & Gruß Matthias.

    Zitat von mhanft

    [...]Ist das gut oder schlecht? ;)


    (Ein einziges Mal kam zwischendurch "status CVY | signal ffff | snr 0098 | ber 001fffff | unc 00000000 |". Was bedeuten eigentlich die ganzen Felder?)


    Danke & Gruß Matthias.


    Mach halt

    Code
    femon -H

    dann wird besser lesbar. ;)

    Zitat von mhanft

    Was bedeuten eigentlich die ganzen Felder


    http://www.vdr-wiki.de/wiki/index.php/Dvb-apps_femon


    Sieht eigendlich ganz gut aus. snr könnte besser sein aber das kann auch am Stick liegen.
    Prüf doch noch mal mit dem zweiten Tuner und dann mit -H wie 3PO vorgeschlagen hat.

    Zitat von Saman

    http://www.vdr-wiki.de/wiki/index.php/Dvb-apps_femon
    Sieht eigendlich ganz gut aus. snr könnte besser sein aber das kann auch am Stick liegen.
    Prüf doch noch mal mit dem zweiten Tuner und dann mit -H wie 3PO vorgeschlagen hat.


    Ah, danke für den Link. Also mit -H und beiden Tunern hintereinander siehts jetzt so aus:


    Ich denke, diese "ber!=0" und/oder "unc!=0"-Stellen waren dann früher immer die paar (wenigen) Klötzchen im Bild - die sind aber tolerabel.


    Was mich dagegen etwas wundert, ist "SNR=0%". Ohne "-H" habe ich da Werte so um 00d0-00df herum; auf dem Beispiel auf der femon-Seite stehen da Werte zwischen b000 und cfff und "sollte möglichst hoch sein". Empfange ich da etwa nur Rauschen? Und wie paßt das mit "signal 100%" und "HAS_LOCK" zusammen?!


    Gruß Matthias.

    ber und unc gleich null ist gut und das wichtigste.


    snr 0% ist schlecht, kann aber am Stick / Treiber liegen. Da wäre ein Wert eines baugleichen Sticks nützlich.


    Aus der Kombination dieser Werte werde ich jetzt auch nicht richtig schlau.


    Da ist snr auch 0 und er hat zumindest Empfang.
    http://www.vdr-portal.de/board…keine-werbung/#post996394


    Habe das Gefühl, das ist eine Sackgasse und der Fehler liegt wo anders.

    die Frage ist, ob die 0-Werte echte Werte sind, oder nur dafür steht, dass der Treiber keine Werte liefert (eher letzteres). Wenn es periodisch auf beiden Tunern zu Empfangsstörungen kommt, die eine 7-stellige BER auslösen (sowas hab ich noch nicht gesehen!) dann ist da was faul. Was für eine Antenne hast Du?
    Ich würde auch mal einen anderem Stick probieren.


    Wenn es regelmäßig zu UNC kommt, dann kann das nicht gut gehen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Zitat von Saman

    snr 0% ist schlecht, kann aber am Stick / Treiber liegen. Da wäre ein Wert eines baugleichen Sticks nützlich.
    Habe das Gefühl, das ist eine Sackgasse und der Fehler liegt wo anders.

    Ja, das Gefühl (Fehler woanders) hab ich auch. Die 0% sind ja abgerundet, OK, in dem femon-Beispiel im Wiki sind da Hex-Werte von b000-cfff drin, und ich hab nur um 00d0 herum, aber vielleicht skaliert der jeweilige USB-Stick das unterschiedlich...


    Zitat von Dr. Seltsam

    die Frage ist, ob die 0-Werte echte Werte sind, oder nur dafür steht, dass der Treiber keine Werte liefert (eher letzteres). Wenn es periodisch auf beiden Tunern zu Empfangsstörungen kommt, die eine 7-stellige BER auslösen (sowas hab ich noch nicht gesehen!) dann ist da was faul. Was für eine Antenne hast Du?
    Ich würde auch mal einen anderem Stick probieren.

    Einen anderen Stick hab ich jetzt leider grad nicht auf Lager... Antennen hab ich ungefähr fünf Stück durchprobiert (mit und ohne Verstärker), das ist jetzt eine simple Zimmerantenne, aber die hat von allen fünf das beste Ergebnis geliefert! (Hat außerdem eh Sichtverbindung zum Fernsehturm, wo das Zeug herkommt.)


    Daß gelegentlich mal BER/UNC-Fehler kommen, macht überhaupt nix, das äußert sich dann nur in einer kurzen Klötzchenzeile im Bild - den Effekt kenn' ich schon seit Jahren. (Mag vielleicht dem länglichen Antennenkabel vom 2. Obergeschoß bis in den Keller geschuldet sein.)


    Nein, das liegt irgendwo anders. Der EPG geht ja auch problemlos. Und: Wenn man z.B. einen Timer von 10.00-10.10 Uhr anlegt (und er dann diese 0-Byte-Datei schreibt) und den VDR dann um 10.05 Uhr mit "/etc/init.d/vdr restart" neu startet, funktionierts plötzlich: das Video wird geschrieben, und die Qualität ist nachher sehr gut. Manchmal geht nach dem Restart sogar das Live-Streaming. Aber irgendwann verklemmt er sich dann wieder, und dann ist wieder Feierabend - bis zum nächsten Restart.


    Vielleicht ist ja einfach der USB-Stick defekt geworden? Wenn der VDR sagt "video data stream broken", kommt halt vielleicht nix mehr? Woher kriegt er eigentlich den EPG? Ist das ein separater Datenstrom oder so? Der geht ja perfekt.


    Früher hab ich beim Restart auch das dib_0700-Modul ent- und wieder geladen, das hat IIRC auch geholfen (wird da die Firmware neu in den Stick geladen?). Aber seit den neueren Kerneln sind da ja haufenweise Module miteinander verkettet (siehe lsmod im ersten Beitrag), das krieg ich manuell nie wieder so hin, daß alles paßt...


    Jetzt grad hab ich mal wieder einen Restart gemacht, jetzt sagt er im syslog ordnungsgemäß Mar 10 22:12:16 fileserver vdr: [16056] channel 12 (SAT.1 Bayern) event Son 10.03.2013 21:15-22:15 'The Mentalist' status 4 und nimmt ihn auch auf... vermutlich bis zum ersten "broken stream" oder so...?! Vielleicht laß ich ihn wieder den Emergeny-Exit machen, dann schreibt ers halt in 100 einzelne Dateien, die krieg ich mit ProjectX dann schon auch zusammen ;)


    Aber früher war das nicht ;(


    Gruß Matthias.

    m.E. waren dvb-usb-Treiber schon immer ziemlich buggy. Kann sein, dass das im Laufe der Jahre verschlimmbessert wurde.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Bei USB uns Dauerbetrieb gibt es wohl gelegentlich so merkwürdige Probleme, hatte ich mit anderen Geräten auch schon.
    Hast du mal versucht den Computer eine Weile komplett auszuschalten (Stecker raus!)?


    Bei so Problemen könnte aber auch ein Blick in den Computer nicht schaden, Stichwort defekte Elkos Auf Mainboard und Netzteil.


    Zitat von mhanft

    Früher hab ich beim Restart auch das dib_0700-Modul ent- und wieder geladen, das hat IIRC auch geholfen (wird da die Firmware neu in den Stick geladen?). Aber seit den neueren Kerneln sind da ja haufenweise Module miteinander verkettet (siehe lsmod im ersten Beitrag), das krieg ich manuell nie wieder so hin, daß alles paßt...

    Wenn du einen wirksamen Reset des Sticks erreichen willst musst du das wieder so einrichten.


    Ist aber nicht so kompliziert, im Endeffekt muss das Modul "dvb_core" entladen werden.
    Das versucht man einfach und arbeitet dann die störendem Module ab. Macht zwar etwas Arbeit, aber so findet man die zu entladenden Module und die Reihenfolge recht schnell.

    Gruss
    SHF


    Naja, ansonsten funktioniert der Server ja prima (hard- und softwaremäßig) - der Bug muß schon irgendwo im Videodatentransport liegen...


    Ich hab mal nachgesehen, diese ganzen zusätzlichen Module gibts wohl erst seit Kernel 3.7.9, vorher war nur das "dvb_usb_dib0700" da, und da hab ich per Cronjob schon immer vorsichtshalber nachts um vier Uhr einen Reset wie folgt gemacht:

    Bash
    #!/bin/bash
/etc/init.d/vdr stop
sleep 5
/sbin/modprobe -r dvb_usb_dib0700
sleep 5
/sbin/modprobe dvb_usb_dib0700
sleep 5
/etc/init.d/vdr start

    Da wird auch der Stick neu initialisiert (entsprechende dmesg-Meldungen). Diesen Reset hab ich jetzt auch grad mal von Hand gemacht, und siehe da, das streamdev-Plugin hat mir danach auch tatsächlich zweimal einen Livestream zu meinem Schreibtisch-VLC geschickt, und dann war wieder schwarzes Fenster. (Nach so einem Reset geht auch die unmittelbar anschließende Aufnahme - aber eben nur die.) BTW, könnte man sich da evtl. irgendwo einklinken, daß mein Reset-Skript automatisch jedesmal unmittelbar vor einer Aufnahme (und ggf. auch bei einem "Emergency Exit" mit anschließendem Neustart) ausgeführt wird? Das könnte helfen ;)


    Als wenn sich nach einiger Zeit die Daten irgendwie "verklemmen" würden. Ich hatte sowas mal bei einer Netzwerkkarte, da mußte ich irgendein Flag für "große Pakete selbsttätig trennen/zusammenbauen" oder so ähnlich abschalten, sonst hat die auch nach einiger Zeit nix mehr übertragen. Gibts evtl. irgendwelche ähnlichen Einstellungen für USB-Schnittstellen? Vielleicht hat sich da ja auch am Kernel im Lauf der Zeit irgendwas geändert...


    Gruß Matthias.

    Zitat von Dr. Seltsam

    Wenn es periodisch auf beiden Tunern zu Empfangsstörungen kommt, die eine 7-stellige BER auslösen (sowas hab ich noch nicht gesehen!) dann ist da was faul.

    Diese Stoerungen gibts bei diesem Stick immer, wenn auf dem einen Tuner eine Aufnahme oder LiveTV laeuft und auf dem anderen Tuner (z.B. fuer EPG-Scan) umgeschaltet wird. Dagegen hilft ein Treiber-Patch (siehe hier).


    Ansonsten hat dieser Stick gelegentlich Probleme mit zu viel Hitzeentwicklung (2 Platinen uebereinander), es hilft dann, den Stick mit der langen schmalen Seite nach unten/oben auszurichten, so dass die Lueftungsloecher uebereinander (und nicht nebeneinander oder gar auf der Unterseite) sind.


    Als dritten Tipp haette ich, die mitgelieferten Stummelantennen zu benutzen (moeglichst auf einer Metallunterlage, z.B. Heizung/Fensterbrett anbringen), gerade wenn der Sender in Sichtweite ist. Der Stick hat Probleme mit zu starkem Signal und mit Masseschleifen zwischen Antenne und USB.


    Als Treibermodule fuer diesen Nova-TD-Stick (altes Design mit einer Antennenbuchse hinten und einer an der Seite) werden mt2266 (Tuner), dib7000p+dibx000_common (Demodulator) und dvb_usb_dib0700 (USB-Bridge) gebraucht (+DVB-Core-Module), der Rest (dib*) schadet aber nicht.


    Gruss,
    S:oren

    Zitat von mhanft

    Früher hab ich beim Restart auch das dib_0700-Modul ent- und wieder geladen, das hat IIRC auch geholfen (wird da die Firmware neu in den Stick geladen?).

    Die Firmware wird nur nach einem Power-Cycle neu geladen, nicht beim Reboot oder Neuladen der Module. Da gibts aber - so weit ich weiss - kein Problem, Firmware 1.20 ist auch ok.


    Gruss,
    S:oren

    Zitat von mhanft

    Naja, ansonsten funktioniert der Server ja prima (hard- und softwaremäßig) - der Bug muß schon irgendwo im Videodatentransport liegen...

    Das sagt nichts.
    Es kann zB. nur die 5V Standby betroffen sein an dem die USB-Sticks hängen.


    Zitat von mhanft

    BTW, könnte man sich da evtl. irgendwo einklinken, daß mein Reset-Skript automatisch jedesmal unmittelbar vor einer Aufnahme (und ggf. auch bei einem "Emergency Exit" mit anschließendem Neustart) ausgeführt wird?

    Der Emergency Exit ist genau dazu gedacht.
    Das Laden und Entladen macht dann die runvdr. Von den Skript gibt es aber diverse Versionen, je nach Distribution und Geschmack.


    Zitat von S:oren

    Die Firmware wird nur nach einem Power-Cycle neu geladen, nicht beim Reboot oder Neuladen der Module.

    Bei USB-Geräten hatte ich öfters schon so Geschichten.
    Genau deshalb sollte man den Rechner als erstes mal für eine Minute stromlos machen, um das auszuschliessen.

    Gruss
    SHF


    Zitat von S:oren

    Diese Stoerungen gibts bei diesem Stick immer, wenn auf dem einen Tuner eine Aufnahme oder LiveTV laeuft und auf dem anderen Tuner (z.B. fuer EPG-Scan) umgeschaltet wird. Dagegen hilft ein Treiber-Patch (siehe hier).

    Danke, hab die Stelle im Quälcode ;) gefunden. Passt nicht mehr ganz zu Kernel 3.7.10, ist aber einfach anzupassen. Mach ich mal in den nächsten Tagen in Ruhe, das hilft vermutlich schon mal weiter.

    Zitat von S:oren

    Ansonsten hat dieser Stick gelegentlich Probleme mit zu viel Hitzeentwicklung (2 Platinen uebereinander), es hilft dann, den Stick mit der langen schmalen Seite nach unten/oben auszurichten, so dass die Lueftungsloecher uebereinander (und nicht nebeneinander oder gar auf der Unterseite) sind.

    Ah, OK. Ich hab grad mal nachgeguckt: Aus technischen Gründen ;) hängt das Dings freischwebend zwischen Server und 19-Zoll-Schrank:
    [Blockierte Grafik: http://www.hanft.de/temp/nova.jpg]
    (und daran wird sich auch nichts ändern :D ), aber ich habs jetzt mal von den umliegenden Kabeln befreit und exakt senkrecht ausgerichtet. Wird aber eh nur gut handwarm. Könnte höchstens sein, daß von den umliegenden Leitungen was einstrahlt, die meisten sind aber selbst abgeschirmt (meist Cat5 oder so).

    Zitat von S:oren

    Als dritten Tipp haette ich, die mitgelieferten Stummelantennen zu benutzen (moeglichst auf einer Metallunterlage, z.B. Heizung/Fensterbrett anbringen), gerade wenn der Sender in Sichtweite ist. Der Stick hat Probleme mit zu starkem Signal und mit Masseschleifen zwischen Antenne und USB.

    Hmmm... da waren Stummelantennen dabei? Kann mich gar nicht erinnern Muß mal sehen, ob ich den Karton von damals noch habe. Allerdings: Das Dings und der Server stehen im Keller, die Zimmerantenne am Dachboden. Da sind also drei Stockwerke dazwischen, mit einer entsprechend langen Antennenleitung. Dämpft die nicht eh schon heftig genug?!


    Gruß Matthias.

    Zitat von mhanft

    Allerdings: Das Dings und der Server stehen im Keller, die Zimmerantenne am Dachboden. Da sind also drei Stockwerke dazwischen, mit einer entsprechend langen Antennenleitung. Dämpft die nicht eh schon heftig genug?!

    Wahrscheinlich schon. Allerdings faengt die Leitung vermutlich auch ziemlich viel Dreck ein. Habe auch eine Antenne auf dem Dachboden, seit ich eine Antennenbuchse gut leitend ins Rechnergehaeuse eingebaut und den Stick ins Gehaeuse gelegt habe, gibts keine Probleme mehr. Vorher auch immer mal seltsame Effekte...


    Gruss,
    S:oren

    Also ich hab jetzt mal den Kernel-Patch angepasst (in der Anlage für Kernel 3.7.10, falls ihn noch jemand braucht), hat aber keine Verbesserung gebracht. Eigentlich glaub' ich auch generell gar nicht, daß es an der Empfangsqualität liegt, denn die ist ja ganz ausgezeichnet (wenn denn mal Videodaten kommen). Nach dem Reboot mit dem neuen Kernel ging auch erst mal wieder kein Streaming, nach einem VDR-Restart dann wieder genau einmal... also alles "wie immer". femon zeigt schon (ganz, ganz selten) immer noch kurze Ausraster (status SCVY | signal c7e1 | snr 00d9 | ber 001fffff | unc 00000000 | oder so ähnlich), aber gelegentliche Klötzchenzeilen in der Aufnahme bin ich gewohnt, und die stören auch nicht - außer die wären die Ursache, daß danach gar nix mehr geht. Sind sie aber offenbar nicht, denn wenn ich mal ein Live-Streaming am Laufen habe, funktioniert das auch unendlich lange, auch wenn gelegentlich die Klötzchen drin sind - deswegen komplett abstürzen tut also nix.


    Gefühlsmäßig siehts einfach für mich so aus, als wenn der Server bei Beginn einer neuen Aufzeichnung oder eines neuen Livestreams zum Stick sagen würde "hallo, schick mir mal ARTE", und der sagt zuerst "ja, mach ich", schaltet ggf. noch um, und schickt dann aber keine Daten...


    Gruß Matthias.

    Moin!


    Ist es möglich, dass du mal einen Stick von einem anderen Hersteller (d.h. anderer Treiber) zum Ausprobieren kaufst? Kannst ihn ja zurückschicken, wenn er auch nicht funktioniert.


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden