Posts by momit

Zur Info:

ich habe heute den neuen Multischalter Dur-Line MS5/6 Blue Eco erhalten. Vor dem Tausch habe ich den alten Humax 5/6 mit integriertem Netzteil als Ursache ausgeschlossen: Weil im ganzen Haus der Transponder bei 11582MHz kein Signal liefert habe ich vom Quattro-LNB das Low-Band/Horizontal Signal direkt an einen der Receiver angeschlossen. ARD HD, ZDF HD gehen so und bringen ein Bild mit gutem Signal. Bei Phoenix HD kommt immer noch kein Bild/Signal.

Ich muss im Frühling wieder aufs Dach und nachschauen... Es liegt ein reines Hardwareproblem vor.

Bei http://www.satindex.de finde ich folgende freie HD-Sender auf einer niedrigeren und höheren Frequenz als 11582 MHz:

11523MHz, WDR HD, SNR>27%, Bild ungestört

11538MHz, TRT World HD, SNR >30%, Bild bei FullHD ungestört

11553MHz, alle Sender, SNR 19-20%, Bild erscheint, aber stark gestört

11582MHz, kein Sender bringt ein Bild, SNR <4%

11626MHz, CNN SD, SNR >27%, Bild erscheint ungestört

11670MHz, 4mediathek, SNR >27%, scheint ungestört zu sein

11778MHz, cubavision, SNR>27%, ungestört bei FullHD

Höhere und niedrigere Frequenzen alle ungestört. Ich habe also ein "Bandsperreproblem" zwischen Quattro LNB und den Kabeln bis zum Multischalter welche an 11553-11582MHz merkbar wird. Die Kabel vom LNB runter sind noch alt. Werde das alles erst später genauer untersuchen.

Stromtest des Multischalters wenn es jemand interessiert:

Der Humax 5/6 mit integriertem Netzteil, benötigt mit und ohne eingeschalteten Receiver im Haus (drei Stück) ca. 10-20Watt Dauerlast.

Dann wären das: 24h * 365 Tage * 0,01W = ~87kWh im Jahr

Bei 40Cent/kWh wären das ~35€/Jahr, bei 60Cent/kWh ~52€/Jahr.

Der Austausch mit dem Dur-Line ohne Netzteil könnte sich relativ schnell amortisieren.

Werde nun nichts mehr zu dem Thema beitragen, ist also im falschen Thema, sorry.

kurzer Zwischenstand:

Test mit MLD 3.0.1 auf PC mit S2-6400: alle Sender gehen, ausser BR HD, NDR HD, Phoenix HD. Ich kann mich noch erinnern dass dies mal vor vielen Jahren funktionierte mit dem Live Stick von MLD 3.0. Ich vermute nun auch was FireFly meint: ich habe ein Hardwareproblem.

Zur Kontrolle auf http://www.satindex.de/ nachgeschaut: die Sender liegen alle auf Transponder 25 bei 11582MHz. Kein dieser Sender geht bei mir. Laut dieser Seite hat sich seit der Einführung 2012 auf diesem Transponder nichts verändert. Andere Sender mit niedriger und höherer Frequenz gehen aber.

Zur Bestätigung habe ich gerade noch den PC mitsamt der S2-6400 unverändert beim Nachbar angeschlossen und dort funktionieren die Sender !

Bei mir im Haus habe ich in einem anderen Stockwerk dann bei einer neuen Mieterin deren Technisat Receiver probiert: er zeigt keine Sender an 11582MHz an !

Hier sind die Kabel sehr kurz und ohne Knick direkt bis zum MultiSwitch-Verteiler der für alle Stockwerke arbeitet.

Den Quad LNB hatte ich ja schon mal getauscht ohne Besserung. Ich vermute nun stark: der Multiswitch könnte defekt sein. Werde mal einen neuen von Dur-Line MS5/6 Blue Eco testen. Die sollen ohne Netzteil auskommen und Strom sparen.

Vermutlich müsste nun der Beitrag in ein neues Thema verschoben werden da es offensichtlich kein Softwareproblem gibt, wie geht das ?

Danke für den Hinweis auf die Frequenz. Ich habe meine aktuelle Channels.conf ausgelesen und durchsucht:

BRFernsehenSüdHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5201=27:5202=deu@3,5203=mis@3,5207=qks@3;5206=deu@106:5204;5205=deu:0:10325:1:1025:0

NDRFSNDSHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3,5227=qks@3;5226=deu@106:5224;5225=deu:0:10327:1:1025:0

phoenixHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5261=27:5262=deu@3,5263=mul@3:5264:0:10331:1:1025:0

Weitere Kanäle auf 11582 MHz:

BRFernsehenNordHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5201=27:5202=deu@3,5203=mis@3,5207=qks@3;5206=deu@106:5204;5205=deu:0:10326:1:1025:0

NDRFSMVHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3,5227=qks@3;5226=deu@106:5224;5235=deu:0:10328:1:1025:0

NDRFSHHHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3,5227=qks@3;5226=deu@106:5224;5245=deu:0:10329:1:1025:0

NDRFSSHHD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3,5227=qks@3;5226=deu@106:5224;5255=deu:0:10330:1:1025:0

Merkwürdigerweise ist das Bild heute viel besser. Nur wenige Artefakte. SNR ist heute bei <24% wo sonst nur <4% sind.

Das Wetter eher bewölkt was aber die letzten Tage auch so war und nur SNR <4% war und kein Bild möglich.

Unterschied heute: ich habe zwei Aufnahmen auf Tele5 laufen und damit war ein Tuner belegt.

Auf 11582MHz konnte ich in femon nicht die Tuner 0+1 wechseln wie sonst. Ohne Aufnahme konnte ich in femon beide Tuner wechseln und beide hatten das Problem auf 11582 MHz.

Es sind nur diese 7 Sender auf 11582 MHz betroffen auf beiden Tunern der S2-6400.

Ein normaler Receiver hat an denselben Kabeln welche sonst an der S2-6400 verwendet werden keine Probleme diese Sender störungsfrei anzuzeigen. Aber das könnte ja auch ein besserer Tuner sein der das Signal besser auswertet.

Guter Tipp mit der Kabelverlegung. Werde das mal so austesten:

ich stelle den PC mit der S2-6400 ins DG und schliesse an den MultiSwitch direkt an (ich glaube das habe ich schon mal gemacht kann mich aber nicht mehr genau erinnern).

Bin jetzt nicht sicher ob der Beitrag hier bei dem Treiber Kompilieren der S2-6400 nun richtig ist. Bisher konnte ich es nicht auf die Hardware eingrenzen. Dachte es wäre eher eine SW-Sache. Ich meine mich noch zu erinnern: ich hatte mal MLD von Stick gebootet und da war das Bild OK. Werde das auch wiederholen und berichten ob es nun Hardware oder eher Software sein müsste.

Nächster Schritt meinerseits:

1. PC mit S2-6400 direkt an Multiswitch mit neuen, kurzen Kabeln, sorgfältig und ohne Knick anschliessen...

2. MLD auf PC mit S2-6400 starten, dieselben Kabelanschlüsse, Standort im Haus...

Werde berichten...

Hallo, ich habe heute mir mal Zeit genommen das Problem mit meiner S2-6400 zu untersuchen. Eventuell kann mir S:oren hier auch helfen, denn er hatte vor einiger Zeit einen Patch im Treiber gemacht und erst danach konnte ich unter EasyVDR 5 die Karte zuverlässig erkennen. Er kennt sich wohl gut damit aus.

Mein aktuelles Problem habe ich schon längere Zeit, weiß nicht mehr genau seit wann. Es sind aber nur diese drei Sender betroffen:

BR3 Fernsehen HD

NDR Fernsehen HD

Phoenix HD

Alle anderen Sender, auch HD von anderen aus der ARD Gruppe, sind OK.

Bei STR habe ich stets bei allen Kanälen >80% und SNR >25%. Es treten damit keinerlei Störungen auf.Doch bei den drei genannten Problemsendern zeigt SNR <4%,

Damit kommen sehr wenige Bildinformationen mal durch und zeigen ein paar Artefakte an, Ton bringt höchstens kurzzeitig ein "zwitschern"Heute habe ich von http://www.aregel.de verschiedene Firmware geladen, es ändert sich nichts.

