Nokia D-Box & ALLNET ALL0119W - Kaufempfehlung Switch?

[ricochez]

Hallo zusammen,

 

basierend auf dem Formenbeitrag "Netzwerk Geschwindigkeit" habe ich mich vor einiger Zeit zum Kauf einer ALLNET ALL0119W/CABLE (RTL8139) Netzwerkkarte entschieden und meine Nokia D2 Box ((Nokia 2xI, Juli 2009 V1 Image) per Crosslink-Kabel mit meinem PC ( XP Pro, SP2, SFU, XP NIC standard Treiber) verbunden. Bislang war ich damit sehr zufrieden, da in dieser Konstellation Aufnahme und Wiedergabe von ARD und ZDF Material ( inkl. 5.1 Sound ) kein Problem darstellten.

 

Da ich zwischenzeitlich eine Dreambox 500C im meinem heimischen Netzwerk in Betrieb genommen habe, diese im gleichen LAN Segment wie die D-Box stehen soll und ich meinen PC nicht mit einer weiteren Netzwerkkarte ausstatten möchte, suche ich nun den passenden 5 oder 8 Port Switch, der den reibungslosen Betrieb zwischen D-Box und meinem PC unter Verwendung der o.g. ALLNET Netzwerkkarte gewährleistet. Nachdem ich bereits verschiedene Switch Modelle vergeblich ausprobiert habe, bin ich gegenwärtig beim LevelOne 5 Port FSW-0508TX gelandet. Dieser funktioniert zwar in Verbindung mit den UM und S*y Programmen reibungslos, versagt aber bei ARD und ZDF Aufnahmen bzw. deren Wiedergabe seinen Dienst. Da ich die die Hoffnung hege, dass jemand von euch der gleichen Kaufempfehlung in o.g. Beitrag gefolgt ist, würde ich mich über ein Feedback über eure gemachten Erfahrungen mit der ALLNET Netzwerkkarte und dem von euch eingesetzten Switch sehr freuen.

 

 

Gruss

Ricochez

[merkwuerden]

Ich hab hier einen Linksys EZXS88W im Einsatz. Kommt sowohl mit meinen Onboard-NICs (Marvell Yukon sowie der vom nForce4-Chipsatz) als auch der RTL8139C (nicht von Allnet, ist irgendein noname-Dings) im Zweitrechner prima klar. Treiber werden die der Chipsatz-Hersteller verwendet, nicht die integrierten Windows-Treiber. Bedingung ist lediglich, dass die NICs fest auf 100MBit HalfDuplex eingestellt werden, sonst bricht die Richtung PC -> dBox2 komplett zusammen, wenn man die für vernünftiges Schreiben/Lesen benötigte r-/wsize von 32768 mountet.

 

Bei XP wirst Du u.U. noch auf einen anderen NFS-Server umsteigen müssen, um das Maximum herauszuholen, da SFU unter XP schreibenderweise (wsize) lediglich maximal 8192 unterstützt. Und da kann es bei ARD/ZDF dann schon etwas knapper zugehen, vor allem wenn man nicht nur den Standardton allein aufnehmen will.

 

Damit Du mal im Vergleich siehst, wie das bei mir ausschaut (Windows Server 2003):

 

nVidia nForce4                Marvell Yukon                 RTL8139C
Microsoft SFU                 Microsoft SFU                 Hanewin NFS-Server

rsize/wsize  8192             rsize/wsize  8192             rsize/wsize  8192
Schreiben    8456 kbits/s     Schreiben    8456 kbits/s     Schreiben    8594 kbits/s
Lesen        7384 kbits/s     Lesen        7281 kbits/s     Lesen        7384 kbits/s

rsize/wsize 16384             rsize/wsize 16384             rsize/wsize 16384
Schreiben    8886 kbits/s     Schreiben    8886 kbits/s     Schreiben    8886 kbits/s
Lesen        7598 kbits/s     Lesen        7825 kbits/s     Lesen        7943 kbits/s

rsize/wsize 32768             rsize/wsize 32768             rsize/wsize 32768
Schreiben    8886 kbits/s     Schreiben    9039 kbits/s     Schreiben    8962 kbits/s
Lesen        8065 kbits/s     Lesen        8192 kbits/s     Lesen        8192 kbits/s

Sagt mein NFS-Speedtest, basierend auf Worschters ntest2.

Warum bei mir da lesenderweise nur knapp 8200 gehen, ist mir zwar leicht rätselhaft, ich kann aber trotzdem Aufnahmen von ARD/ZDF ohne Zwischenpuffern abspielen.

 

Was Du unter XP mit SFU erwarten kannst, sind die Werte Schreiben mit 8192 / Lesen mit 32768.

[ricochez]

Hallo Merkwuerden,

 

vielen Dank für Dein Feedback. Habe selbst verschiedene Tests (NIC Mode, mit dem netzwerk speed Test Skript durchgeführt und habe die NIC letztenendes fest auf 100MBit Halfduplex eingestellt, da in dieser Konfiguration die beste Performance für Wiedergabe und Direktaufnahme errreicht werden konnte.

 

/tmp # ./netztest 192.168.0.1 /movies /mnt/record

4096, 4096
8192+0 records in
8192+0 records out
real    1m 23.11s
user    0m 0.36s
sys     0m 17.02s
6168
8192+0 records in
8192+0 records out
real    1m 19.83s
user    0m 0.29s
sys     0m 14.82s
6400
192.168.0.1:/movies on /mnt/record type nfs (rw,noatime,v3,rsize=4096,wsize=4096,soft,udp,nolock,addr=192.168.0.1)

8192, 8192
8192+0 records in
8192+0 records out
real    1m 10.27s
user    0m 0.27s
sys     0m 15.69s
7211
8192+0 records in
8192+0 records out
real    1m 10.65s
user    0m 0.19s
sys     0m 11.57s
7211
192.168.0.1:/movies on /mnt/record type nfs (rw,noatime,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.1)

16384, 16384
8192+0 records in
8192+0 records out
real    1m 8.67s
user    0m 0.34s
sys     0m 15.75s
7420
8192+0 records in
8192+0 records out
real    1m 7.10s
user    0m 0.26s
sys     0m 12.65s
7641
192.168.0.1:/movies on /mnt/record type nfs (rw,noatime,v3,rsize=16384,wsize=8192,soft,udp,nolock,addr=192.168.0.1)

32768, 32768
8192+0 records in
8192+0 records out
real    1m 8.18s
user    0m 0.27s
sys     0m 15.87s
7529
8192+0 records in
8192+0 records out
real    1m 3.14s
user    0m 0.23s
sys     0m 11.46s
8000
192.168.0.1:/movies on /mnt/record type nfs (rw,noatime,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.0.1)

 

Interessanterweise erreiche ich jetzt den höchsten Datendurchsatz, wenn ich UDP als Mountoption verwende. Als ich D-Box und PC via Crosslink-Kabel mit der gleichen NIC verbunden hatte, habe ich die besten Ergebnisse mit der TCP Mountoption erreicht.

Naja, werde jetzt mal den von Dir genannten Hanewin NFS Server in Kombination mit den Chipsatz-Hersteller NIC Treibers ausprobieren und sehen, ob das mein Problem löst. Sollte dieses der Fall sein, so bin ich gerne bereit die 19,- Euro für die Software auf den Tisch zu legen. Anderenfalls werde ich den von Dir genannten Linksys EZXS88W Switch testweise shoppen und sehen, ob dieses mein Problem endgültig löst.

Alternativ werde ich den Full-Duplex Umbau meiner D-Box in Betracht ziehen. Kann diesbezüglich jemand seine damit gemachten Erfahrungen zum Besten geben?

[merkwuerden]

Nur zu Deiner Information: der FullDuplex-Umbau der Box nützt Dich nur dann etwas, wenn Du entweder für die Box eine separate NIC zur Verfügung hast, die Du dann in den 10 FullDuplex Mode zwingen musst, oder Du musst Dir einen managebaren Switch anschaffen, dessen Ports sich einzeln konfigurieren lassen, und den Du am Port der dBox2 auch wieder auf 10 Full zwingen musst. So ein managebarer Switch geht ab ca. 80 bis 90 Euro aufwärts los, nach oben sind kaum Grenzen gesetzt.

 

Mit einem normalen Switch wird nichts, weil die dBox2 sich mangels Fähigkeit zu Autonegotiation nach außen generell mit 10 HalfDuplex meldet, ein normaler Switch stellt sich darauf hin auf den falschen Modus ein, damit geht der FullDuplex-Umbau komplett nach hinten los, Du verschlechterst die Übertragungsgeschwindigkeit, statt etwas gut zu machen. Im Zweifelsfall geht dann netzwerkmäßig mit der Box überhaupt nichts mehr.

 

Mir persönlich wäre es das Geld für einen managebaren Switch nicht wert, zumal man mit normalen Mitteln (ordentlicher NFS-Server und Switch) auch ziemlich die Grenzen des für die dBox2 Machbaren erreichen kann.

 

Um einen anderen NFS-Server wirst Du jedenfalls nicht herumkommen, wenn Du ARD/ZDF störungsfrei aufnehmen willst. Allein der FullDuplex-Umbau dürfte dazu vermutlich nicht reichen.

 

Was Du als NFS-Server auch mal probieren kannst, wäre der kostenlose FreeNFS. Thread dazu. Kann rsize/wsize 32768 (mehr kann die Box nicht) und ist sonst in den Geschwindigkeitswerten mit Microsoft SFU und Hanewin gleich. Ist allerdings nur recht eingeschränkt konfigurierbar, Du kannst nur ein einziges Hauptverzeichnis als NFS-root definieren, wo dann alles Übrige drin als Unterverzeichnisse liegen muss. Verzeichnisse auf mehreren Festplatten geht damit nicht - zumindest nicht so einfach.

[ricochez]

Ist wirklich ein Managed Switch für den Full Duplex Mode erforderlich?

 

Bin eigentlich davon ausgegangen, dass das auch mit einem einfachen Switch möglich wäre, da sich in dem von mir verwendete Keywelt Image (Juli 2009 V1 Image) unter Settings ein entsprechender Full Duplex Mode Schalter befindet und dieser die D-Box NIC in den besagten Modus zwingen sollte. Darüber hinaus kann ich auch nicht nachvollziehen, wieso ich für die Nutzung dieser Konstellation eine explizite NIC auf PC Seite benötige. Die vorhandene NIC kann ja in jeden Duplex Modus Modus versetzt werden und hängt ja auch an einem Switch und keinem einfachen Hub. Somit sollten keine Störeinflüsse durch Drittgeräte zu erwarten sein, oder ?

[merkwuerden]

Ist wirklich ein Managed Switch für den Full Duplex Mode erforderlich?

Ja! Wie ich Dir schon geschrieben habe: die Schnittstelle der dBox2 meldet nach außen generell Half Duplex, und zwar unabhängig davon, ob man sie intern per Software zu Full Duplex zwingt oder nicht. Die Hardware kann sich nicht anders als mit Half Duplex melden, und darauf stellt sich eben ein normaler Switch dann automatisch ein. Was dann massive Kollisionen und Datenpaketverluste zwischen dBox und Switch nach sich zieht, die die Netzwerkkommunikation in den Keller drückt bzw. sogar gänzlich unmöglich machen kann.

 

Bin eigentlich davon ausgegangen, dass das auch mit einem einfachen Switch möglich wäre, da sich in dem von mir verwendete Keywelt Image (Juli 2009 V1 Image) unter Settings ein entsprechender Full Duplex Mode Schalter befindet und dieser die D-Box NIC in den besagten Modus zwingen sollte.

Das tut nichts zur Sache. Die Schnittstelle kann sich nach außen nur mit Half Duplex melden, lediglich intern wird sie zu Full Duplex gezwungen. Die Gegenstelle weiß davon allerdings nichts und bekommt das "freiwillig" auch nicht zu erfahren.

 

Darüber hinaus kann ich auch nicht nachvollziehen, wieso ich für die Nutzung dieser Konstellation eine explizite NIC auf PC Seite benötige.

Die benötigst Du, wenn Du auf einen managebaren Switch verzichten willst. Entweder managebarer Switch (oder spezieller konfigurierbarer Hub, Switch wäre aber deutlich zu bevorzugen) oder separate NIC, an der die dBox2 dann direkt per Crossover hängen muß. Andere Möglichkeiten sind ausgeschlossen, weil das nicht funktionieren würde.

 

Die vorhandene NIC kann ja in jeden Duplex Modus Modus versetzt werden und hängt ja auch an einem Switch und keinem einfachen Hub. Somit sollten keine Störeinflüsse durch Drittgeräte zu erwarten sein, oder ?

Den Switch an seinen anderen Anschlüssen interessiert es nicht, ob die NIC des PC auf Half oder Full Duplex gestellt wird. Die dBox2 meldet ihm Half Duplex, und darauf stellt er seinen zuständigen Port automatisch ein. Und das ist der springende Punkt: die Box würde durch die Modifikation und den erzwungenen Software-Modus auf Full Duplex arbeiten, dem Switch für seinen Port aber trotzdem nur Half Duplex melden, und das geht eben schief. Daher managebarer Switch zwingend notwendig, damit Du den Port des Switches, an dem die dBox2 hängt, manuell auf 10 Full Duplex zwingen kannst.

 

Kannst das Prinzip ja gerne mal mit zwei PCs ausprobieren, die Du direkt per Crossover verbindest. Einen PC stellst Du auf 10 Half Duplex, den anderen auf 10 Full Duplex. Ergebnis: zwischen den Kisten geht wenig bis überhaupt nichts, weil die Übertragungsmodi nicht zusammenpassen.

[ricochez]

Vielen Dank für Deine sehr detailierte Antwort. Werde zunächst den von Dir genannten NFS Server testen und sehen, ob dieses mein Problem löst. Sollte dieses nicht der Fall sein, werde ich zunächst nochmals verschiedene NIC Treiber ausprobieren. Wenn das alles nicht den gewünschten Erfolg bringt, werde ich mich mal nach einen preiswerten managed Switch umsehen und den damit verbundenen Full Duplex Mode Umbau meiner D-Box in Angriff nehmen. Die Ergebnisse meiner Tests werde ich diesem Thread in jedem Fall veröffentlichen. Nochmals vielen Dank für Deine Mithilfe.

[ricochez]

Leider habe ich jetzt die Zeit die Zeit gefunden, den von Dir genannten HaneWin NFS Server einer genauen Prüfung zu unterziehen.

Ich habe diesen parallel zu meinem SFU NFS Server installiert, da ich nicht den Drang verspürte, bei einem negativen Testergebnis den alten NFS Server erneut installieren zu müssen.

Damit dieses Unterfangen reibungslos über die Bühne gehen konnte, habe ich vor Installation des zu testenden NFS Servers die nachfolgenden Dienste des bereits vorhandenen NFS Servers gestoppt:

 

NFS Server

User Name Mapping

 

Für die Performance Messung habe ich auf das von chickens

Weiterentwickelte NFS Speed Test Skript (http://wiki.dbox2-tuning.net/wiki/index.php/Neutrino:Skripte#chickens_erweiterter_NFS_speed_test zurückgegriffen und dabei die

empfohlenen HaneWIN NFS Server Settings aus dem Keywelt Thread http://www.keywelt-board.com/index.php?showtopic=141137 verwendet:

 

Nachfolgend die Ergebnisse

 

Results for write throughput:

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

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

8.012 Mbit/s with udp,async,wsize=8192

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

6.547 Mbit/s with udp,async,wsize=4096

6.391 Mbit/s with tcp,async,wsize=8192

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

5.368 Mbit/s with tcp,async,wsize=4096

 

Results for read throughput:

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

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

7.669 Mbit/s with udp,async,rsize=8192

7.456 Mbit/s with tcp,async,rsize=8192

7.354 Mbit/s with tcp,async,rsize=4096

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

6.795 Mbit/s with udp,async,rsize=4096

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

 

 

Wie man sehen kann, hat der Umstieg auf den HaneWIN NFS Server eine ganze Menge gebracht und ich werde definitiv die 19,- Euro für die Software investieren, da Aufnahmen und Wiedergabe von Filmen nunmehr problemlos möglich sind. Wie auch bei Dir fällt bei mir die Schreib-Performance besser aus als die Lese-Performance. Diesbezüglich habe ich jedoch im Netz den Tip gefunden, dass die UDP Lese-Performance dadurch verbessert werden kann, den HaneWin NFS Server Parameter „Anzahl der UDP NFS Server Threads“ von 4 (Default Value) auf 32 zu erhöhen und den NFS Server anschließend durchzustarten. Dieser Test steht noch aus, die Ergebnisse werde ich aber in jeden Falle auch noch nachreichen.

[merkwuerden]

Na siehste, geht doch.

 

Mit den Schreibwerten sollten ARD, ZDF und Konsorten selbst mit allen drei Tonspuren keine Probleme beim Aufnehmen geben. Damit kannste SFU dann eigentlich entsorgen.

 

dass die UDP Lese-Performance dadurch verbessert werden kann, den HaneWin NFS Server Parameter „Anzahl der UDP NFS Server Threads“ von 4 (Default Value) auf 32 zu erhöhen und den NFS Server anschließend durchzustarten. Dieser Test steht noch aus, die Ergebnisse werde ich aber in jeden Falle auch noch nachreichen.

Würde mich auf jeden Fall interessieren, ob es was bringt.

[ricochez]

Hier nun die Ergebnisse mit dem angepassen NFS Server Parameter

 

Results for write throughput:

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

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

8.012 Mbit/s with udp,async,wsize=8192

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

6.547 Mbit/s with udp,async,wsize=4096

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

6.316 Mbit/s with tcp,async,wsize=8192

5.592 Mbit/s with tcp,async,wsize=4096

 

Results for read throughput:

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

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

7.669 Mbit/s with udp,async,rsize=8192

7.456 Mbit/s with tcp,async,rsize=8192

7.255 Mbit/s with tcp,async,rsize=4096

6.795 Mbit/s with udp,async,rsize=4096

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

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

 

Wie man unschwer erkennen kann, ist eine konstante Verbesserung der UDP Lese-Performance durch die besagte Parameteränderung nicht wirklich erkennbar. Bei einer rsize=32768 ist zwar eine minimale Verbesserung erkennbar, allerdingt kann diese auch andere Ursachen haben. Vielleicht wäre es vorteilhaft, wenn Du diesen Test zum Vergleich ebenfalls durchführst.

 

Ach ja, gefunden habe ich den Tip bezüglich der Parameteränderung hier

[merkwuerden]

Wie man unschwer erkennen kann, ist eine konstante Verbesserung der UDP Lese-Performance durch die besagte Parameteränderung nicht wirklich erkennbar. Bei einer rsize=32768 ist zwar eine minimale Verbesserung erkennbar, allerdingt kann diese auch andere Ursachen haben.

Hat sie mit Sicherheit auch: liegt an der Größe der Test-Datei. Bei 64MB können zwischen einzelnen Testläufen durchaus Abweichungen über 250kbit/s auftreten, das liegt an der Messungenauigkeit mit der 64MB-Datei. Nimmst Du die Datei noch kleiner (32MB), werden die Differenzen noch größer.

 

Unter 64MB brauchst Du nach meiner eigenen Erfahrung überhaupt nicht erst anfangen, der Test wird unbrauchbar. Die im Tuxbox-Wiki genannten 8MB machen den Test komplett zum Witz, die Ergebnisse damit sind absolut lächerlich und nicht zu brauchen, da gibt es zwischen verschiedenen Testläufen teils Abweichungen im Mbit-Bereich.

 

Meine Empfehlung: mache den Test mit 192 oder 256MB Filesize. Je größer die Testdatei, umso genauer wird das Ergebnis. Dauert allerdings dann auch entsprechend.

 

Das Chicken-Script ist dafür übrigens ungeeignet und zerrt den Testlauf nur sinnlos in die Länge, weil man sich den ganzen TCP-Schnurz sparen kann, damit wäre ARD, ZDF und Konsorten sowieso nie streambar. Mehr als Pi mal Daumen 7Mbit/s gehen damit nicht, das ist für Sender hoher Bitraten keinesfalls ausreichend.

 

Blocksizes unter 8k kann man sich auch schenken. Wenn der NFS-Server 32k read/write unterstützt, reicht es normalerweise, damit allein zu testen. Voraussetzung ist natürlich, dass das Netzwerk (Switch) mitspielt. Und die NIC des PC dann fest auf Half Duplex läuft.

Den FD-Mod der dBox lasse ich hier bewusst aus dem Spiel und gehe davon aus, dass die Box nicht umgebaut wurde. Braucht man meiner Meinung auch nicht, weil der Vorteil nur minimal wäre.

 

Ach ja, gefunden habe ich den Tip bezüglich der Parameteränderung hier

Kannst Du gleich wieder vergessen, was dort geschrieben wurde. Der User betreibt USB-Festplatten, von denen er streamen will, und genau das ist die Schwachstelle in seinem System.

 

Kurz erklärt:

Auch wenn USB 2.0 theoretisch 480Mbit/s (60MB/s) packen soll, lässt sich diese Geschwindigkeit in der Praxis nie erreichen. Gängige Werte sind so 20 bis 25MB/s, wenn es sehr gut läuft vielleicht 30 bis 35MB/s. Hab ich selber in der Praxis aber noch nie erlebt, im Schnitt sind's bei mir um die 22MB/s. Wenn das Maximale gehen soll, muss die USB-Platte allein an einem Root-Hub hängen, die Bandbreitenreservierung unter Windows abgeschaltet sein und die USB-Platte auch wirklich das hergeben, was die Schnittstelle mitmachen würde (Certified USB Hi-Speed-Logo). Haben die wenigsten Platten. Ohne das "Certified" verstehen die Dinger zwar USB 2.0, mit welcher tatsächlichen Geschwindigkeit steht aber dabei in den Sternen. Und keiner kann sich drüber aufregen, das ist der Trick der Sache. Meist scheitert es an schrottigen Controllern in den Plattengehäusen, die HDDs ansich können heutzutage problemlos 60 bis 70MB/s und mehr linear lesen und schreiben.

 

Wenn jetzt der Transfer via USB schon nicht viel wert ist, bremst das nachfolgend auch den NFS-Server aus. Und da hilft auch nicht, 'zigweise Server-Threads zu starten, damit wird es unterm Strich auch nicht schneller.

 

Ich hab übrigens in meinem lokalen Netzwerk Tests gefahren, die beiden PCs sind auch via NFS vernetzt. Auf der kleinen Kiste läuft der Hanewin mit seinen normalen 4 Threads und 32k Transfersize. Über mein 100Mbit Half-Duplex-Netz sind da problemlos 80 bis 85MB/s drin, der Server ist also sehr wohl schnell genug. Im Gegensatz zur normalen Windows-Freigabe (CIFS), da gehen kaum mehr als 65MB/s.

 

Für die dBox2 also mehr als ausreichend, was der Hanewin-NFS per UDP liefern kann, der Knackpunkt wird sein, dass die Box nicht mehr als die 8.3MB/s abnehmen kann. Hier könnte vielleich der FD-Umbau samt managebarem Switch noch was bringen, denn die Richtung vom Server zur Box ist da irgendwo die Schwachstelle (sieht man am Switch an der Collision-Anzeige). Für die Richtung Box -> Server dagegen dürfte das nichts merkbar verbessern, da sehe ich die Collision-Anzeige nur sehr selten mal blinken. Und wegen vielleicht 300, 400kbit/s die Box umbauen und Geld für einen managebaren Switch ausgeben ist die Sache am Ende denke ich doch nicht wert.

 

Mache einfach mal den Praxistest und nehme ARD oder ZDF mal auf, Sport-Live-Übertragungen sind dafür gut geeignet. Auch Phoenix und Arte kannst Du versuchen. Wenn sich die Aufnahmen einwandfrei abspielen lassen, ist alles im Lot, dann würde ich mir keine Gedanken weiter machen. Bei mir reichen selbst die laut Test 8192kbit/s aus, hatte da noch kein Zwischenpuffern im Stream, das mir aufgefallen wäre.

[ricochez]

Habe den Praxistest mit Hanewin NFS durchgeführt und muss sagen, dass Aufnahmen per D-Box von ARD und ZDF überhaupt kein Problem mehr darstellen.

 

Trotzdem werde ich wohl vorerst bei SFU bleiben müssen, da die Dreambox nicht mit dem Hanewin NFS Server zurechkommt

 

Ursächlich für dieses Problem ist ein im Sourecode von Gemini E1 befindlicher Bug (, welcher bei der Aufnahme die .ts Datei mit einer 555 umask (richtig wäre 655) versieht. Dieses hat zur Folge, dass bei einer Aufnahme lediglich eine 0 Byte große Datei geschrieben wird. Der SFU Server nimmt es mit Berechtigungen wohl nicht so genau und lässt das Schreiben auf den NFS Share zu, während der Hanewin NFS Server diese nicht zulässt. Wie ich in anderen Threads gelesen habe, steht der Hanewin Server nicht alleine dar. Auch der FreeNFS Server scheint von diesem Problem betroffen zu sein.

 

Da das IHAD Team sich nunmehr wohl ausschließlich der Weiterentwicklung von E2 widmet (wo besagter Bug auch gefixt ist), wird dieser im aktuellen E1 Image (Gemini 4.7) befindliche Fehler auch nicht mehr behoben werden.

 

Die einzige Möglichkeit, dieses Problem zu umschiffen, besteht aus folgenden Möglichkeiten:

 

1. Auf E2 Image ausweichen

2. E1 Image selbst kompilieren

3. E1 Image eines anderen Teams verwenden, welches aktuellere Sourcen verwendet.

 

Da ich nicht den Drang verspüre, ein Image selbst zu kompilieren und ich mich auch nicht mit der Inkompatibilität eines E2 Images mit der D-Box beschäftigen möchte, werde ich mich nunmehr nach einem E1 Image eines anderen Teams umsehen. Wenn jemand ein E1 Image eines anderen Teams für eine DM600 empfehlen kann, das dieses Problem nicht kennt, bin ich für jeden Tip dankbar.

 

In jedem Fall möchte ich mich bei Dir merkwuerden für Deine Hilfe und sehr detailierten Ausführungen bedanken.

 

 

Gruss

Rico

[ricochez]

kurzes Update:

Habe zu Testzwecken mal das aktuelle Pli Jade3 Image auf die Dreambox gespielt. Leider ist auch in diesem Image der besagte Bug vorhanden, so dass ich weiterhin nicht auf den Hanewin NFS Server zurückgreifen kann. Sollte ich ein fertiges Image finden, dass dieses Bug nicht beinhaltet, so werde ich euch informieren.