Altes Problem - Ruckeln beim abspielen

Digital Recording
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Altes Problem - Ruckeln beim abspielen

Beitrag von klez »

Hi.
Ich weiss, daß solche Themen schon 100 mal durchgekaut wurden, aber trotzdem habe ich diesbezüglich ein paar fragen.

Mein Netzwerk:
Debian Linux Server und Internet hängen an einem Router mit eingebautem 100 Mbit Switch (1). Von dort aus geht ein Uplink zu einem 2ten 100 Mbit Switch(2) an dem die Dbox und ein paar Rechner hängen.

Der Switch Nr.2 war ein von einem Freund ausgeliehener...
Alle Aufnahmen und Wiedergaben funktionierten über ein NFS Share völlig Problemlos. Keine abbrüche oder Ruckler.

Dann musste ich den Switch meinem Freund zurückgeben und ich kaufte mir einen eigenen neuen (100Mbit). Aufnehmen klappt mit dem Ding ebenfalls Problemlos, aber die Wiedergaben Ruckeln, bis sie irgendwann völlig stehen.
Das Interessante daran ist das Aufnahmen, die ich früher mit dem ausgeliehenen Switch gemacht habe Problemlos wiedergegeben werden. Nur die "neueren" nicht. Spiele ich die "neueren" am PC ab, laufen sie auch Problemlos, nur über die Dbox halt nicht mehr.
Tausche ich meinen neuen Switch gegen einen alten 10Mbit Hub, laufen sie auch auf der Dbox wieder ohne Probleme.

Jetzt meine Frage. Woran liegt das ?
Man könnte sagen es liegt am Switch... Is klar.
Ich verstehe aber nicht warum.
Der Switch müsste die Daten in jedem Fall schneller liefern können, als mein uralt Hub. Abgesehen davon ging es mit dem ausgeliehenen Switch ja auch. Desweiteren verstehe ich die Messergebnisse mit diesem einen, hier im Forum genannten, Script nicht. Mehr als 1MB/s gehen ohnehin nicht über die 10Mbit der Dbox. Wie können dann Ergebnisse von 5-8 MB/s erreicht werden ?

rsize=32768 brachte ebenfalls keinen Erfolg. Im Gegenteil. Es wurde fast noch schlimmer. Wenn jemand ein paar Tips für mich hat, wäre ich sehr dankbar.
Spooky
Einsteiger
Einsteiger
Beiträge: 338
Registriert: Sonntag 24. Februar 2002, 10:43

Beitrag von Spooky »

@klez

Probiere mal rsize=4096,wsize=32768 für das Mounten!

Mit den MB Angaben ist die Ursache die "Schlamperei" der verschiedenen Poster hier im Forum. Die einen meinen damit Mbit und die anderen MByte.

Spooky
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Beitrag von klez »

Wow, es kann so einfach sein...
rsize=4096 brachte bereits den erhofften Erfolg. VIELEN DANK :)

Jetzt aber noch eine Frage aus Neugier, da ich mich für sowas immer Interessiere. Warum läufts besser, wenn der Lesepuffer verkleinert wird ?
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Spooky hat geschrieben: Mit den MB Angaben ist die Ursache die "Schlamperei" der verschiedenen Poster hier im Forum. Die einen meinen damit Mbit und die anderen MByte.
klez redet imo von den Ausgaben des Essu-Skripts...die sind nicht 'schlampig'. rsize=4096 bringt bei SFU oder bei der WL-HDD schlechtere Werte fuers lesen...

@klez
was waren das fuer Switches..Hersteller/Type ? Na klar liegt das nur an den Switches...Du hast nichts am NFS-Server und an der Box geaendert...was soll's dann sonst sein?
Die Switches haben zB. unterschiedliche Buffergroessen/Latenzzeiten/????...die NIC Deines PC's steht _fest_ auf 100 full Duplex und Dbox/PC haengen gemeinsam am gleichen Switch oder?
Spooky
Einsteiger
Einsteiger
Beiträge: 338
Registriert: Sonntag 24. Februar 2002, 10:43

Beitrag von Spooky »

@klez,