Die Schüssel hatte ich vor einiger Zeit schon überprüft, das war es nicht. LNB getauscht weil die alte defekt war. Doch die drei HD Sender gingen damit auch nicht.

Ich hab keine Idee mehr was ich testen oder tun könnte. Da nur diese drei Sender betroffen sind würde ich meinen: die Hardware/Karte ist nicht defekt.

Aktuell verwende ich:

Kernel: 5.4.0-60-generic

Den dvb Treiber habe ich mit dem Patch von S:oren kompiliert, selbstverständlich habe ich den passenden Source etc. dafür verwendet. Seitdem funktioniert die Karte einwandfrei. Das Problem mit den drei Sendern habe ich schon länger, ich meine auch schon unter EasyVDR3.5 bin aber nicht mehr ganz sicher.

Sendersuchlauf brachte auch nichts.

Hat jemand eine Idee warum SNR so niedrig sein könnte und auch nur bei drei HD-Sender aus der ARD-Gruppe?

Hallo Wolfgang,

darum ging es mir ja zuerst, wie man ein Entwicklersystem mit sourcen zu easyvdr einrichtet (falls ich das mal brauche)

Hab inzwischen schon das plugin installiert und aktiviert. Leider geht es auf anhieb mit meinem TV erst mal noch nicht.

Ich hab mal in die syslog geschaut, da findet man ein paar Einträge dass das plugin startet usw. Aber auch einen Eintrag dass kein Adapter gefunden wurde.

Ich vermute damit ist ein CEC fähiges Gerät z.B. TV am HDMI gemeint.

An meinem TV ist CEC aber aktiviert und ich meine unter easyVDR 3.5 ging da mit dem selben TV auch mal, ist aber schon länger her.

Ich wollte es wieder nutzen weil aktuell meine Fernbedienung der TT-S2 6400 kaputt ist. Werde mir bald ein Attric USB-Modul einbauen. Dann nutze ich das.

Aber am Wochenende schaue ich mal genauer nach dem vdr-plugin-cecremote was der Fehler bedeuten soll.

Auf jeden Fall ist es nun 1.5.0 also das neueste.

Danke.

Hallo wolfi.m,

vielen Dank.

Dann scheint meine source.list irgendwie die falsche zu sein, hab da aber nie rumgefummelt. Sie müsste so installiert worden sein von der iso (ich hatte stable bei der Installation gewählt) bzw. dem folgenden setup oder upgrade.

sources.zip sieht bei mir so aus:

...

## vdr stable

deb http://ppa.launchpad.net/easyvdr-team/5-vdr-stable/ubuntu focal main

## base-stable

deb http://ppa.launchpad.net/easyvdr-team/5-base-stable/ubuntu focal main

## others-stable

deb http://ppa.launchpad.net/easyvdr-team/5-others-stable/ubuntu focal main

...

Wenn ich mich richtig erinnere waren an der Stelle wo man das Stichwort easyvdr findet bei mir nie auskommentierte src-Einträge zu finden.

Müssten da auch src-Einträge für stable zu finden sein?

Das neue vdr-plugin-cecremote werde ich testen und melden.

Natürlich nehem ich den Eintrag für vdr unstable auf wie von Dir beschrieben. Danke

Hallo,

ich wollte das vdr-plugin-cecremote über das Setup von easyvdr installieren, aber zum Abschluss erscheint sinngemäß der Hinweis "wurde nicht installiert".

Also hab ich an der Konsole das mal versucht:

apt install vdr-plugin-cecremote

Da kommt die Ausgabe:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:

vdr-plugin-cecremote : Hängt ab von: libxerces-c3.1 ist aber nicht installierbar

E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Ich muss noch dazu erwähnen dass ich mal ein apt upgrade machte weil ich die kernelsourcen brauchte um den Treiber der TT-S2 6400 zu kompilieren. Bei Ubuntu ist es nun so dass man immer die neuesten kernelsourcen bekommt und nicht die welche zum installierten kernel gehören. Dieser ist jedoch bei easyVDR auf hold. Warum weiß ich nicht. Vor einem Jahr half mir mango, surfacecleanerZ und ein user namens wirbel wie man die Treiber korrekt kompiliert. "wirbel" meinte man muss immer die sourcen verwenden welche zum installierten kernel gehören. Bei easyVDR war das nach der neuinstallation 5.4.0-26-generic soweit ich noch weiß. Also musste ich den aktuellen kernel installieren und die passenden sourcen. Dabei habe ich ein apt upgrade gemacht und somit auch alle anderen neuen Ubuntupakte installiert. Danach habe ich den kernel auf hold gesetzt und zusätzlich die sourcen damit diese erhalten bleiben.

