cy_coe

per Online-Update, wenn die box am Internet hängt. blaue Taste > Keywelt Menü > System Menü > Image Aktualisierung > Image über Interet updaten ...

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

@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.).

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!

Der wird immer benutzt -soweit ich weiß. Ist ja schließlich eine der Hauptkomponenten der box. ä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` 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ß

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.

Nein!

schreibgeschützt ist das nur im squashfs-image. Im jffs-image kannst Du - glaub ich - alles beschreiben....

Habe bei Powerboard was gefunden, das vllt bei einigen Zwitscherboxen helfen könnte: www.pb-powerboard.com/board/index.php?showtopic=43013&hl=enx Falls das jemand testet, dann bitte hier das Ergebnis posten.

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

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

Wo finde ich die aktuellste Auflistung der ntest Ergebnisse? War ne Excel-Tabelle, wenn ich mich richtig erinnere...

Hallo! Habe ne Honda NTV 650 Bj.88 und brauche ne Rückleuchte dafür. Vielleicht kann mir da einer weiterhelfen? Das Ding ist mir im Handel einfach zu teuer bzw. kanns mir halt nicht leisten

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

Jetzt hast mich aber echt neugierig gemacht, will aber nur für den Versuch nicht extra flashen. klär das doch (bitte, bitte) mal auf... hat das ne bessere Performance?

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

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

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

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

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

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

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

Hallo! Habe ein uraltes Kalibo von 2004 drauf. Möchte das aktuelle KW-Beta-Image flashen. Hab momentan 85% belegt. Frage: Kann ich das zu flashende Image nach tmp uppen und manuell flashen, oder besser per Hallenberg? Danke