es ist nur eine Vermutung von mir, nachdem ich auf dem NSLU2 die selben Probleme hatte. Das 10Mbit Interface der dbox ist der Flaschenhals und der Server kann die Daten schneller liefern als die dbox sie abnimmt. Durch den "Stau" fängt der dazwischenliegende Switch nach einem Timeout an, die "überflüssigen" Pakete zu verwerfen. Durch die Nutzung von rsize=32768 ist der Geschwindigkeitsunterschied noch größer und auf einen Schlag sind nicht 4K sondern 32K Daten weg. Durch das UDP Protokoll merkt der Server nichts davon und schickt fleissig die nächsten Pakete hinterher. Parallel dazu fängt die dbox2 an sich zu "verschlucken" und bleibt eventuell sogar hängen. Man kann stattdessen auch TCP verwenden. Mit TCP wird immer eine Bestätigung über den Empfang der Pakete abgeprüft und im Bedarfsfall neu verschickt. Damit ist aber auch der Platz für die Nutzdaten (Videostream) im Netz geringer und die Geschwindigkeit sackt unter die Werte einer funktionierenden UDP-Verbindung ab.

Spooky
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Beitrag von klez »

@Spooky:
Danke für die Erklärung. Klingt einleuchtend. Hätte ich fast selbst drauf kommen können, aber die Vorlesung "Netzwerke" liegt schon etwas zurück :)

@Petgun:
Schon klar, daß es am Switch lag/liegt. War ja auch das einzige was sich in meiner Konfiguration geändert hatte. Der ausgeliehene Switch war ein etwas älterer 5-Port Mini-Switch. Firma... ka. Stand nur Mini-Switch drauf.

Mein neuer ist ein ultra-billig 8-Port Switch von Fast. Das ganze Netzwerk arbeitet mit Full Auto-Negotiation und somit (überprüft) mit 100Mbit - Full Duplex. Bis auf die Dbox natürlich... Die kann ja nicht mehr als 10Mbit - Half.
Und Ja. PCs (bis auf den Server) und Dbox hängen an dem Switch von Fast.
Spooky
Einsteiger
Einsteiger
Beiträge: 338
Registriert: Sonntag 24. Februar 2002, 10:43

Beitrag von Spooky »

@petgun

Wenn einer MB schreibt und damit Mbit meint ist das nun mal irreführend und nicht korrekt. MB steht (außer für Spielwaren :) ) auch für MByte und nicht Mbit. Man beachte die GROß/klein-schreibung ! Wenn jemand im Forum einen Thread eröffnen würde mit "p. script für W-H", dann kannst Du als "petgun" gemeint sein, oder auch irgend ein x-beliebiger nutzer der ebenfalls im Forum angemeldet ist.

Der eine liest daraus:
"petguns Script fürs WL-HDD" und ein anderer "pauls script für die WinterHilfe"

Denk mal darüber nach ;)

Spooky
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

...ich finde ja nur gut, dass hier klar raus kommt, dass es ausschliesslich am Switch liegt der einfach langsamer ist und dass die Kastrierung der rsize Groesse nur ein Wuergaround fuer einen lahmen Switch/schlechtes Netzwerk ist.
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Spooky hat geschrieben:@petgun
Denk mal darüber nach ;)
ok, ich bin schlampig und habe meine Ruhe....trotzdem hat klez auf das Script von Essu angespielt und das ist _nicht_ schlampig.
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Beitrag von klez »

trotzdem hat klez auf das Script von Essu angespielt und das ist _nicht_ schlampig.
Habe ich auch nie behauptet. Spooky übrigens auch nicht, da sich seine Aussage auf die Poster gewisser Threads bezogen hat.