Nun gut ich hab nun mal ein upgrade gemacht, ich hoffe dass das nicht die Ursache ist warum das vdr-plugin-cecremote sich nicht installieren lässt.

Ich hab mal nachgeschaut: libxerces scheint wohl bei Ubuntu 20.04 im Paket libxerces-c3.2 zu sein. Also hab ich das installiert:

apt install libxerces-c3.2

Trotzdem verlangt das vdr-plugin-cecremote noch die *-c3.1.

Also habe ich im vdr-wiki nach dem Plugin gesucht.

Aktuell wäre 1.5.0 bei easyVDR5 wird 1.4.1 verwendet.

Hab mal versucht die sourcen in easyvdr zu holen:

apt source vdr-plugin-cecremote

aber das scheitert, die sourcen wurden nicht gefunden.

Dann habe ich die sourcen von der Homepage des plugins geholt, also 1.5.0

Zum kompilieren muss man m.w. die sourcen von vdr holen, das hab ich so versucht:

apt source vdr -> damit bekomme ich die sourcen von vdr 2.4.1

Aber easyVDR5 verwendet 2.2.0

Frage 1:

ich bin zwar kein Entwickler und habe kaum Kenntnisse, aber vor 20J konnte ich eigentlich unter LinVDR problemlos plugins kompilieren. Ich habe aber fast alles vergessen wie das ging.

Vielleicht kann mir jemand mal helfen wie ich unter easyVDR5 so eine Art Entwicklersystem mit den sourcen richtig einrichte.

In der source.list fehlt da irgendwas, kann das sein?

Frage 2:

Bei diesen Link habe ich was gefunden:

https://bitbucket.org/Ranseyer…remote-1.4.1~git20170212/

https://gitlab.com/easyvdr/five/-/tree/master/v

Es sieht für mich so aus dass das plugin bereits für easyVDR5 kompiliert wurde. Hmm, dann müsste es ja an meinem installierten System liegen.

Hat das plugin jemand schon am laufen unter easyVDR5?

Hallo, ich will nur mitteilen dass meine TT-S2 6400 seit dem Treiberpatch von s:oren einwandfrei funktioniert und erkannt wird.

Wie markiert man so ein Thema als gelöst, muss man dazu im Titel einfach von Hand schreiben [gelöst] oder sowas?

Hallo Sören, Hallo SurfaceCleanerZ,

der neue Treiberpatch funktioniert!

Folgendes habe ich zuerst erprobt:

zuerst nur den neuesten Kernel vom Ubuntu repository geholt:

uname -r

5.4.0-60-generic

Die Pakete und Sourcen dazu vom repository:

linux-generic : Version: 5.4.0.60.63

linux-image-generic : Version: 5.4.0.60.63

linux-headers-generic: Version: 5.4.0.60.63

linux-source : Version: 5.4.0.60.63

Reboot mit neuem Kernel.

Ich habe keinen neuen Treiber Patch verwendet sondern den alten Stand wie bisher und die Module neu kompiliert (mit meinem Skript).

lspci -vvv -nn:

03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

Subsystem: Philips Semiconductors SAA7160 [1131:0000]

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 27

NUMA node: 0

Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

Address: 00000000fee01004 Data: 402b

Capabilities: [50] Express (v1) Endpoint, MSI 00

DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

MaxPayload 128 bytes, MaxReadReq 128 bytes

DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

Capabilities: [74] Power Management version 2

Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Kernel driver in use: SAA716x FF

Kernel modules: saa716x_ff

Also das war nicht die Lösung nur den neueren Kernel zu laden.

Nun den neuen Treiber Patch geholt und mit meinem Skript erneut die Module kompiliert, Reboot.

Danach lspci geprüft:

03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

Subsystem: Technotrend Systemtechnik GmbH SAA7160 [13c2:300a]

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 27

