STR / SNR bei einer Cine S2 V6 und yaVDR, welche Werte sind üblich/ausreichend

Hier habe ich STR 69 SNR 79 (mit kleinen Abweichungen je nach Transponder) und keine Bildstörungen.

lspci -v sagt:

3:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter
        Subsystem: Digital Devices GmbH Cine S2 V6 DVB adapter
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f7200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: DDBridge
        Kernel modules: ddbridge

Ich verwende einen LNB mit eingebautem Multiswitch (ist das nun Quattro oder Quad??)

Wolfgang

Meine Erfahrung ist dass beide Werte nicht sehr relevant sind. Meine sind deutlich schlechter. Relevant ist UNC.

ich habe mit meiner Cine S6.5 die Werte ca. STR=71% SNR=76% und was wichtig ist BER=0.
Persönlich finde ich besseres SNR als vorteil, da das Signal was reinkommt eindeutig ist,, Allerdings was du schauen solltes obs bei den Freezen zu einem BER Wert kommt. (Bit Error Rate) Das würde bedeuten, dass sich in dein Signal was mitreinmischt, was dort nichts zu suchen hat.. Wo ich früher Baum in der Sicht hate, wenn es geregnet hat, haben die nassen Blätter auch andere SAT-Positionen mitrefektiert..

