Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

  • Es ist der Tuner der DD, der beim start des VDR aktiv ist. Wie nehme ich dies raus?

    Antec Fusion Remote black
    Asrock B150M Pro4S/D3
    Celeron G4560
    2x4 GB Ram 1600Mhz
    Kingston 60GB V300 SSD
    Zotac GT1030
    LG GH-22NS
    DD Cine C2/T2I V7

    DD DuoFlex C2/T2/ISDB-T

    DD Duoflex Dual CI
    Gen2VDR6.0

  • Es ist der Tuner der DD, der beim start des VDR aktiv ist. Wie nehme ich dies raus?


    Prüfe mit dem femon-Plugin, welcher Tuner Empfang hat und welcher nicht.
    Offenbar ist auch noch eine Satelco DVB-C eingebaut.


    Da ich nicht weiß, wo das "redirect" her kommt, kann ich auch nicht sagen, wie man es heraus nimmt.
    Kann in einem Startskript stehen oder in einer udev-Rule.


    CU
    Oliver

  • "DVB-C #0 - STV0367 DVB-C DVB-T" bringt kein Bild. "DVB-C #1 - STV0367 DVB-C DVB-T" und "DVB-C #2 - Phillips TDA10023 DVB-C" bringen Bild. Das redirect stand im VDR startscript, habe ich nun auskommentiert.


    Edit: Ok, mann hätte nach dem entfernen des redirect auch den kompletten Rechner neustarten müssen und nicht nur den VDR. Danke, jetzt geht es. :-)

    Antec Fusion Remote black
    Asrock B150M Pro4S/D3
    Celeron G4560
    2x4 GB Ram 1600Mhz
    Kingston 60GB V300 SSD
    Zotac GT1030
    LG GH-22NS
    DD Cine C2/T2I V7

    DD DuoFlex C2/T2/ISDB-T

    DD Duoflex Dual CI
    Gen2VDR6.0

    The post was edited 3 times, last by motorsense ().

  • Erst mal vielen Dank an UFO und die anderen Entwickler für die tolle Arbeit. Ich habe die cine S2 in der Version < 5 seit 2 Jahren in Benutzung und war sehr zufrieden.


    Vor kurzem habe ich mein Mainboard auf ZOTAC D2550 geändert und leider einige Probleme. Im ersten Schritt konnte ich die cine S2 nur mit den Kernel-Optionen "noapic nolapic" betreiben, das hat die letzten sechs Wochen funktioniert ist aber unbefriedigend. Jetzt habe ich die cine S2 auf die Version 6.5 upgedated, aber die Karte läuft nicht. Ein Sundtek USB-Empfänger (DVB S2) läuft dagegen problemlos.
    Weiter Infos hier:
    Syslog http://paste.ubuntu.com/7104828/
    Kernel-Log [url]http://paste.ubuntu.com/7104839/[/url]


    Das habe ich gemacht
    1) cine S2 (alt) gegen neue cine S2 (Version 6.5) getauscht
    2) Packet installiert linux-media.. installiert und nach Test wieder deinstalliert
    3) Packet media-build-experimental-dkms installiert (Version 2014030X...)
    4) Kernel auf Version 3.8.0.37 upgedated (Packet aus ppa)
    5) Packet media-build-experimental-dkms: Down grade auf ätere Version (201401XX...)
    6) Packet media-build-experimental-dkms entfernt und Treiber von der Web-Seite eines Entwicklers aus den Sourcen (ddd...) installiert


    Ab Schritt 3 hatte ich immer eines der folgenden Ergebnisse:
    a) Treiber (dvb-core; cxd2099; ddbridge) ist geladen aber Karte wird nicht erkannt (keine Eintrag unter /dev/dvb). Das passiert vorzugsweise bei einem Warmstart. Dazu gibt es schon Beiträge im Forum.
    b) Treiber (siehe oben) wird geladen und Device ist vorhanden, aber kein Bild und Fehlermeldung im syslog "DDBridge I2C timeout, card 0, port 0"


    Ich vermute eine von zwei Erklärungen trifft zu: Hardware defekt oder Version ist nicht 6.5 und wird vom Treiber nicht unterstützt. Soll ich die Karte an linux4media zurückschicken, oder gibt es noch Schritte, die ich versuchen kann?

    VDR-1: POV ION 330, ZOTAC D2550 Wifi Supreme , Digital Devices cine S2 6.5 DVB-S2, ATRIC, yavdr 0.5

  • Karte wird vom Treiber unterstützt und auch korrekt erkannt...


    Ich bin für Variante 3:
    Mangelhafte Linuxunterstützung für das Mainboard.

    Code
    1. hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.


    Dies kommt vor den I2C-Timeouts und bei Card #0 und Card #1.
    Ohne funktionierendes Interrupt-Handling wird das ganze nie funktionieren!


    CU
    Oliver

  • Nicht zu vergessen, Zotacs Liebling:

    Quote

    Mar 16 14:24:31 yavder kernel: [ 10.286037] ACPI: This conflict may cause random problems and system instability


    Führt bei mir (zum Glück nur alle paar Wochen mal) auch zu

    Quote

    a) Treiber (dvb-core; cxd2099; ddbridge) ist geladen aber Karte wird nicht erkannt (keine Eintrag unter /dev/dvb). Das passiert vorzugsweise bei einem Warmstart. Dazu gibt es schon Beiträge im Forum.


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • Danke für die schnellen Antworten. Ich gehe erst mal davon aus, dass es kein Hardware-Defekt ist.


    Bisher konnte ich die in den Logs dokumentierten Fehler (einer eher unspezifisch, einer bezüglich Audio-Hardware und Interrupts) noch nicht beseitigen. Ich habe einige Kernel Optionen bezüglich APCI-System versucht (apci=ht; apci=noirq), aber das war nicht erfolgreich. Ich werde jetzt BIOS-Einstellungen verändern und Parameter zu den Kernelmodulen versuchen (options snd-hda-intel enable_msi=1).
    Das ist allerdings schon off topic, weil kein direkter Zusammenhang zum ngene/Octopus Treiber besteht. Trotzdem würde ich mich über Lösungsvorschläge freuen 8)


    Grüße
    Alexander

    VDR-1: POV ION 330, ZOTAC D2550 Wifi Supreme , Digital Devices cine S2 6.5 DVB-S2, ATRIC, yavdr 0.5

  • Hi,


    Sorry for English (I can read German - just barely - but not write it!). I've been following this thread for a while. Also, using my DD Octopus + DVB C/T dual for a while. However, I have a weird problem with using the CAM with the redirect method and adapter_alloc.


    Oh, this is on Gentoo and 64bit . Kernel 3.12.0.


    1st) There's no problem if I don't enable the CAM at all (and use adapter_alloc=0) - I can use both front ends without issue.


    2nd) If I modprobe with adapter_alloc=3 (without echo "AB CD" > redirect!) , I can't tune on the second frontend:


    But, I can tune on the first frontend (-f 0):


    and, while tuning on the first frontend, I can also tune on the second - but as soon as the first frontend is closed, the second one comes unusable again! (again with the same error as above, nothing in syslog).


    3rd) If I use the redirect method (of course a fresh reboot as per instructions) to try to use the CAM, both frontends become unusable, again with the same error (filter timeout), and nothing in syslog.


    Has anyone had this kind of issue?


    I should probably say, that it used to work in the summer. Since then, at some point it stopped working (I needed to upgrade my Kernel and NVidia drivers), and I haven't come around to fix it, mostly since there's little worth the effort to watch / record on the DVB-C network here. But now, there's a few things I'd like to watch / record...


    My syslog (while initializing the driver):


    And, if I try the redirect method, with this line:


    I get in syslog:


    Maybe this is a 64-bit issue? Are there other users using their CAM on a 64bit Kernel?


    Cheers (and thanks for your work with the driver)!

  • Ich nutze das aktuelle media_build_experimental und erhalte mit meiner DuoFlex CT folgendes ausgeben in dmesg


    Code
    1. [45873.581577] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
    2. [45879.271864] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
    3. [45885.486408] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
    4. [45891.180825] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
    5. [45897.971582] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:


    Ist dies schlimm oder einfach nur irgendwelche Debug-Meldungen?


    Grüße
    Martin

  • Ich nutze das aktuelle media_build_experimental und erhalte mit meiner DuoFlex CT folgendes ausgeben in dmesg


    Code
    1. [45873.581577] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:


    Ist dies schlimm oder einfach nur irgendwelche Debug-Meldungen?


    Meine Kristallkugel sagt, daß die drxk-Firmware nicht installiert ist.
    Im Log dürfte beim Laden des Treibers eine entsprechende Fehlermeldung stehen.


    CU
    Oliver

  • yes. Have al look at this conversation. I used w_scan but the problems, both, the adapter_alloc and the redirect problem, were very similar.

    Thanks for your reply!


    It seems I've had two errors - one caused by me. adapter_alloc works as expected (has no effect on the functioning of the frontends). The other thread pointed out my error: I've just forgotten to give -d as a parameter for scan-dvb; I can scan the second frontend correctly with:


    Code
    1. $ scan-dvb -f 1 -d 1 fi-sonera-new


    However, after redirect, the frontend which output I've redirected to the CI/CAM, does not work anymore. It used to work previously without issues (during the last summer / before it!). It seemed that the frontend had became totally unusable, but now I suddenly get some PID's tuned correctly as I speak, while others don't. It seems somewhat random, and increasing the filter timeout does not work (it either tunes without issues quite fastly, within two seconds, or it doesn't tune at all - or, if I understand correctly, it does tune to the initial transponders but the filter does not get any data trough). I need to do some more testing. So, it is actually exactly like your problem in the other thread.


    So, I wouldn't rule out a hardware issue - maybe our hardware has broken in the exact same way. Did you get your issue resolved?

  • So, I wouldn't rule out a hardware issue - maybe our hardware has broken in the exact same way. Did you get your issue resolved?


    I don't think it is a hardware fault. I have tested it under Windows 7 with MediaPortal and did not encounter such problems. My CAM was a Technisat TechniCrypt CX which uses the Conax-System.


    I resolved it by not using the CI. But it is not allowed to discuss this here.

  • Ah yes, there's alternatives (other hardware and related software not discussable here).


    But, about this hardware - I've noticed something weird. If I use redirect, the frontend is totally useless, until the CAM menu is accessed once (I use gnutv -cammenu). After that, it's a hit and miss - sometimes the tuning works, sometimes it doesn't, seemingly randomly (with filter timeout messages) - but for different channels each time.


    As I said, it didn't used to be like this sometime last summer.


    Example scan-dvb run: (at point where there's "Network Name: 'TSF_FULL' I've just run "gnutv -cammenu" at another terminal - and adapter_alloc=3, echo "00 01" > redirect; I've moved the CI to another TAB to rule out a broken TAB).


  • Please include the mutex patch

  • Please include the mutex patch


    Maybe it would help if you would tell why?


    It is easy to see what it does, but why has it to be done?


    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

  • Gerard,


    thank you for your reply. I am just a user. Looks to me it has to do with locking up the device. I have been applying this patch from the start; without the patch it does not work properly in my setup. Others with similar setups might experience the same. Since its such a simple patch that does not bother users that do not experience this it is nice if it can be included. Makes life easier for everyone (well except for the person that has to include it but thats probably shorter then me typing this message :-D). There's enough waste going on already ;-). thx a lot.

  • thank you for your reply. I am just a user. Looks to me it has to do with locking up the device. I have been applying this patch from the start; without the patch it does not work properly in my setup. Others with similar setups might experience the same. Since its such a simple patch that does not bother users that do not experience this it is nice if it can be included. Makes life easier for everyone (well except for the person that has to include it but thats probably shorter then me typing this message :-D). There's enough waste going on already ;-). thx a lot.


    There is no proof that it doesn't bother other users. Mutex-Locks in a driver are serious things. Simply describe more exactly what happens with and without patch. Describe the hardware you use.


    But anyway the inclusion of the patch is not my decision. Maybe UFO has no problems with it.


    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

  • Thanks for your replies!


    jeee: I've tried your patch, unfortunately it has no effect on my issue. But thanks anyway!


    For the time being, I've "fixed" it so that I've done the scanning and channel setup without redirect, and hope that it works with redirect for watching / recording.


    After setting up channels, rebooting with redirect, and once I've ran 'gnutv -cammenu', I seem to be able to receive anything via MythTV (or probably other software, too, but that's what I'm currently using); I changed channels back and forth in MythTV last night without issues (on the "redirected" frontend, includeing scrambled channels) - but it may be it is not reliable, and it is certainly dirty and hacky. Only time will tell.


    Also, I've tried dvbv5-scan from v4l utils git, with it I get slightly more informative errors, but the behaviour is consistent with the currently released scan utility - click below if you're interested:



    FWIW I also tried to scan without the CAM in the CI, and the behaviour is exactly the same; I believe that rules out issues with my CAM...