Jump to content

cy_coe

Full Member
  • Gesamte Inhalte

    104
  • Benutzer seit

Beiträge erstellt von cy_coe

  1. @bahnbooster

    ich weiß leider nicht, was der ENX-Reset im Avia_gt_proc-Menü genau macht. Hat bei meiner box keine spürbare Veränderung gebracht. Eindeutig weiß ich nur, daß

    touch /var/etc/.zap_enx_reset

    nen Reset beim Umschalten verursacht.

     

    P.S.: Wollte Dir nicht "auf die Füße treten", sondern nur zur Klärung beitragen - also nichts für ungut...

     

    @kacheng

    probiers mal aus. Ich fürchte das ändert nix, aber wer weiß?

  2. Ein Umschalten auf FTA bringt die Box wieder auf Normal und dann kann man ja auch wieder auf verschlüsselte Sender schalten

     

    das funktioniert aber nur, wenn Du den automatischen ENX-Reset beim Umschalten aktiviert hast.

    touch /var/etc/.zap_enx_reset

    Wenn nicht, dann geht das Zwitschern beim Zurückschalten auf PayTV sofort weiter.

    Ist zumindest meine Erfahrung...

  3. @Franzisco

    Das mit den Timings ist interessant. Könnte vllt was bringen da weiter zu forschen. Aber daß Aufnahmen ohne Zwitschern durchlaufen, kann ich leider auch nicht bestätigen. Ich nehme auf nem Linux-NFS-Server auf und das hält die box auch nicht davon ab, gelegentlich mal zu zwitschern.

     

    Wenn ich nen Film aufnehmen will, muß ich das meistens in zwei Schritten machen. Also Aufnehmen bis es zwitschert, dann die Wdh. aufnehmen ab der Stellle wo es beim ersten mal angefangen hat zu zwitschern und dann die Teile zusammenschneiden...

    Sehr mühselig und macht auch nur bei Sendern Sinn, die häufig Sendungen wiederholen (Brummiere und Co.).

  4. Durch den Wechsel des Antennenkabels (gegen ein besseres) verbesserst Du den Empfang der box. Es gibt einige Leute, die der Meinung sind, daß das (Optimierung des Empfangs) die einzige Lösung des Problems ist. Andererseits haben andere die Erfahrung gemacht, daß auch eine perfekt eingerichtete Anlage das Zwitschern nicht endgültig behebt, sondern bestenfalls verzögert. Das liegt wohl daran, daß das Zwitscherproblem bei den boxen unterschiedlich stark ausgeprägt ist.

    Eine genaue Ausrichtung der Schüssel, gute Kabel, gute LNBs/Disecqs etc. sind aber der erste Ansatzpunkt. Bei einigen boxen wird das bestimmt helfen - aber leider nicht bei allen!

  5. Ich meinte auch mehr den ENX-Chip als den ENX Reset........

    Wird der CHIP bei CAMD2 benutzt ?!

    Der wird immer benutzt -soweit ich weiß. Ist ja schließlich eine der Hauptkomponenten der box.

     

     

    (steht COE für Coesfeld ?!)

    äh, nein.

     

    Ob das ein Treiberproblem ist, weiß wohl bisher niemand. Da man das Zwitschern mit nem Reset des ENX beheben kann, ist alles was mit ENX zusammenhängt verdächtig...

    Die `heißeste` :D Spur ist wohl ein Hitzeproblem, da bei einigen das Kühlen des ENX-Chips das Problem gelöst oder zumindest verringert hat.

     

    Klar ist also nur, daß der Chip damit zu tun hat - Nokias kennen dieses Zwitscherproblem z.B. nicht, aber die haben auch keinen ENX sondern den GTX ...

     

    gruß

  6. Ich bin zwar nicht Xander, aber ich antworte trotzdem mal.

    Das Zwitschern tritt nur bei pay-Sendern auf, wenn die über nen emu entschlüsselt werden. Bei Kartenbetrieb gibt es das Problem nicht.

    Camd2 ist für FTA-Sender und auch für Kartenbetrieb ausgelegt. Da es hierbei kein Zwitscherproblem gibt, braucht man in diesem Fall auch keinen enx-Reset.

  7. Nach viel Lesen hab ich mal die Daten von "AWE Antennentechnik Weser-Ems"

    besorgt und ins cables.xml-Format übertragen.

    Dieser Provider ist z.B. in Oldenburg (Oldb) weit verbreitet...

    Die Daten sind von der Homepage des Providers mit Datum 1.Juni 2007

     

    ACHTUNG, UNGETESTET!

     

    	<cable name="AWE Antennentechnik Weser-Ems" satfeed="true" flags="9">
     <transponder frequency="129000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="136000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="143000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="150000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="157000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="164000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="171000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="178000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="185000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="192000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="199000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="206000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="213000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="220000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="227000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="234000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="241000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="248000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="255000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="262000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="269000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="276000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="283000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="290000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="297000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="306000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="314000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="322000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="330000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="338000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="346000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="354000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="362000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="370000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="378000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="386000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="394000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="402000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="410000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="418000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="426000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="434000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="442000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="450000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="458000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="466000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="474000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="482000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="490000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="498000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="506000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="514000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="538000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="546000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="554000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="562000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="570000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="610000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="754000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="786000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="794000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="826000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
     <transponder frequency="858000000" symbol_rate="6875000" fec_inner="9" modulation="6"/>
    </cable>

     

    Ich habe selbst kein Kabel, supporte aber einen Kumpel, der bisher noch nicht alle Sender gefunden hat. Sobald ich diese überarbeitete cables.xml bei ihm (hoffentlich erfolgreich) getestet habe, poste ich das Ergebnis hier.

     

    EDIT: Diese Einstellungen funktionieren leider nicht! Falls ich doch noch die richtigen Einstellungen finde, poste ich das dann hier...

  8. ja, seltsam. Ich dachte, ich hätte das gestern schon mal runtergeladen und da wäre was anderes drin gewesen... war ich wohl etwas konfus gestern... ;)

     

    Sehe gerade, daß da noch was bei meinem Linux-Ergebnis fehlt: NIC ist Realtek8139d auf 100HD

    ...nur der Vollstädigkeit halber...

  9. Diesmal NFS mit Linux (Debian 4.0), die Hardware ist (s.o.) noch dieselbe:

     

    8192, 8192

    8192+0 records in

    8192+0 records out

    real 1m 3.94s

    user 0m 0.22s

    sys 0m 12.20s

    8000

    8192+0 records in

    8192+0 records out

    real 1m 8.86s

    user 0m 0.18s

    sys 0m 8.15s

    7420

    192.168.1.12:/nfs on /mnt/record type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.1.12)

     

    16384, 16384

    8192+0 records in

    8192+0 records out

    real 1m 0.90s

    user 0m 0.22s

    sys 0m 11.96s

    8393

    8192+0 records in

    8192+0 records out

    real 1m 5.02s

    user 0m 0.19s

    sys 0m 9.16s

    7876

    192.168.1.12:/nfs on /mnt/record type nfs (rw,v3,rsize=16384,wsize=16384,soft,udp,nolock,addr=192.168.1.12)

     

    32768, 32768

    8192+0 records in

    8192+0 records out

    real 0m 59.72s

    user 0m 0.13s

    sys 0m 12.97s

    8533

    8192+0 records in

    8192+0 records out

    real 1m 1.47s

    user 0m 0.21s

    sys 0m 7.49s

    8393

    192.168.1.12:/nfs on /mnt/record type nfs (rw,v3,rsize=32768,wsize=32768,soft,udp,nolock,addr=192.168.1.12)

     

    /tmp # time cat /proc/kcore > /mnt/record/test1

    real 0m 57.15s

    user 0m 0.14s

    sys 0m 15.15s

    /tmp # time cat /mnt/record/test1 > /dev/null

    real 0m 59.58s

    user 0m 0.15s

    sys 0m 7.37s

     

     

    Ich glaub, damit kann ich erstmal zufrieden sein... :huh:

  10. Die geringfügig abweichenden Werte zu Deinem letzten Test (war mit dem 10Mb-Hub wenn ich mich recht erinnere) sind lediglich messtechnische Toleranzen.

    Könnte man meinen, da der Unterschied nur gering ist. Da ich das aber jedesmal mit mindestens 5 Durchläufen teste, halte ich es eindeutig für eine (sehr geringfügige) Verbesserung. Kcore-Test lag vorher z.B. immer über 1Min und jetzt konsequent darunter. -_-

    Das übertakten bringt aufnahmetechnisch nichts - so jedenfalls meine Beobachtungen.

    Wie gesagt, geringfügige Verbesserung. Andere (z.B. im Powerboard) wollen da schon deutlichere Verbesserungen erlebt haben (evt. mit höherer Übertaktung?) Aber aus diesem Grund zu übertakten rate ich natürlich niemandem! (never touch a running system):huh:

    Zu Chickens Test: Der rechnet "etwas großzügiger" als die von Worschter angepassten......wegen der Vergleichbarkeit der Werte, wollen wir hier nur Worschters Scripte oder den kcore-Test verwenden.

    Deshalb hab ich ja die Ergebnisse von seinem Script auch noch mit angegeben. Aber ich werd mich dran halten und die anderen in Zukunft weglassen... -_-

  11. Hat schon jemand den NFS-Performance-Unterschied zwischen normal getakteter und übertakteter DBox getestet?

     

    Habe meine mal auf 72Mhz (ohne zusätzliche Kühlung) getaktet und mein oben erwähntes Script durchlaufen lassen:

     

    /var/tuxbox/plugins # sh ./perf.sh

     

    Measuring NFS throughput...

    Mount options: udp, async, wsize=16384

    writing 64 MBytes...

    Success after 63 seconds

    Mount options: udp, async, rsize=16384

    reading 64 MBytes...

    Success after 64 seconds

     

    Mount options: tcp, async, wsize=16384

    writing 64 MBytes...

    Success after 78 seconds

    Mount options: tcp, async, rsize=16384

    reading 64 MBytes...

    Success after 78 seconds

     

    Mount options: udp, async, wsize=32768

    writing 64 MBytes...

    Success after 63 seconds

    Mount options: udp, async, rsize=32768

    reading 64 MBytes...

    Success after 62 seconds

     

    Mount options: tcp, async, wsize=32768

    writing 64 MBytes...

    Success after 73 seconds

    Mount options: tcp, async, rsize=32768

    reading 64 MBytes...

    Success after 77 seconds

     

    Results for write throughput:

    8.521 Mbit/s with udp,async,wsize=32768

    8.521 Mbit/s with udp,async,wsize=16384

    7.354 Mbit/s with tcp,async,wsize=32768

    6.882 Mbit/s with tcp,async,wsize=16384

     

    Results for read throughput:

    8.659 Mbit/s with udp,async,rsize=32768

    8.388 Mbit/s with udp,async,rsize=16384

    6.972 Mbit/s with tcp,async,rsize=32768

    6.882 Mbit/s with tcp,async,rsize=16384

     

     

    Und hier mal mit worschters ntest:

     

    /tmp # ./ntest 192.168.0.12 mpg /mnt/record/ 32768 32768

     

    32768, 32768

    8192+0 records in

    8192+0 records out

    real 1m 2.82s

    user 0m 0.25s

    sys 0m 10.02s

    8126

    8192+0 records in

    8192+0 records out

    real 1m 1.72s

    user 0m 0.24s

    sys 0m 6.89s

    8393

     

     

    Und kcore:

     

    /tmp # time cat /proc/kcore > /mnt/record/test1

    real 0m 59.84s

    user 0m 0.28s

    sys 0m 11.95s

    /tmp # time cat /mnt/record/test1 > /dev/null

    real 0m 59.20s

    user 0m 0.14s

    sys 0m 6.91s

     

     

    Scheint ein wenig schneller geworden zu sein...

  12. Habe ein Script gefunden, dass sich ins Image einbinden und dann über die FB starten lässt. Ergebnisse werden übersichtlich in ner Messagebox angezeit. Die Grösse des Testfiles kann im Script angepasst werden (je grösser, desto genauer), außerdem wird tcp und udp im selben Scriptdurchlauf getestet.

     

    Erst mit Editor (z.B. Proton) PC-IP, Name der Freigabe und dbox-Mountverzeichnis eingeben, dann per ftp nach /var/tuxbox/plugins , Rechte auf 755 und fertig. Also alles was man braucht, wenn man intensiv testen will...

     

    Falls Interesse besteht, kann das ja mal jemand (der das darf/kann ) als .rar an diesen post anhängen - schick ich ihm/ihr dann gerne zu...

     

    Das Ding kommt ursprünglich aus dem tuxbox-forum und ist nach dem Original von essu durch chicken modifiziert worden. -> h**p://tuxbox-forum.dreambox-fan.de/forum/viewtopic.php?p=282953

  13. Ich hoffe, dass das hier nicht schon mal irgendwo gepostet wurde.

     

    Für alle Sagem-Zwitscher-Zicken-Besitzer, die ucode 001A schon erfolglos getestet haben:

    Falls ucode001A bei FTA funzt, aber nicht bei den anderen Sendern, dann schaltet doch mal SPTS aus. So hab ich 001A zum Laufen bekommen. Beachtet auch, dass beim Streamen (-> beim Aufnehmen oder TV-schauen übers WebInterface yWeb) SPTS meist automatisch wieder eingeschaltet wird (ist glaub ich die Standardeinstellung)! In dem Fall gibts beim Aufnehmen nur schwarzes Bild ohne Ton :-) Also überall mal abschalten und testen.

    SPTS ist - wenn ich mich nicht irre - für die A/V-Synchronisation zuständig. Also können Aufnahmen ohne SPTS nen Versatz zwischen Audio und Video aufweisen - der aber evt. durch ein Bearbeitungsprogramm wieder ausgeglichen werden kann!? Ich denke da an PVAStrumento...

    Und dass AC3-Ton mit 001A nicht funktioniert, wurde hier ja bereits mehrfach gepostet.

    Hab noch keinen intensiven Test gemacht, habe aber das Gefühl, dass es bei meiner Zicke trotzdem gelegentlich zwitschert - aber vielleicht hilfts ja bei irgendjemandem...

    versuch macht kluch ;)

  14. So, mal ne Aktualisierung. Bisher habe ich über Crosslink-Kabel (NIC auf 10Mbit Half Duplex) gestreamt. Jetzt über nen Hub (100Mbit HalfDuplex oder Autonegotiation macht keinen Unterschied):

     

    Windows XP Professional mit SFU <--> RTL8139/810x FamilyFastEthernetNIC (100 Mbps HalfDuplex)Treiber: 5.663.1212.2006 <--> Hub D-Link DFE-908Dx <--> Sagem SAT 1xI AVIA600 KW-Image V2 Sept 06 beta3

     

     

    /tmp # ./ntest 192.168.1.12 mpg /mnt/record/ 32768 32768

     

    32768, 32768

    8192+0 records in

    8192+0 records out

    real 1m 2.71s

    user 0m 0.37s

    sys 0m 10.67s

    8126

    8192+0 records in

    8192+0 records out

    real 1m 1.38s

    user 0m 0.16s

    sys 0m 7.77s

    8258

     

    kcore-test:

     

    /var # time cat /proc/kcore > /mnt/record/test1

    real 1m 0.58s

    user 0m 0.15s

    sys 0m 12.70s

     

    /var # time cat /mnt/record/test1 > /dev/null

    real 0m 58.93s

    user 0m 0.20s

    sys 0m 7.62s

     

     

    Das sieht doch schon besser aus...

    ;)

  15. Na dann will ich auch mal:

     

    Windows XP Professional mit SFU (AMD1800+)<--> RTL8139/810x FamilyFastEthernetNIC (10Mbps HalfDuplex)Treiber: 5.663.1212.2006 <--> TwistedPair-Kabel <--> Sagem SAT 1xI AVIA600 KW-Image V2 Sept 06 beta3

     

    /tmp # ./ntest 192.168.1.12 mpg /mnt/record/ 32768 32768

     

    32768, 32768

    8192+0 records in

    8192+0 records out

    real 1m 11.08s

    user 0m 0.28s

    sys 0m 10.78s

    7211

     

    8192+0 records in

    8192+0 records out

    real 0m 59.06s

    user 0m 0.31s

    sys 0m 8.82s

    8533

     

     

    Kcore-Test:

     

    /var # time cat /proc/kcore > /mnt/record/test1

    real 1m 7.28s

    user 0m 0.18s

    sys 0m 13.21s

     

    /var # time cat /mnt/record/test1 > /dev/null

    real 0m 56.75s

    user 0m 0.20s

    sys 0m 8.21s

     

    Der Schreibwert ist echt grenzwertig. Solange ich nur einen Audiostream aufnehme funzt es (meistens).... ;)

  16. Hab versucht das Image nach tmp zu schieben, war aber wohl schon zu voll- image ist jetzt zu 96% voll und es läßt sich jetzt nichts mehr löschen- Image geplatzt!? :lol:

     

    Mit Hallenberg komm ich auch nicht weiter; Port 111 von der Datei system belegt kommt als Fehlermeldung - also kein Zugriff per Hallenberg möglich...

     

    Für den DBoxBootManager brauche ich ein Nullmodemkabel, oder? ;)

     

    Irgendwelche Tips? :lol:

×
×
  • Neu erstellen...