NUMA node: 0

Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable+ Count=1/32 Maskable- 64bit+

Address: 00000000fee01004 Data: 402c

Capabilities: [50] Express (v1) Endpoint, MSI 00

DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

MaxPayload 128 bytes, MaxReadReq 128 bytes

DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

Capabilities: [74] Power Management version 2

Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Kernel driver in use: SAA716x FF

Kernel modules: saa716x_ff

Damit kommt die richtige Sub ID.

Die Hardware-Erkennung von EasyVDR5 klappt nun auch wieder mit der original Datenbank ohne den Eintrag 1131:0000.

Also nochmal den älteren Kernel 5.4.0-54-generic gebootet:

lspci bringt wieder die falsche Sub-ID 1131:0000

Dann den neuen Treiber-Patch kompiliert für diesen Kernel.

vdr gestoppt

rmmod saa716x_ff zum entladen

lsmod zeigte an dass es auch entladen war

modprobe saa716x_ff zum laden

lspci brint immer noch die falsche Sub-ID 1131:0000 obwohl der neu kompilierte Treiber geladen wurde.

Reboot und erneuter boot mit kernel 5.4.0-54-generic

lspci zeigt nun die korrekte Sub-ID an !

-> OK der neue Treiberpatch ist die Lösung. Es wird zwingend ein reboot des kernels nötig.

Noch eine Kleinigkeit zum kompilieren:

Beim kompilieren der Module mit meinem Skript trat noch ein Fehler auf:

...

The next patch would create the file Documentation/media/uapi/dvb/audio-get-pts.rst,

which already exists! Assume -R? [n]

usw...

...

Ich habe bereits das versucht:

- /usr/src/linux-source-5.4.0 -> make clean -> keine Abhilfe

- make distclean -> keine Abhilfe

- patch --forward -p1 -> keine Abhilfe: führt dazu dass alle Patchbefehle übersprungen werden, selbst die welche noch nicht vorhanden sind in saa716x_boot.c war immer noch die Greg-Zeile drin obwohl sie mit dem neuen Patch verschwinden sollte. Der Patch wirkte also nicht.

- /usr/src/linux-source-5.4.0 von Hand gesäubert, alle Verzeichnisse bis auf die debian-Verzeichnisse und die tar.bz2 zum entpacken der Sourcen. Nur damit hat das Patchen wieder funktioniert wenn man auf leere Verzeichnisse neu entpackt.

Das bedeutet: wenn schon mal gepatch wurde dann kann man nicht nochmal einen anderen Patch darauf anwenden. Habe ich das so richtig verstanden?

Wie macht ihr das richtig?

Ich kann natürlich mit meinem Skript auch alles löschen vor dem entpacken und patchen. Soll ich das so tun?

Hallo S:oren,

ich habe die Module mit meinem Script kompiliert. Im Prinzip basiert es auf deine Hinweise die ich im vdr portal gefunden hatte.

Es klappte damit auch ohne Fehler, die Karte funktioniert.

Vor dem kompilieren musste ich die kernel sourcen vom Ubuntu repository holen, aber weil man da immer den letzten Stand bekommt

hat dieser nicht zum vorinstallierten kernel von easyVDR5 gepasst, also habe ich ein upgrade gemacht. Nach einem reboot passte dann

kernelversion zur sourceversion. Danach habe ich im Prinzip deine Anleitung hoffentlich richtig befolgt.

Die kernelversion ist bei mir aktuell diese:

uname -r ->

5.4.0-54-generic

Damit kommt diese Ausgabe:

lspci -vvv -nn ->

03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

Subsystem: Philips Semiconductors SAA7160 [1131:0000]

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 27

NUMA node: 0

Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

Address: 00000000fee01004 Data: 402b

Capabilities: [50] Express (v1) Endpoint, MSI 00

DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

MaxPayload 128 bytes, MaxReadReq 128 bytes

DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

Capabilities: [74] Power Management version 2

Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Kernel driver in use: SAA716x FF

Kernel modules: saa716x_ff

Der vorinstallierte kernel ist ja auch noch im grub, also habe ich den mal gebootet (hier habe ich keine module kompiliert):

uname -r ->

5.4.0-26-generic

Damit kommt diese Ausgabe, mit der richtigen Sub-ID:

