Beiträge von onur

    hi,
    hab gerade mit media_build_experimental_work getestet, leider keine besserung - sondern schlimmer.
    UNC steigt um 0x20(30) - mit den alten treibern lag der UNC anstieg bei 3. Beim work treiber erhöht sich UNC zusätzlich beim beenden, und BER Werte schlagen länger aus.


    bei reinem vdr betrieb kann ich dieses problem nicht nachvollziehen.
    es passiert also wirklich nur beim öffnen/beenden vom frontend.


    ich hatte aber immer wieder unerklärliche BER anstiege - welche gefühlt weg sind, wenn ich immer nur das zweite forntend verwende.



    es ist aber nicht auszuschließen dass dieses problem auch bei reinem vdr betrieb auftritt, solange wir nicht wissen wo genau im code das problem auftritt.


    gruss, onur

    Hi,
    ich hatte immer wieder Artefakte mit den Digital Devices Karten.
    nach endlosem testen konnte ich das Problem eingrenzen.
    es würde mich wundern wenn ich der einzige mit den Problemen bin.
    das hier beschriebene Test Setup führt so gut wie immer zu Artefakten (UNC).


    Test Setup 1: geht am schnellsten und ist unabhängig vom vdr.
    wir testen immer zusammengehörende Tuner, also a0+a1 oder a2+a3, usw...
    Standard mäßig wird der Treiber als Mutlifrontend geladen, also a0f0+a0f1, a1f0+a1f1.


    2 x putty Fenster öffnen
    zap.conf im root oder sonst wo anlegen - inhalt siehe unten.


    1. vdr beenden: /etc/init.d/vdr stop
    2. putty1: szap -c /zap.conf -a 0 -f 0 ARDHD
    3. putty2:
    Multi Frontend Variante: szap -c /zap.conf -a 0 -f 1 ARDHD
    Single Frontend Variante: szap -c /zap.conf -a 1 -f 0 ARDHD


    mehrfach Befehl aus Schritt 3 beenden und wiederholen - dabei BER und UNC in putty1 beobachten.


    man kann nun beobachten dass sich UNC bei jedem tune Vorgang auf der ersten karte erhöht.
    BER werte bleiben meist auf 0 - manchmal auch nicht - hängt wohl vom Timing ab - das Intervall der BER Berechnung im Treiber ist wohl einfach zu gering.
    meine Beobachtung(Vermutung) bei BER: BER Ausschläge sieht man entweder immer, oder nie - diese Verhalten kann sich nach jedem Rechner Neustart ändern.
    Das Intervall der BER Berechnung im Treiber ist wohl zu gering – oder das Timing gerade so dass man was sieht oder eben nicht…


    Ich habe bei mir ein Setup, wo ich die Fehler(TS continuity) sehe (ist aber zu umfangreich dies hier zu posten).
    Immer wenn sich UNC erhöht, liegen auch TS continuity vor – der Stream ist also unterbrochen.


    Test Setup 2: hier sieht man die Artefakte live
    vdr starten mit option –D 0 (dann verwendet er nur die erste karte).
    Ich stelle bei mir die Option in der Datei /etc/default/vdr ein. OPTIONS="-w 60 –D 0"


    Das Erste HD aufnehmen und im putty den Befehl aus Schritt3 (siehe oben) mehrmals ausführen.
    Im syslog müsste man die Fehler sehen als: TS continuity error


    Man könnte auch einfach Das Erste HD live tunen, und den Befehl von Schritt3 (siehe oben) mehrmals ausführen.
    Ab und zu sind nun Artefakte sehen.



    meine Erkenntnis:
    Tune Vorgänge auf zusammengehörenden Karten beeinflussen sich.
    UNC erhöht sich um 3 auf dem jeweiligen Partneranschluss und TS Pakete gehen verloren.
    Karten in unterschiedlichen PCIe Slots beeinflussen sich nicht.



    ich hab getestet mit:
    3 x Cine S2 V6.5 (mit und ohne Extension)
    2 x Cine S2 V5.5 (ohne Extension)
    1 x Digital Devices GmbH Octopus Mini
    1 x Mystique Satix S2 dual V1 (ohne Extension)
    1 x Mystique Satix S2 dual V2 (ohne Extension)



    Strom Kabel natürlich immer dran (testweise auch mal ohne).
    unterschiedliche kernel versionen und media_build_experimental varianten.
    unterschiedliche Intel Chipsätze.
    unterschiedliche Bios Settings (C1E deaktivieren, Spread Spectrum, usw...)


    vielleicht kann jemand das Problem nachvollziehen.


    zap.conf:

    Code
    ARDHD:11493:hC23M5O35P0S1:S19.2E:22000:5101:5102=deu,5103=mis;5106=deu:5104:0:10301:1:1019:0ZDFHD:11362:hC23M5O35P0S1:S19.2E:22000:6110:6120=deu,6121=mis,6123=mul;6122=deu:6130:0:11110:1:1011:0ARDSD:11837:hC34M2O0P0S0:S19.2E:27500:101:102=deu,103=mis;106=deu:104:0:28106:1:1101:0ARTEHD:11493:hC23M5O35P0S1:S19.2E:22000:5111:5112=deu,5113=fra,5117=mis;5116=mul:5114:0:10302:1:1019:0SERVUSTVHD:11303:hC23M5O35P0S1:S19.2E:22000:4920:4921=deu,4922=deu;4924=deu:4925:0:4914:1:1007:0



    gruss, onur

    hallo,


    mein vdr generiert teilweise falsche channels.conf einträge.


    Die Modulation stimmt nicht, die Sender sind dann nicht zuverlässig tunebar.


    falsch:
    AXN HD;SKY:11332:hC34M16O35S1:S19.2E:22000:255:0;259=deu,260=eng:32:1833,9C4,98C:125:133:10:0


    richtig:
    AXN HD;SKY:11332:hC34M5O35S1:S19.2E:22000:255=27:0;259=deu@106:32:1833,9C4,98C:125:133:10:0



    kann man da was machen?
    gruss, onur

    hallo,
    die karte fügt bei mir die neuen SKY Welt sender falsch hinzu!
    ist dass bei euch auch?


    Code
    RICHTIG:
    TNT Film (TCM),TNT Film;SKY:10920:HC78M2O0S0:S19.2E:22000:511=2:512=deu@3,513=eng@3:0:1702,1833,9C4:35:133:15:0
    
    
    FALSCH:
    TNT Film (TCM),TNT Film;SKY:10920:hC56M2O0S0:S19.2E:22000:511:512=deu,513=eng:0:1702,1833,9C4:35:133:15:0


    gruss, onur

    hallo, mich hat dass auch geärgert,
    ich habe dazu den vdr angepasst, bei mir testet der vdr in regelmässigen abständen alle karten ob sie signal haben (immer mit dem ersten jeweiligen kanal den die karte kann), wenn kein signal dann deaktiviere ich die karte,
    funktioniert super, mein vdr läuft auch wenn mal an einer der karten kein kabel dran hängt.
    gruss, onur

    Hallo, hätte ne frage.
    Ich habe gerade versucht einen 64 bit kernel mit 32 bit userspace laufen zu lassen.
    die treiber habe ich kompiliert, wie hier beschrieben.


    bei start des vdr bekomme ich fehlermeldungen:

    kernel: [ 100.256373] ioctl32(vdr:2247): Unknown cmd fd(19) cmd(40086f52){t:'o';sz:8} arg(ef0f92bc) on /dev/dvb/adapter3/frontend0


    mit 32bit kernel habe ich keine probs,


    danke, gruss, onur


    ich wollte gerstern einen neuen kernel installieren - wegen XEN - KVM - Grafik - durchreichen... (war zufall, dass der 2.38 gerade freigegebn wurde).


    leider geht die Realtek 8112L nicht, bzw. haufenweise link down,up meldungen - wenn sie ausgelastet ist.
    NOHZ: local_softirq_pending 08 r8169 link up


    gruss, onur

    nochwas,
    als ich den stecker ins leerrohr eingefädelt habe dachte ich, keine chance (dass leerrohr hat sehr kleine radien, sogar die feder ging kaum durch).
    habs aber trotzdem probiert, und ging wirklich super.


    gruss, onur

    hallo, ich hatte ein ähnliches problem,


    ich hab ein mini HDMI aud HDMI kabel gekauft (und einen adapter mini auf hdmi).
    am mini hdmi stecker den gummi etwas zurecht geschnitten,
    dann flutschte es ohne probleme durchs leerrohr (außendurchm. 18mm?).


    mit einem hdmi kabel kommst du dann bis zu 30m - mit entprechendem verstärker. z.B.
    http://www.digitus.info/produk…l-hdmi-repeater-ds-55901/



    ansonsten kannst du auch sowas nehmen.


    Digitus hdmi extender, kostet ca. 70€
    http://www.digitus.info/produk…-video-extender-ds-55100/


    gruss, onur

    hi,
    ich habe dass auch schon beobachtet, aber nur bei sky und h264.
    bei mir ist außerdem hardlink cutter mit 256MB aktiv.


    rausgefunden hab ich folgendes:
    es kann passieren das in der index.vdr falsche positionsangaben stehen.
    die index.vdr ist nicht komplett falsch, anzahl der frames passt..


    beim schnitt wird die index.vdr nicht neu aus den video files generiert(bin mir nicht sicher - wäre aber unnötig)?
    somit haben die geschnitten aufnahmen dass selbe problem, noch schlimmer: das erste vdr file der geschnitten aufnahme beginnt nicht mit 00 00 01 ...


    ich dachte zuerst dass es am pid wechsel liegt, dann müssten aber die ersten paar einträge der index.vdr korrekt sein.


    ich schau mir das am wochenende mal genauer an...
    ich tippe auf ein problem mit dem hardlink cutter.


    gruss, onur

    hallo, olliver
    ich hab ähnlcihes wie sgp01 durchgemacht...
    der treiber liefert grundlos müll daten, egal ob SD oder HD....
    ich könnte mir vorstellen dass es mit PCI-E, timing, oder IRQ zu tun hat.


    ich habe auch verschiedene MB getestet, und kam zum schluss dass bestimmte Chipsätzte den fehler definitv öfter produzieren.


    andere user haben dass problem durch grub boot optionen NOAPIC... gefixt(kann ich leider nicht machen).
    Ich denke dass man genau hier ansetzten sollte...


    danke, für deine arbeit, gruss, onur

    vdr_rossi
    du must das ngene rep. nehmen,
    http://linuxtv.org/hg/~endriss/ngene
    die neuesten v4l kompilieren nur mit ganz aktuellem kernel. hab mich auch geärgert.
    wenn du nen aktuellen kernel nimmst sind die neuesten ngene patches bereist drin.


    IG88
    als ich zum ersten mal die karte in betrieb nahm, lief dass ding auch über mehrere tage ohne mucken.
    mit 2 dual karten wurde es dann schlimmer.
    ich habe keine probleme mit 4 X Hauppauge DVBS2, 4xKNC, FF.


    ich habe dass thema hier schon mal beschrieben:
    http://www.vdr-portal.de/board/thread.php?threadid=94741


    UFO war anfangs auch der meinung dass die karten laufen, nach intensiven tests hatte er dann dass selbe prob.


    Zitat

    Am WE habe ich einen langen Test mit 2 cineS2 Karten gestartet.
    Nach 3 Tagen lieferte Tuner #4 nur noch Datenmüll.
    Nur Entladen und Neuladen von ngene.ko hat geholfen.


    ich finde es verblüffend dass dieser bug von vielen nicht bemerkt merkt.
    ich hab bis auf nvidia eigenlich alle MBs getestet. die neuen i3/i5 Boards waren am schlimmsten, ältere intel besser, AMD noch besser.
    um alles auszuschließen hat ein bekannter mitgetestet - mit dem selben ergebnis. ich hab den vdr gepatcht damit bei den aufnahmen in die info.vdr der BUS Pfad der karte mitgeloggt wird..., ich habe sogar den stromverbrauch der karte gemessen, und kontrolliert was für auswirkung der externe anschluss hat (OT - ich glaube dass viele Probs ab 4 x sat durch zu schwache netzteile hervorgerufen werden - aktuelle netzteile haben auf der 3.3v schien einfach zu wenig power.).
    ich hab den code vom treiber angeschaut, da und dort was geändert, und dann schließlich aufgegeben.



    gruss, onur

    hallo,


    ich habe die karte (alle versionen, alle treiber variationen), mit ca. 10 unterschiedlichen mainboards getestet.
    läuft definitv nicht. im besten fall läuft sie mal für 3 tage.
    vdr systeme die regelmässig ausgeschaltet werden, bemerken dass eventuell nicht.


    nach einer gewissen zeit sendet sie nur noch müll pakete.
    hab dass ganze auch ohne vdr getestet.
    wenn sie in diesem "defekten" zustand ist, kommen nur noch müll TS pakete - nur noch ca. 5% der datenmenge...


    du kannst dass einfach testen, vdr beenden und folgendes eingeben, und 10 sekunden laufen lassen (jeweils in intaktem und defekten zustand).
    auf konsole1: szap -a0 -n1 -r
    auf konsole2: cat /dev/dvb/adapter0/dvr0 > /tmp/recording.ts


    mit AMD chipdatz läuft sie etwas besser(länger). denke dass es irgendein bus oder timing problem ist. leider passiert die letzte zeit nix bei der treiberentwicklung.


    ist schade, da für meine begriffe die karte grundsätzlcih perfekt ist.
    ich wäre auch bereit den entwickler finanziell zu unterstützten.


    edit: damit szap funzt die channels.conf nach /root/.szap/channels.conf kopieren.


    gruss, onur

    hallo, august ist gut...


    grillen wäre auch mal was neues.
    da die gruppe eh relativ überschaubar ist, kann ich mir dass auch bei mir vorstellen.


    was ich anbieten kann ist folgendes:
    Location: Lustenau - Vorarlberg
    Garten mit überdachter laube,
    eventuell nen Profi Gas Grill (den ich vom bekannten ausleihen könnte)
    Holz Kohle Grill,
    große feurstelle,
    freie Sat anschlüsse.


    ich hab auch noch 3-4 freie Zimmer in einer leer stehenden wohnung...


    gruss, onur

    da war magicdragon67 wohl schneller...


    hallo,
    du must schon mit lspci -v prüfen ob die bios einstellung greift...


    zur erklärung: (achtung halbwissen)
    je größer dieser wert, umso länger darf ein PCI gerät den Bus für sich beanspruchen.
    gemeint sind Takt Zyklen, wird also auch vom PCI Bus Speed abhängen.
    ab PCI 2.1 sind dass 66Mhz und somit 15ns pro takt.


    da alle PCI geräte sich den BUS teilen ist sowas notwendig...
    je weniger PCI Geräte umso höher könntest du dieses Latenzzeit einstellen...


    eventuell solltest du ne aufnahme machen, und prüfen ob die fehlerhaft ist.


    gruss, onur