Gestern war ein Freund von mir zu Besuch und brachte seinen iPod 3Gen und eine externe Maxtor Platte mit.
An meinem iBook hingen bereits meine externe Platte und ein LG Brenner.
Alles angehängt ergab sich folgendes Bild:

iBook-FW Platte-LG DVD-Maxtor HD.

Nun haben wir von seiner Maxtor mittels toast Image auf DVD gebrannt. Dann dachten wir, steck mal den iPod an die Maxtor (einziger freier Port in der Kette) und kopier eben noch zwei Tools davon.
Mit dem Einstecken ist aber sofort das Brennen beendet und Toast meldet eine kryptische Fehlermeldung über "Medium Error" und/oder "unknown command".
Das Rausziehen des iPods beim Brennen hat die gleiche Wirkung.
Das haben wir dann auch noch mit meinem 2.Gen iPod versucht, selbes Resultat.

Was soll sowas?
Warum fliegt der Brennvorgang ab, wenn ich ein Firewire Gerät an die Kette hänge??

Klar, dass das Toast nicht mag!
Überleg mal den Datenstrom...
...von der Maxtor übers LG-DVD und die FW-PLatte ins iBook, dort von Toast verarbeitet und wieder die Daten zurückgeschickt durch die FW-PLatte auf den Brenner... und dann kommen plötzlich noch Daten voM Ipod über die Maxtor durch den Brenner und die FW-Platte ins iBook mit anschließender Rückmeldung vom iBook wieder zurück bis in den iPod... dass sich Toast dann irgendwann verschluckt, ist doch wohl klar?
Bisschen viel Verkehr auf der Datenautobahn in beide Fahrtrichtungen. Und das dann auch noch bei (wahrscheinlicher) Brenngeschwindigkeit > 1x....

Daten- / Stromabriss!? Ich finde das nicht schlimm. Die DVD-Brennerei ist meiner Meinung nach eh nicht ausgereift.

Brenngeschwindigkeit ist dabei total egal.
Und gegen Daten- / Stromabriss hat der Brenner dieses BurnProof, was von Toast auch aktiviert wurde.
Es reicht das Einstecken und die Meldung erscheint sofort.

Also ich finde das nicht so normal...

Danke Arekhon,

das war eine super Erklärung!
Muss ich mir halt angewöhnen während des Brennens nix an den Bus zu stecken oder zu entfernen....

Danke nochmals.

Das hat mit Bandbreite nichts zu tun und BurnProof hilft da auch nicht. Der Brennvorgang bricht immer ab wenn man wärend des Vorgangs ein zusätzliches FireWire-Gerät an den gleichen Bus hängt. Der FW-Bus wird dabei neu initialisiert, Festplattenkopiervorgänge vertragen das, Brennvorgänge mit FW-Brennern nicht, so einfach ist das.
<br>Mit der iSight ist es genauso, jedesmal wenn die sich ein-/ausschaltet ist es Essig mit dem Brennen, daher sollte man dann nicht Brennen oder die iSight an einem anderen FW-Bus betreiben.
<br>ein FW-HUB hilft übrigens auch nicht.
<br>Also, it&rsquo;s not a bug, it&rsquo;s a feature. Da kann man nichts dran machen.

Vermutlich liegt es am verwendeten Befehlssatz der Brenner, die eine solche Bus-Neuinitialisierung nicht vertragen und dann Schluckauf bekommen. Mit Datenstromunterbrechungen und -verminderungen kommen die Geräte zurecht und da hilft dann auch Burnproof, aber die Businitialisierung ist offensichtlich nicht vorgesehen und wird nicht abgefangen. Ich denke es handelt sich um einen Protokollmangel bei den Brennern bzw. den Bridge-Chips in Verbindung mit den Brennern. Leider habe ich dazu aber noch keine exakte technische Aussage gefunden.
<br>Firewire selbst kann dies ja abfangen wie man an anderen Geräten sieht, bei Festplatten sind solche Probleme fast gänzlich unbekannt.

Naja, dass man es z.Zt. am gleichen Bus nicht umgehen kann wissen wir mehr oder weniger. Aber warum es so sein muss und warum die Hersteller daran bisher nichts geändert haben wissen wir leider nicht genau. Ich gehe davon aus, dass es technisch möglich wäre dies abzufangen, entweder könnte ein entsprechender Mechanismus in der Brennsoftware vorgesehen werden, was ein unschöner workaround/hack wäre, oder aber die Bridge-Chips müßten angepasst werden. Ich denke von den Brennerherstellern ist nichts zu erwarten, da für sie FireWire kein Hauptziehlmarkt ist und der Konkurrenzdruck bei den Brennern eh schon zu einer Konsolidierung geführt hat, die haben also andere Sorgen.
<br>Ob Apple da wohl was an den Firewire-Treibern machen könnte, keine Ahnung.
<br>Eigentlich erwarte ich da eh nix, traurig und ärgerlich aber wohl leider war....
<br>
<br>Eine technisch saubere Lösung wäre ein FireWire-Switch, der die Busse quasi entkoppelt und so die Initialisierung "lokalisiert". Nichts anderes wird seit Jahren im Fibre-Channel Bereich gemacht. Da kommt es ohne Switches auch zu sog. LIPs, also Loop-Initialisierungen, FC-AL ist also mit FireWire bedingt vergleichbar. Neue Geräte im FC-Bereich werden sowieso nur noch im Fabric-Mode, oder im Public-Loop-Mode also mit Switches betrieben. Ob sowas auch mal bei FireWire Einzug hält möchte ich aber aus Kostengründen einfach mal bezweifeln. Vermutlich ist es in den Specs auch gar nicht vorgesehen, aber dazu kenne ich mich im Detail mit FireWire zu wenig aus, im Gegensatz zu FibreChannel.

Mhh, Strombedarf ? Bandbreitenreservierung ?
<br>
<br>Die iSight nimmt sich ja auch die ganze Bandbreite, so das nichts anderes mehr geht, Rantanplan kann da ein Liedchen davon singen.

Augenblick, das es quasi ein Reset/Initialisierung gibt, beim Anstecken, Ein/ausschalten, das ist verständlich, aber das es überhaupt keinen Betrieb gibt, lässt sich durch die Initialisierung nicht unbedingt erklären, ausser sie wäre fehlerhaft oder es stünde eben nicht genug Strom/Bandbreite zur Verfügung, m.e.

Rantanplan hat mal gepostet, das seine isight nur direkt und alleine am Mac Firewireport geht und alle Geräte blockt, wenn sie extern in Kette angeschlossen wird. Nehme aber an das er aktuelle Bridgefirmware hat in den externen. Kann das bestätigt werden, das isight extern, in reihe angeschlossen Probleme verursacht ?

ok, interessant das zu hören, auch da ich keinerlei Problem mit einer DV Cam von Panasonic über externen Brenner und Laufwerk angeschlossen habe. Könnte also sehr wohl an der Firmware der isight, bzw. der Brennergehäuse liegen.