lspci -vvv -nn ->

03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

Subsystem: Technotrend Systemtechnik GmbH SAA7160 [13c2:300a]

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 11

NUMA node: 0

Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+

Address: 0000000000000000 Data: 0000

Capabilities: [50] Express (v1) Endpoint, MSI 00

DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

MaxPayload 128 bytes, MaxReadReq 128 bytes

DevSta: CorrErr- NonFatalErr+ FatalErr- UnsupReq+ AuxPwr- TransPend-

LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

Capabilities: [74] Power Management version 2

Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Man beachte dass lspci mit kernel 5.4.0-26-generic wieder die richtige sub-ID ausgibt.

Allerdings werden hier auch keine module geladen.

Mit kernel 5.4.0-54-generic bringt lspci die falsche sub ID aus. Allerdings sind hier die nachkompilierten module bereits geladen.

Also habe ich den vdr gestoppt und mit rmmod saa716x_ff entladen. Dann kommt das raus:

lspci -vvv -nn:

03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

Subsystem: Philips Semiconductors SAA7160 [1131:0000]

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-

Interrupt: pin A routed to IRQ 19

NUMA node: 0

Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable- Count=1/1 Maskable- 64bit+

Address: 0000000000000000 Data: 0000

Capabilities: [50] Express (v1) Endpoint, MSI 00

DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

MaxPayload 128 bytes, MaxReadReq 128 bytes

DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

Capabilities: [74] Power Management version 2

Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Kernel modules: saa716x_ff

Immer noch die falsche sub ID.

Ein Vergleich deckt auf dass noch etwas anderes angezeigt wird:

bei kernel 5.4.0-26-generic:

DevSta: CorrErr- NonFatalErr+ FatalErr- UnsupReq+ AuxPwr- TransPend-

bei kernel 5.4.0-54-generic:

DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

Leider kann ich die sourcen zu 5.4.0-26-generic nicht finden.

Ich könnte jedoch einfach mal mit den vorhandenen sourcen 5.4.0-54-generic dies unter dem kernel 5.4.0-26-generic kompilieren und schauen was dabei rauskommt.

Was meinst du?

Hallo S:oren,

hab gerade noch unter EasyVDR anstatt lspci den Befehl hwinfo ausgeführt.

hwinfo :

>> pci.2: get sysfs pci data

pci device: name = 0000:03:00.0

path = /devices/pci0000:00/0000:00:0b.0/0000:03:00.0

modalias = "pci:v00001131d00007160sv000013C2sd0000300Abc04sc80i00"

class = 0x48000

vendor = 0x1131

device = 0x7160

subvendor = 0x13c2

subdevice = 0x300a

irq = 27

res[0] = 0xfbf00000 0xfbffffff 0x140204

config[64]

direkt danach nochmal lspci -vvv -nn :

03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

<------>Subsystem: Philips Semiconductors SAA7160 [1131:0000]

<------>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 27

<------>NUMA node: 0

<------>Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

<------>Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

<------><------>Address: 00000000fee01004 Data: 402b

<------>Capabilities: [50] Express (v1) Endpoint, MSI 00

<------><------>DevCap:>MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

<------><------><------>ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

<------><------>DevCtl:>CorrErr- NonFatalErr- FatalErr- UnsupReq-

<------><------><------>RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

<------><------><------>MaxPayload 128 bytes, MaxReadReq 128 bytes

<------><------>DevSta:>CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

<------><------>LnkCap:>Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

<------><------><------>ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

<------><------>LnkCtl:>ASPM Disabled; RCB 128 bytes Disabled- CommClk-

<------><------><------>ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

<------><------>LnkSta:>Speed 2.5GT/s (ok), Width x1 (ok)

<------><------><------>TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

<------>Capabilities: [74] Power Management version 2

<------><------>Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

<------><------>Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

<------>Capabilities: [80] Vendor Specific Information: Len=50 <?>

<------>Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

<------>Kernel driver in use: SAA716x FF

<------>Kernel modules: saa716x_ff

Man beachte fett markierte Angaben.
Das würde bedeuten lspci gibt was anderes aus als hwinfo !!!

@gb:

Den Eintrag 1131:0000 würde ich nicht in die Datenbank von easyVDR aufnehmen, es bedeutet ja dass die Ausgabe von lspci falsch wäre oder?