Wegen dem Netzwerk:
Sehe ich ehrlichgesagt anders. Selbst das langsamste 100Mbit Netzwerk ist immernoch schneller, als die Dbox die Daten annehmen könnte. Von daher spielt das schonmal keine Rolle. Desweiteren hatte ich auch schonmal einen 3Com Switch hier und der war nach Geschwindigkeitsmessung auch nur sehr geringfügig (paar KB/s) schneller. Ob sich dafür der Exorbitante Aufpreis für einen 3Com Switch rechnet, muß jeder für sich selbst entscheiden.
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,
klez hat geschrieben:
trotzdem hat klez auf das Script von Essu angespielt und das ist _nicht_ schlampig.
Habe ich auch nie behauptet. Spooky übrigens auch nicht, da sich seine Aussage auf die Poster gewisser Threads bezogen hat.
dann habe ich das wohl total flasch verstanden:
..Desweiteren verstehe ich die Messergebnisse mit diesem einen, hier im Forum genannten, Script nicht. Mehr als 1MB/s gehen ohnehin...
..iss mir aber auch ziemlich egal.
Wegen dem Netzwerk:
Sehe ich ehrlichgesagt anders. Selbst das langsamste 100Mbit Netzwerk ist immernoch schneller, als die Dbox die Daten annehmen könnte
..eben warst Du noch anderer Meinung:
Schon klar, daß es am Switch lag/liegt. War ja auch das einzige was sich in meiner Konfiguration geändert hatte..
Ob sich dafür der Exorbitante Aufpreis für einen 3Com Switch rechnet, muß jeder für sich selbst entscheiden.
es spielt keine Rolle was draufsteht...selbst ein echter HighEnd Switch (Cisco) muss nicht der Beste sein wenn's darum geht von 100Mbit auf 10Mbit half Duplex umzusetzen...ich verlasse mich dabei lieber auf meine schlampigen selber gemachten Messungen.

cu,
peter
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Beitrag von klez »

Och PetGun. Sei doch net so kleinlich.
Desweiteren verstehe ich die Messergebnisse mit diesem einen, hier im Forum genannten, Script nicht.
Wo habe ich hier behauptet, daß Du oder Dein Script schlampig wären ?
Was kann ich dafür, wenn manche Leute MB schreiben, aber Mbit meinen ?
Genau das hat Spooky mit Schlampig gemeint, da eben diese Leute nicht auf diesen Unterschied geachtet haben, bei ihren Posts. Nichts, aber rein gar nichts davon war auf Dich oder Dein Script bezogen ! Klar geworden ?
Sehe ich ehrlichgesagt anders. Selbst das langsamste 100Mbit Netzwerk ist immernoch schneller, als die Dbox die Daten annehmen könnte
Wo habe ich in diesem Satz etwas behauptet, was dem hier
Schon klar, daß es am Switch lag/liegt. War ja auch das einzige was sich in meiner Konfiguration geändert hatte..
wiederspricht ?
Gemeint war: Selbst wenn mein Switch langsamer ist, als den den ich vorher hatte, so ist er immernoch schneller, als das was die Box verarbeiten kann.

Hoffe es ist nun alles geklärt. Nochmal danke an Spooky für den Tip.
Egal ob es ein Workaround ist oder nicht, es funktioniert jedenfalls.
Spooky
Einsteiger
Einsteiger
Beiträge: 338
Registriert: Sonntag 24. Februar 2002, 10:43

Beitrag von Spooky »

@petgun

Ich habe nie behauptet o. gedacht , dass die Arbeit die hier im Forum geleistet wird, und das schließt Deine Verbesserungsvorschläge u. Scripts mit ein, schlampig sei. Mein einzige Aussage war, viel zu ungenaue Angaben führen zu Missverständnissen.

Ob der Switch von klez wirklich langsamer ist, mag ich bezweifeln und lasse ich mal so im Raum stehen. Ich glaube eher, dass er den internen Buffer anders verwaltet und die Pakete früher verwirft. Ob das ein Zeichen von höherer Geschwindigkeit o. schlechterem Handling ist, mag jeder für sich selbst entscheiden. Fakt ist, bremst man den Datenstrom(und nur den) zur dbox auf knapp unter 9MBit ein, läuft die Wiedergabe flüssig. Wenn Du Lust u. Zeit hast, probiere es mal mit TrafficShaping aus.

Spooky

