31.08.2019, 00:38 (Dieser Beitrag wurde zuletzt bearbeitet: 01.09.2019, 23:31 von klappnase.)
Hallo,
auf meinem relativ frisch installierten 3.5 habe ich hier das seltsame Phänomen, dass nach jedem Neustart der VDR zwar läuft, allerdings weder Bild noch Ton am TV ankommen. Femon und Devstatus behaupten jeweils Empfang.
Das OSD Menu funktioniert aber und wenn ich den VDR neu starte scheint er auch zuverlässig zu funktionieren.
Zuerst hatte ich das hier beschriebene Nvidia/Kernel Problem im Verdacht, allerdings haben weder das Upgrade auf 4.4.0-142 / Nvidia-384 noch das Upgrade auf 4.8.12 / Nvidia-390 (nach Anleitung u. mit Paketen von mango) etwas geändert.
An einer anderen Stelle (link habe ich gerade nicht parat) wurde für ein ähnlich klingendes Problem nahegelegt, dass skinflatplus Prbleme verursachen könnte, aber weder das deaktivieren noch das deinstallieren von skinflatplus bringt eine Änderung.
Ich bin hier jetzt doch etwas ratlos, vielleicht hat jemand noch eine Idee?
31.08.2019, 12:08 (Dieser Beitrag wurde zuletzt bearbeitet: 31.08.2019, 15:54 von Oberlooser.)
Hi Michael
ERROR im syslog: ERROR:can't open DVB device 0/0 und 1/0
Du kannst mal versuchen den Systemstart zu verlangsamen in
/etc/vdr/easyvdr/easyvdr-systemstart.conf
hier die Werte etwas höher setzen.
#Pause in Sekunden zwischen DVB Treiber laden und VDR starten
#Wenn der VDR ohne Livebild startet, hier die Zeit erhöhen
#default=0.1 ->0.1 Sekunde
WAIT_FOR_DVB_DEVICE=0.4
sieht so aus als hätte eine DVB Karte keinen Empfang ( TT Budget S2 3200 mit DVB-STB0899 Chipsatz)) Siehe hier:
#####################################################
##### femon -H -c5 -a0
#####################################################
Problem retrieving frontend information: Operation not supported
FE: STB0899 Multistandard (DVBS)
status C YL | signal 0% | snr 0% | ber 0 | unc 1 | FE_HAS_LOCK
Problem retrieving frontend information: Operation not supported
status C YL | signal 0% | snr 0% | ber 0 | unc 1 | FE_HAS_LOCK
Problem retrieving frontend information: Operation not supported
status C YL | signal 0% | snr 0% | ber 0 | unc 1 | FE_HAS_LOCK
Problem retrieving frontend information: Operation not supported
status C YL | signal 0% | snr 0% | ber 0 | unc 1 | FE_HAS_LOCK
Problem retrieving frontend information: Operation not supported
status C YL | signal 0% | snr 0% | ber 0 | unc 1 | FE_HAS_LOCK
FE: Conexant CX24116/CX24118 (DVBS)
status SCVYL | signal 84% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 84% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 84% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 84% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 84% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK
Test mit Plugin femon ( Signalinformation im VDR-OSD )
Genauer in System & Einstellungen / Signalinformationen hier dann mit der Ok Taste zu Transponterinformationen wechseln
und hier mit den Cursortasten nach rechts oder Links zwischen Deinen 2 Satkarten hin + her wechseln.
Um zu sehen welche Satkarte keinen Empfang hat. DVB-S #0 oder #1
Wenn das nichts bring mal versuchen die Obere LNB Frequenz ( MHz) etwas höher zusetzen oder runter zu setzen
um 3 Mhz ( 10597 bzw 10603 ).Beides nach einem reboot testen.
im VDR OSD unter System & Einstellungen / Einstellungen / VDR-Einstellungen / LNB.. / Obere LNB-Frequenz
Die TT 3200 leiden manchmal unter einem Frequenzdrift.. Kann aber auch am LNB liegen ..
Noch ein Versuch wäre die TT3200 Versuchsweise mal ganz auszubauen und dann zu testen..
Dann gibt es noch ein Error im syslog. Ist jetzt aber nicht maßgeblich..
In /media/easyvdr01/convert fehlt der Ordner traco.
Den evtl. händisch hinzufügen.
Und wenn Du WLAN nicht nutzen tust , diesen Dienst im Bio,s ganz abschalten
Evtl auch die interne Soundkarte deaktivieren wenn Du sie nicht brauchst und den Ton nur über die Nvidia Grafikkarte per HDMI zum TV
ausgeben willst.
Floppy wenn möglich auch im Bio,s deaktivieren..
Sonst fällt mir im Moment auch nichts mehr ein.. Versuch macht kluch....
Gruß Helmut
EA5 Test-VDR : Lintec3 Senior Gehäuse - MSI G41M-P25 Board - Intel P4 E6850 / 775 Dual Core CPU - 2x2GB DDR3 RAM - MSI GT 710 PCI-e HDMI Grafik - DVB Technisat Skystar S2 SAT PCI + Tevii S2 471 PCI-e x1 - 120GB SSD + 1 TB Test-HDD - Asus DRW-24D5MT DL DVD - USB-STM32 V2 Stick (36kHz) mit SMK RC6 MCE 50GB Fernbedienung - EasyVDR 5.0 Alpha ISO 010 - Softhddevice mit Pulseaudio + estuary4vdr OSD - Kodi 18.7 mit Confluence Skin VDR-Client,s : Media MVP Scart, VIP BOX 1903, 1910 , EasyStream 0.6-18 für WIN 10, Raspberry PI 3 mit OpenElec 7.01 und TotalControl FB Code 0104 Lirc an Tsop 31238
Zitat:ERROR im syslog: ERROR:can't open DVB device 0/0 und 1/0
kommt normalerweise nicht, hatte ich deshalb auch übersehen. Das war wohl nach dem Neustart, nachdem ich skinflatplus deinstalliert hatte, da ging seltsamerwiese der VDR gar nicht mehr. Nach einem weiteren Neustart lief der VDR aber wieder wie gehabt.
Das ändern der oberen LNB Frequenz hatte hier keinen Effekt, zumindest soweit ich bei einem kurzen Test feststellen konnte.
In der /etc/vdr/easyvdr/easyvdr-systemstart.conf WAIT_FOR_DVB_DEVICE höher zu setzen hatte ebenfalls keinen Effekt, selbst wenn es auf mehrere Sekunden gesetzt wird.
Allerdings scheint VDR_RESTART="yes" das Problem zu lösen, zumindest als Workaround fürs Erste.
Zur Meldung von Femon:
Zitat:Problem retrieving frontend information: Operation not supported
FE: STB0899 Multistandard (DVBS)
status C YL | signal 0% | snr 0% | ber 0 | unc 1 | FE_HAS_LOCK
Bei der TT Karte zeigt Femon hier immer 0% Signal und SNR an, die farbigen Balken zeigen aber Empfang, und Bild u. Ton sind auch da. Ich hatte da eigentlich ein Treiberproblem mit dieser Karte vermutet, das "Operation not supported" scheint ja auch in die Richtung zu deuten (oder sollte Femon mit dieser Karte eigtl. normal arbeiten?).
Werde da wohl noch mal weiter forschen müssen, inwieweit ich hier ein Problem mit der Hardware habe oder ein generelles Problem mit dem Empfang. Aber zumindest das akute Problem schein für's erste gelöst.
Hallo,
erstmal noch ein schönes neues Jahr euch allen!
Ich weiss, der Thread ist schon alt, aber für's Archiv, falls mal jemand mit einem ähnlichen Problem hier vorbeikommt, wollte ich doch mal meine neu gesammelten Erkenntnisse zu diesem Problem hier festhalten.
Erstmal stelle ich beim nochmaligen Durchlesen fest, dass ich die Symptome oben nicht ganz korrekt beschrieben habe, einiges war mir zuerst wohl entgangen.
Also, es ist so, dass nach dem normalen Systemstart zunächst die Nova für das Live-TV benutzt wird, Bild und Ton sind aber nicht da. Femon zeigt aber normale Empfangswerte (STR/SNR u. farbige Balken sind normal) u. die Transponderinfo sieht normal aus. Die Streaminfo ist allerdings leer.
Wenn ich mit femon das Live-TV auf die TT Karte umschalte, funktioniert diese offenbar normal, Bild u. Ton sind vorhanden, ebenso wie eine normale Streaminfo in femon. Mit einer zweiten, baugleichen Nova-S2 verhält es sich genauso, ein Hardwaredefekt an der Nova scheint also eher unwahrscheinlich.
Der Workaround mit VDR_RESTART="yes" funktioniert zwar meistens, aber leider doch nicht zuverlässig; ab und zu sind nach dem Booten beide DVB-Karten "stillgelegt", d.h. überhaupt kein Empfang; falls irgendein Timer aktiv ist, wird deshalb auch ein Timerkonflikt angezeigt. In solchen Situationen hat hier auch ein Neustart des VDR keinen Effekt, nur ein Reboot hat geholfen.
Ein oder zweimal ist es auch passiert, dass die Nova während des Betriebs beim Umschalten wieder das Signal verloren hat, Symptome also wie oben beschrieben; in diesen Fällen hat dann ein VDR-Neustart geholfen.
Überraschenderweise hat sich jetzt gezeigt, dass diese ganze Problematik nur mit neueren Kernelversionen auftritt. Ich konnte das soweit eingrenzen, dass mit allen Kernelversionen <= 3.18 das Initialisieren der DVB-Karten problemlos funktioniert, mit allen Versionen >= 3.19 treten die beschriebenen Probleme auf. Der Unterschied ist offenbar, dass bis 3.18 das ältere "videobuf" Treibersystem verwendet wird, ab 3.19 das neue "videobuf2" System. Wie es aussieht, gibt es aus unbekannten Gründen bei meiner Hardwarekombination hier ein obskures Problem.
Das ist reproduzierbar bei allen Easyvdr-Versionen von der 2.5 bis zur 4-unstable so.
Ich hatte schon daran gedacht, einen Bugreport zu schreiben, aber mangels Fehlermeldungen bringt das vermutlich nicht viel. Das einzige halbwegs handfeste, das ich bisher finden konnte, ist die Ausgabe von "lsmod" nach einem "erfolglosen" Systemstart mit z.B. Kernel 4.4 (Auszug):
Code:
Module Size Used by
cx88_dvb 36864 13
nvidia 13160448 178 nvidia_modeset
und nach dem (erfolgreichen) VDR Neustart (Bild u. Ton sind da):
Code:
Module Size Used by
cx88_dvb 36864 14
nvidia 13160448 208 nvidia_modeset
(ansonsten ist die Ausgabe von lsmod identisch).
Die niedrigeren "used-by" Werte scheinen ja irgendwie anzudeuten, dass direkt nach Systemstart irgend etwas nicht vollständig initialisiert ist.
Wie auch immer, im Moment ist hier offenbar die beste Lösung, einen aktuellen 3.16 Kernel zu verwenden, mit diesem läuft das System hier jetzt wie es aussieht zuverlässig, ohne dass irgendwelche weiteren Frickeleien nötig sind :-)
09.01.2020, 13:28 (Dieser Beitrag wurde zuletzt bearbeitet: 09.01.2020, 13:45 von gb.)
Hallo Michael, interessant wäre hier noch, ob ein Entladen und neu laden der cx88_dvb den gleichen Effekt haben könnte, wie ein Neustart des System.
Entladen, wenn keine weiteren Abhängigkeiten bestehen:
Hi,
Teste ruhig mal mit Plugin dynamite. Das sorgt bei TT 3200 auch für Ruhe. Von denen kenne ich das.
Ich denke der Treiber ist zu langsam gestartet und deshalb geht es nicht.
Bei Reboot ist der etwas schneller fürchte ich.
Mfg Stefan
Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, Mygica t230 Stick als Tuner, nvidia Slim-GT218 512MB PCIe x1 - v3.5-64
VDR2 in Rente
VDR3 in Rente VDR4: MSI G31M2 v2, Intel E5200, 6" t6963c gLCD, 2GB, WD Red 4TB, 2x TT3200, ASUS GT730-SL-2GD3-BRK, mod. Digitainergeh. - v3.5-64 VDR5: GIGABYTE GA-G31M-S2L, Intel E5200, GT630 passiv, 2GB, 3TB, 6" t6963c gLCD, mod. Digitainergeh. - v3.5-64 VDR6: MSI MS-7236, Intel E2140, GT630 passiv, 2GB, WD Green 2TB, 6" t6963c gLCD, 2x TT3200 - v2.5-64 Hilfe gefällig? Dann brauchen wir ein easyInfo aus easyPortal!
Zitat:interessant wäre hier noch, ob ein Entladen und neu laden der cx88_dvb den gleichen Effekt haben könnte, wie ein Neustart des System.
naja, der Systemneustart ist ja nur in seltenen Fällen nötig. Ich bin nicht ganz sicher, aber vermute, dass beim VDR-Neustart auch die DVB-Treiber entladen und wieder neu geladen werden, und dass es eigentlich auch das ist, was in den meisten Fällen dann dafür sorgt, dass die DVB-Karten nach dem VDR-Neustart dann arbeiten. Falls das zutrifft, dann hilft das Treiber ent- u. neuladen in diesen seltenen Fällen, in denen beide Karten ohne Funktion sind, ja eben nicht.
Und nachdem mit dem 3er Kernel die Karten jetzt "einfach so" laufen, lockt es natürlich wenig, wieder auf den 4er Kernel umzusteigen um so eine Situation abzuwarten. Richtig lästig wird das ja vor allem dann, wenn eine Aufnahme nach Timer-Wakeup fehlschlägt, weil gerade in dem Moment die Karten streiken...
Interessant wäre denke ich aber auf jeden Fall in Hinsicht auf einen Bugreport, welche Befehle genau die nach dem Booten zuerst nicht funktionierende Nova dann "aufwachen" lassen. Evtl. wäre auch interessant, ob zusätzliche Debug Optionen beim Kernelbau vielleicht dazu führen, dass ich doch ein paar sinnvolle Meldungen ins Syslog bekomme, z.B. CONFIG_VIDEO_ADV_DEBUG sieht hier evtl. vielversprechend aus.
Zitat:Teste ruhig mal mit Plugin dynamite
Ich bin mir nicht sicher, ob das in meinem speziellen Fall etwas bringt. Wenn bei einem Timer-Wakeup bei Abwesenheit die Karten nicht funktionieren, ist ja eben niemand da, um das mittels dynamite zu reparieren. Und wenn der VDR-Neustart schon ausreicht, dann braucht es das dynamite ja gar nicht.
Aber für mich jetzt eigentlich egal, der 3.16.80 Kernel läuft hier jetzt seit ca. einer Woche zuverlässig, vorher schon ca. 4-5 Wochen der 3.13 Kernel ebenso, deshalb denke ich dass für mich das Problem an dieser Stelle erstmal gelöst ist.
Wenn ich weiter mit den neueren Kernelversionen herumbastele, werde ich erstmal lieber versuchen Informationen für einen erfolgversprechenden Bugreport zu sammeln als mit weiteren Workarounds zu experimentieren. Ob das letztlich zu etwas führt, steht natürlich auch in den Sternen, aber einen Versuch ist es denke ich mal wert.
Vielen Dank für die Unterstützung, und beste Grüsse