hwinfo gibt es korrekt aus.

S:oren:

Was hälst du davon? Eine Idee warum lspci was anderes ausgibt? Hab schon von lspci die neuesten Sourcen 3.7.0 geholt und kompiliert, es kommt als Subsystem auch 1131:0000 raus anstatt wie bei hwinfo 13c2:300a.

Hallo S:oren,

vielen Dank für die Hinweise. Ich habe gerade Clonezilla gebootet und lspci -v -n gemacht.

Dann wieder easyVDR 5 (Ubuntu 20.04 im Unterbau) gebootet, also der gleiche PC mit der selben TT-S2 6400 und da auch lspci -v -n gemacht.

Hier das Ergebnis:

Clonezilla:

---------------------------------------------------------------------

03:00.0 0480: 1131:7160 (rev 02)

Subsystem: 13c2:300a

Flags: bus master, fast devsel, latency 0, IRQ 11, NUMA node 0

Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+

Capabilities: [50] Express Endpoint, MSI 00

Capabilities: [74] Power Management version 2

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Und das kommt bei EasyVDR5 (Ubuntu 20.04):

---------------------------------------------------------------------

03:00.0 0480: 1131:7160 (rev 02)

Subsystem: 1131:0000

Flags: bus master, fast devsel, latency 0, IRQ 27, NUMA node 0

Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

Capabilities: [50] Express Endpoint, MSI 00

Capabilities: [74] Power Management version 2

Capabilities: [80] Vendor Specific Information: Len=50 <?>

Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

Kernel driver in use: SAA716x FF

Kernel modules: saa716x_ff

Einziger Unterschied ist die ID und diese Zeile Capabilities: [40] MSI...

Nochmal:

wenn man EasyVDR5 neu installiert mit der ISO wird dieselbe TT-S2 6400 wieder erkannt !!! Das kann nur geschehen wenn lspci dann wieder die korrekte ID ausgibt.

Wenn man dann weitermacht mit der Installation von EasyVDR5 mitsamt Kernelupdate (alles vom Ubuntu 20.04 repository) und manuelles Module kompilieren für die TT-S2 6400 und laden der Module wird danach die Karte im Hardware-Setup von EasyVDR nicht mehr erkannt !!! lspci bringt nun eine andere ID !!!

Grund kann keinesfalls EasyVDR sein oder die Hardware selbst, das belegt oben das Ergebnis !!!

Es muss also etwas damit zu tun haben welcher Kernel läuft oder wie ich die Module erzeugt habe.

Wieso sonst bringt plötzlich lspci eine andere ID als Subsystem? Die Karte funktioniert ja korrekt und unter einem anderen System wird die richtige ID wieder erkannt. Das kann doch nicht der Eprom sein, oder wird der vom aktuellen Linuxsystem umgeschrieben? Kann ich mir nicht vorstellen.

Ich werde als nächstes mal ein Ubuntu 20.04 booten und lspci wieder prüfen.

Hast du noch eine Idee für das unterschiedliche Verhalten von lspci auslösen könnte?

Verwendest du eine TT-S2 6400 unter Ubuntu 20.04 schon so dass ich mir den Aufwand nicht antun müsste?

Hallo Sören,

OK, aber wie geschieht das, den Eprom zerschiessen? Ich habe nichts an der Karte rumgemacht.

Und wieso wird die Karte wieder erkannt wenn ich eine Neuinstallation vomUSB-Stick mache, an der iso habe ich ja gar nichts angepasst, sie ist original.

Damit wird im HW-Setup wieder TT-S2 6400 erkannt. Demnach müsste ja die originale HW-ID wieder funktionieren? Das könnte nicht sein wenn etwas am Eprom auf der Karte dauerhaft zerschossen wäre.

Ich kann mal Clonezilla booten und mit lspci auslesen ob da was anderes kommt bei einem anderen System/Kernel.

Oder kann man die Installations-ISO booten und dann auf die Konsole wechseln um das zu testen?

Komisch ist das schon.

Hallo,