PS: Mit dem wechseln auf 100Mbit HalfDuplex machst Du auch nichts anderes beim WL-HDD, als die "Handbremse" anzuziehen.
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hiho,
Spooky hat geschrieben:Ob der Switch von klez wirklich langsamer ist, mag ich bezweifeln
...wenn ich hier geschrieben habe der neue Switch von klez sei 'langsamer' ist das technisch sicher ungenau...
Ich glaube eher, dass er den internen Buffer anders verwaltet und die Pakete früher verwirft.
..die Teile sind strohdoof und koennen weder verwalten, noch entscheiden ein unzustellbares Paket zu verwerfen...
Fakt ist, bremst man den Datenstrom(und nur den) zur dbox auf knapp unter 9MBit ein, läuft die Wiedergabe flüssig. Wenn Du Lust u. Zeit hast, probiere es mal mit TrafficShaping aus.
...und Du meinst das klez mit solch einer Datenstrombremse eine Lesegeschwindigkeit von knapp 9 Mbit schaffen wuerde? Da wette ich den naechsten Kasten Bier, das es das jetzt mit dem neuen Switch niemals schafft!
Mit dem wechseln auf 100Mbit HalfDuplex machst Du auch nichts anderes beim WL-HDD, als die "Handbremse" anzuziehen.
...der Movieplayer bleibt auch schwarz bei einem Film der nur eine _konstatnte_ Bitrate von vielleicht 2Mbit/sec hat.

Lasst uns hier diesen Disput beenden...Du/Ihr habt Eure Theorie und ich habe meine. Wichtig ist nur das es mit rsize=4096 nicht mehr ruckelt....und das habe ich keine Sekunde angezweifelt.

cu,
peter
gmo18t
Erleuchteter
Erleuchteter
Beiträge: 553
Registriert: Freitag 27. Februar 2004, 14:30

Beitrag von gmo18t »

Spooky hat geschrieben:@klez,

es ist nur eine Vermutung von mir, nachdem ich auf dem NSLU2 die selben Probleme hatte. Das 10Mbit Interface der dbox ist der Flaschenhals und der Server kann die Daten schneller liefern als die dbox sie abnimmt. Durch den "Stau" fängt der dazwischenliegende Switch nach einem Timeout an, die "überflüssigen" Pakete zu verwerfen. Durch die Nutzung von rsize=32768 ist der Geschwindigkeitsunterschied noch größer und auf einen Schlag sind nicht 4K sondern 32K Daten weg. Durch das UDP Protokoll merkt der Server nichts davon und schickt fleissig die nächsten Pakete hinterher. Parallel dazu fängt die dbox2 an sich zu "verschlucken" und bleibt eventuell sogar hängen. Man kann stattdessen auch TCP verwenden. Mit TCP wird immer eine Bestätigung über den Empfang der Pakete abgeprüft und im Bedarfsfall neu verschickt. Damit ist aber auch der Platz für die Nutzdaten (Videostream) im Netz geringer und die Geschwindigkeit sackt unter die Werte einer funktionierenden UDP-Verbindung ab.

Spooky
... schön erklärt ...
das "udp-Proplem" tritt auch vermehrt auf, wenn verstärkter Netzwerkverkehr herrscht (z.B. mehrere Boxen streamen von 1 Server mit 1 NIC). Dann müssen nach Kollisionen die Buffer wieder neu gefüllt werden, was zu Rucklern führt. In dem Fall arbeitet "tcp" mit großen Buffern zuverlässiger.

- GMo -
Sagem 1x Kabel, AVIA600_vb028, cam-alpha 01_02_105D, int. ucode, .sp_ts + .hw_sections
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

gmo18t hat geschrieben:...In dem Fall arbeitet "tcp" mit großen Buffern zuverlässiger.
jau...lest Euch das http://cdfcaf.fnal.gov/doc/cdfnote_5962/node16.html mal bitte aufmerksam durch, studiert die Tabelle und zieht bitte Schluesse daraus.
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Beitrag von klez »

hi... Hab nochmal ne Frage:

Ich wollte mal testweise versuchen das NFS-Share mit TCP zu mounten, aber durch die GUI funktioniert das nicht. Gebe ich das entsprechende Kommando über Telnet ein, hängt sich die Shell auf. Weiss jemand woran das liegt ?
ifish
Neugieriger
Neugieriger
Beiträge: 12
Registriert: Donnerstag 2. September 2004, 11:36

..nochmal zum Thema ruckeln..

Beitrag von ifish »

Hallo,
nochmal zum Thema schlechtes Netzwerk:

