Posts by momit

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