ich verwende seit Anfang 2020 meine TT-S2 6400 ohne Probleme mit EasyVDR5. Die Module muss man selber kompilieren. Im Laufe der Zeit habe ich mir ein kleines Skript dafür gemacht, weil die Module bei einem Kernelupdate immer wieder kompiliert werden müssen. Damit das nicht immer wieder gemacht werden muss setzt das Skript nicht nur den Kernel sondern auch die dazu gehörigen Sourcen auf Hold. Damit bleibt immer alles was dazugehört auf dem gleichen Stand.

Hier das Skript "compile_dvb.zip" compile_dvb.zip

Es ist nur rudimentär, Jeder Schritt wird einzeln abgefragt, damit kann man jederzeit abbrechen und wieder einsteigen. Kann man sicherlich auch besser machen.

Problem war aber schon von Anfang an bei easyVDR5:

nach einer Erstinstalltion vom USB-Stick wird die TT-S2 6400 erkannt, aber ohne Treiber halt. Dies wurde später dann getan und funktionierte dann auch. Dabei wurde aber auch ein Kernelupdate mit den passenden Sourcen von mir geladen. Alles OK soweit. Wenn man dann aber eine erneute Hardwareerkennung im Setup auslöste wurde die TT-S2 6400 nicht mehr erkannt. Es kam "unbekanntes DVB Device". Ebenso wurde der IR-Empfänger nicht mehr erkannt. Grund: lspci bringt eine andere Hardware-ID aus als in der Datenbank hinterlegt ist:

Bei mir ist es 1131:0000

Ich habe die Datenbank ergänzt (neu: fett und unterstrichen):

/usr/share/easyvdr/setup/hw-detect/hw-lib/20_video_in_hw

->

# FF-HD-Karte

hw_name[5]="FF-HD TT-6400"

hw_ident[5]="1131:7160 \

13c2:3009 13c2:300a 1131:0000"

det_method[5]="chk_lspci3"

ins_method[5]="inst_write-info"

paraset_a[5]="FF-HD-Karte(TT6400)"

paraset_b[5]="STD_DRV_NO"

paraset_c[5]="<empty_value>"

paraset_d[5]="<empty_value>"

paraset_e[5]="<empty_value>"

/usr/share/easyvdr/setup/hw-detect/hw-lib/40_remote_control_receiver

->

# FF-HD-Karte

hw_name[20]="IR der TT-6400 Karte"

hw_ident[20]="1131:7160 \

13c2:3009 13c2:300a 1131:0000"

det_method[20]="chk_lspci3"

ins_method[20]="inst_lirc"

paraset_a[20]="ID_TXT"

paraset_b[20]="dev_input"

paraset_c[20]="Event"

paraset_d[20]="TT6400 DVB IR receiver"

paraset_e[20]="TT6400 DVB IR receiver"

Ich habe das analysiert mit der Routine chk_lspci3 aus der Datei chk_lib und dies an der Konsole überprüft:

chk_lspci3()

{

PCI_ID_ARRAY=($@)

ELEMENT_COUNT=${#PCI_ID_ARRAY[*]}

echo "Elementcount:" $ELEMENT_COUNT >> hw.txt

echo "PCI ID Array:" $PCI_ID_ARRAY >> hw.txt

RET_STATUS=1

if (($(lspci -n | grep -ic ${PCI_ID_ARRAY[0]}) != 0)); then

for ((i=1;i<$ELEMENT_COUNT;i++))

do

echo "PCI_ID_ARRAY:" ${PCI_ID_ARRAY[$i]} >> hw.txt

echo "aktiver Index:" $i >> hw.txt

(($(lspci -nv | grep -i "sub" | grep -ic ${PCI_ID_ARRAY[$i]}) != 0)) && RET_STATUS=0

((RET_STATUS == 0)) && break

done

fi

echo "Ergebnis:" $RET_STATUS >> hw.txt

return $RET_STATUS

}

Bei der Stelle wo die sub ID geprüft wird kommt bei mir 1131:0000 an der Konsole raus, warum auch immer.

Mit den neuen Einträgen in der Datenbank wird die Karte sowie der IR-Empfänger wieder erkannt und die Installation klappt dann auch.

Ich konnte so über das Hardware Setup den IR-Empfänger auf Lirc Com1 umstellen und wieder zurück auf den IR-Empfänger der TT-S2 6400.
Hier die Dateien von mir "hw-lib.zip" hw-lib.zip