Ich nehme auch Ts-Files auf, das klappt ganz gut,
auch das Abspielen funktioniert zuerst, in der Mitte fängt es jedoch massiv an zu ruckeln.

Nach dem was ich hier gelesen habe, dürfte es auch an meinem Netzwerk liegen:

100Mbit PC --------> 100/10 MBit HUB <--------- 10Mbit Dbox2 / Neutrino
............................................|
...........................................` e
............................100 MBit Fritzbox Fon


Fragt mich nicht warum; es funktioniert, obwohl ich den PC NICHT auf 10 MBit heruntergestuft habe.
Aber es ruckelt eben,

ist es richtig, dass es wohl an dem schwachen HUB liegen dürfte und das Problem durch das Nutzen eines Switches behoben werden kann?
klez
Einsteiger
Einsteiger
Beiträge: 112
Registriert: Sonntag 15. Dezember 2002, 17:43

Beitrag von klez »

Der Austausch kann etwas bringen, muß aber nicht.
Ehrlichgesagt verstehe ich das ganze sowieso nicht richtig und ich bin auch der Meinung, daß viel an der Box und dem verwendeten Image liegt. Auch ich hatte ab und zu Ruckler. Auf älteres Image gewechselt -> Ruckeln weg.

Das der eine oder andere Switch bei der Umsetzung von 100 auf 10 Mbit Performanter ist will ich gar nicht abstreiten. Trotzdem wundert mich dabei folgendes:

Stelle ich die NIC meines PCs auf 10Mbit/half, habe ich beim abspielen von TS auf eben diesem PC keinerlei Ruckler trotz CIFS mount. Auf der Dbox (trotz angeblich performanterem NFS) aber schon.
Logische Erklärung ? Mir fällt keine ein.
Selbst die Wiedergabe über WLAN auf dem Notebook geht Problemlos.

Irgendwie habe ich das Gefühl, daß die Dbox sehr wählerisch ist, was den verwendeten Switch angeht, auch wenn das nach Blödsinn klingt.
Angeblich sollen Netgear Switches ganz gut funktionieren (habe ich aber bisher nicht ausprobiert).
TheGenesis
Interessierter
Interessierter
Beiträge: 35
Registriert: Samstag 8. Juni 2002, 02:46

Beitrag von TheGenesis »

Die eingebauten Switches in den Netgear Routern funktionieren ganz gut.

Aber mal ene andere Frage ... kann mir jemand enen halbwegs günstigen Gigabit-Switch (8 Port) empfehlen, auf dem das abspielen eines TS ruckelfrei läuft ?

Danke im voraus
Thom
trinidat
Interessierter
Interessierter
Beiträge: 41
Registriert: Sonntag 9. November 2003, 22:53

Beitrag von trinidat »

Sorry, dass ich diesen threat aus der Vergangenheit ans Licht hole (April 2005). Aber es geht dabei genau um mein Problem, für das ich immer noch keine Lösung gefunden habe. Ich verwende den Netgear WGT 624 WLAN-Router mit eingebautem Swich. Wenn ich die TS-files vom PC (SFU-mount) via WLAN mit dem movieplayer auf der Box anschaue, habe ich ein extremes Ruckeln. Wenn ich mit einem Lan-Kabel direkt vom PC in den Router fahre, habe ich mit dem gleichen ts-file kein Ruckeln. Bei der Direktverbindung habe ich bei meiner Netzwerkkarte die Datenrate auf 10Mbit herabgesetzt, damit kommt der Switch nicht in Bedrängnis und ich kann die ts-files ruckelfrei abspielen. Lasse ich die Datenrate der Netzwerkkrate auf 100 Mbit, habe ich das gleiche Ruckeln wie im Wlan.

Mein Problem: Im WLAN habe ich keine Netzwerkkarte, wo ich den Stream auf 10Mbit herabsetzten kann.

Vielleicht kann sich irgend ein Fachmann dieser Frage annehmen. TS-Abspielen im WLAN mit dem movieplayer ohne Ruckeln.

Ansonsten werde ich wohl umsteigen müssen und mpegs aufnehmen und diese auf DVD brennen. Aber lieber würde ich schon den Movieplayer nützen.



Spooky hat geschrieben:@klez,

es ist nur eine Vermutung von mir, nachdem ich auf dem NSLU2 die selben Probleme hatte. Das 10Mbit Interface der dbox ist der Flaschenhals und der Server kann die Daten schneller liefern als die dbox sie abnimmt. Durch den "Stau" fängt der dazwischenliegende Switch nach einem Timeout an, die "überflüssigen" Pakete zu verwerfen. Durch die Nutzung von rsize=32768 ist der Geschwindigkeitsunterschied noch größer und auf einen Schlag sind nicht 4K sondern 32K Daten weg. Durch das UDP Protokoll merkt der Server nichts davon und schickt fleissig die nächsten Pakete hinterher. Parallel dazu fängt die dbox2 an sich zu "verschlucken" und bleibt eventuell sogar hängen. Man kann stattdessen auch TCP verwenden. Mit TCP wird immer eine Bestätigung über den Empfang der Pakete abgeprüft und im Bedarfsfall neu verschickt. Damit ist aber auch der Platz für die Nutzdaten (Videostream) im Netz geringer und die Geschwindigkeit sackt unter die Werte einer funktionierenden UDP-Verbindung ab.

Spooky
TheGenesis
Interessierter
Interessierter
Beiträge: 35
Registriert: Samstag 8. Juni 2002, 02:46

Beitrag von TheGenesis »

Mit WLAN habe ich aufgegeben ... ebenso mit diversen Powernet-Adaptern ... das einzig Wahre ist Kabel und die Karte möglichst auf 10 MBit Half-Duplex.

Um den WLAN-Adapter bzw. den Port auf 10 MBit zu zwingen könntest du mal versuchen einen waschechten 10 MBit HUB direkt an die Box zu hängen ... manchmal wirds damit besser ... manchmal leider nicht.

Bei manchen Netzwerken hats auch geholfen, den NFS-Read Buffer beim mounten auf 8192 zu stellen (anstatt die megagroßen Bufferwerte).

Weiterhin empfehle ich, ABSTAND vom SFU zu nehmen und stattdessen den supergenial funktionierenden HaneWin NFS-Server zu verwenden.

Der tuts übrigens auch unter Win98 einwandfrei und muß nichmal großartig installiert werden.

Wenn man EINMAL das Setup gemacht hat kann man den Programmpfad einfach so kopieren und das Teil läuft auch auf anderen Rechnern. Den Registry Pfad [HKEY_LOCAL_MACHINE\SOFTWARE\haneWIN\nfsd] sollte man dann allerdings mitkopieren :wink:

Mount Einstellungen mit HaneWin sind folgende:

network_nfs_dir_0=/Stream
network_nfs_mount_options1_0=udp,nfsvers=3,mountport=1058
network_nfs_mount_options2_0=nolock,rsize=65535,wsize=65535
network_nfs_type_0=0

HaneWin exports:

S:\Stream -name:Stream -range 192.168.0.7 192.168.0.7

Viel Glück!

Gruß
Thom
jmittelst
Tuxboxer
Tuxboxer
Beiträge: 6044
Registriert: Montag 17. November 2003, 06:48

Beitrag von jmittelst »

Schade nur, das der Hanewin nur Shareware ist und mit 19 Euro zu Buche schlägt.
cu
Jens
Belgarad
Einsteiger
Einsteiger
Beiträge: 182
Registriert: Donnerstag 1. November 2001, 00:00

Beitrag von Belgarad »

jmittelst hat geschrieben:Schade nur, das der Hanewin nur Shareware ist und mit 19 Euro zu Buche schlägt.
cu
Jens
Für den Fall dass die 19,- Eur das Problem loesen, stellt sich die Frage wieviele Stunden man alternativ in die Fehlersuche und _nicht_ Fehlerbehebung stecken darf, damit sich die ersparten 19,- Eur rechnen...
jmittelst
Tuxboxer
Tuxboxer
Beiträge: 6044
Registriert: Montag 17. November 2003, 06:48

Beitrag von jmittelst »

Nebenbei: Ist das nicht auch nur ein V2-Server mit 2GB-Problem?
Und ganz nebenbei: Bei mir läuft jetzt schon die 3. SFU-Installation direkt aus der Installationsdatei.
cu
Jens