Aktuell habe ich aber auch ab und zu Aussetzer, die ich nicht eindeutig zuordnen kann, es treten aber meistens auf, wenn der 2ter oder ein weiterer Tuner mit einschalltet um EPG zu scannnen, Dann passiert eine Unterbrechung oder Pixelfehler.. Aktuell nutze ich TVHeadend der es als "Continuity Error" bezeichnet. Also es kann etwas mit der Schirmung/Erdung der Leitung nicht stimmen (beim Umschallten der anderen LNBS (H/V/Lo/Hi). Es kann aber auch auf dem TVHeadend liegen oder weil ich KVM nutze und auf die Karte über IOMMU zugreife... Habs noch nicht so ganz tief analysiert.

Also am bestens alles andere an der Leitung abstecken, das EPG Aktualisierung abschallten und dann beobachte obs immer noch auftritt..

Vielleicht hilft das bei deiner Fehlersuche...

Miro

BER zeigt zwar Fehler im Datenstrom an, aber die sind noch kein Indiz für Pixelfehler, sondern erst unkorrigierbare Daten (UNC) führen zu Pixelfehlern.

Andy

noppi59
Ich habe gestern nach meinem Problem gesucht, und bei mir stimmt scheibar etwas mit der DuoFlex karte nicht. Ich habe den 3ten und 4ten tuner deaktiviert und seitdem kein einziger Problem auch beim EPG scann.. Wäre auch ein ansatz für Dich..

Zuvor konnte ich sehen, das meistens bei mir ein Problem auftrat, der UNC und Continuity Errors (nur tvheadend) wenn der 3ter oder 4ter tuner beim Tunen einer Frequenz waren (aber auch nicht immer). Sobs nun etwas an der Leitung ist, was nicht ok ist oder vielleicht stimmt etwas nicht mit der zusatz-stromversorgung der karte nicht.. (ich habe nur der DuoFlex die extra stromversorgung gegönt, da es hies, für die Cine selbst ist es nicht zwingend erforderlich)

Und wie sieht es mit aufnahmen? Werden die Störungsfrei auch auf einem Pc wiedergeben? Denn ich würde bei Dir auf ein Problem bei der Kommunikation zu RapsberryPi sehen, das Netzwerk bei dem hat schon einige Macken, weil USB...

Zitat von noppi59

Das ist bei BER und UNC völlig anders. BER nimmt scheinbar zufällig die Werte 0 oder 1 ein, wenn das TV-Bild wieder läuft. Neben UNC steht nie etwas.

Sollte das wirklich bei einer Cine S2 V6 + DuoFlex S2 und aktuellem yaVDR normal sein?

Ja - falls man einen veralteten Treiber verwendet!
Mit media_build_experimental erhält man Werte für BER und UNC.

Zitat von UFO

Mit media_build_experimental erhält man Werte für BER und UNC.

Kann es neben diesem Bug auch sein, dass der alte Treiber STR und SNR verwechselt? Gestern hatten wir Gewitter, und als sich die fette Cumulonimbus zwischen Schüssel und Satellit schob, sank SNR stark ab während STR weitgehend konstant blieb. Ich hätte das Umgekehrte erwartet. Das Bild blieb fehlerfrei.

Gibt es neben dem UNC/BER-Bug weitere Gründe, auf media_build_experimental umzusteigen?

Wolfgang

Zitat von UFO

Ja - falls man einen veralteten Treiber verwendet!
Mit media_build_experimental erhält man Werte für BER und UNC.

Trifft das auch für die CineCT zu? Mit dddvb-dmks bekomme ich unter femon nämlich nur das:

xbmc@Aton:~$ dkms status
bbswitch, 0.7, 3.13.0-23-generic, x86_64: installed
dddvb, 0.9.13.2yavdr0, 3.13.0-23-generic, x86_64: installed
nvidia-331, 331.38, 3.13.0-23-generic, x86_64: installed


xbmc@Aton:~$ femon -a0 -H
FE: STV0367 DVB-C DVB-T (DVBC)
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status       | signal   0% | snr   0% | ber 0 | unc 0 |


xbmc@Aton:~$ femon -a1 -H
FE: STV0367 DVB-C DVB-T (DVBC)
status SCVYL | signal   0% | snr   0% | ber 0 | unc 11 | FE_HAS_LOCK
status SCVYL | signal   0% | snr   0% | ber 0 | unc 11 | FE_HAS_LOCK
status SCVYL | signal   0% | snr   0% | ber 0 | unc 11 | FE_HAS_LOCK
status SCVYL | signal   0% | snr   0% | ber 0 | unc 11 | FE_HAS_LOCK
status SCVYL | signal   0% | snr   0% | ber 0 | unc 11 | FE_HAS_LOCK


lspci -vv


03:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter
        Subsystem: Digital Devices GmbH Cine CT V6.1 DVB adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at f7200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [70] MSI: Enable- Count=1/2 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [90] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range A, TimeoutDis+, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>
        Kernel driver in use: ddbridge

Zitat von wofritz

Kann es neben diesem Bug auch sein, dass der alte Treiber STR und SNR verwechselt? Gestern hatten wir Gewitter, und als sich die fette Cumulonimbus zwischen Schüssel und Satellit schob, sank SNR stark ab während STR weitgehend konstant blieb. Ich hätte das Umgekehrte erwartet. Das Bild blieb fehlerfrei.

Nach einem Blick in den Treiber würde ich sagen, daß die Werte nicht vertauscht sind. Ob die Werte immer Sinn machen, kann ich nicht beurteilen. Dazu fehlen mir die Meßmittel...

Zitat

Gibt es neben dem UNC/BER-Bug weitere Gründe, auf media_build_experimental umzusteigen?

Was den Frontend-Treiber (stv090x) angeht, nein.
Der Kartentreiber (ddbridge) wurde stark verändert.

Ob sich der Umstieg lohnt, muß jeder selbst entscheiden. Wer keine Probleme hat, kann natürlich den alten Treiber verwenden.

CU
Oliver

Zitat von BJ1

Trifft das auch für die CineCT zu? Mit dddvb-dmks bekomme ich unter femon nämlich nur das:

Code

xbmc@Aton:~$ dkms status
bbswitch, 0.7, 3.13.0-23-generic, x86_64: installed
dddvb, 0.9.13.2yavdr0, 3.13.0-23-generic, x86_64: installed
nvidia-331, 331.38, 3.13.0-23-generic, x86_64: installed


xbmc@Aton:~$ femon -a0 -H
FE: STV0367 DVB-C DVB-T (DVBC)
status       | signal   0% | snr   0% | ber 0 | unc 0 |


xbmc@Aton:~$ femon -a1 -H
FE: STV0367 DVB-C DVB-T (DVBC)
status SCVYL | signal   0% | snr   0% | ber 0 | unc 11 | FE_HAS_LOCK

Alles anzeigen

Laß das -H weg, dann bekommst Du vermutlich Werte.

Meine Aussage bezieht sich auf DVB-S2 (stv090x).

Der stv0367-Treiber in media_build_experimental stammt aus dddvb, allerdings Version 0.9.14.

CU
Oliver

Zitat von UFO

Laß das -H weg, dann bekommst Du vermutlich Werte.

Ja, und sie "zappeln" auch. Nur kann ich (und auch andere Programme) mit den Werten nichts anfangen. Vermutlich sind die Werte so klein, dass sie sich (im Vergleich zu anderen Karten) wahrscheinlich im Promillebereich bewegen und daher zu keiner "human readable" Anzeige führen. Sie nachträglich ausserhalb des Treibers mit einem Multiplikator zu versehen, wäre der falsche Ansatz, sowas gehört in den Treiber... Wäre der Ansatz von DVB-S2 auf DVB-CT übertragbar?

BJ1