USB MP3-Player will nicht am Mac

Dec 25, 2004 52 Replies

Hallo,



habe für meine Tochter einen eigentlich ganz schicken und preiswerten MP3-Player gekauft: Gembird FDrive 128 FM (mit Radio).



Am PC wird das Teil problemlos als MassStorage erkannt. Schließe ich den jedoch an einen beliebigen Mac mit USB an, passiert Folgendes:


  1. Player zeigt "starting..."
  2. Player zeigt PC-Connect-Symbol
  3. Mac merkt das da "was ist"
  4. Palyer schaltet sich aus
  5. Mac merkt das da "nix ist"
  6. gehe zu 1.

Und das endlos mit einer Zykluszeit von ca. 5 Sekunden. Ich dachte immer USB ist standardisiert. Was kann die Ursache sein? Macs habe ich folgende probiert:


- G3 Powerbook Mainstreet mit Belkin USB-Card, MacOS 9.2.2



- G4 Titanium, MacOS X 10.3.7



- Umax Pulsar mit USB-PCI-Karte, MacOS 8.6



Alle diese Macs sind in der Lage mit externen USB-Festplatten und mit 2 anderen MP3-Playern ("RedRock" und Treckstore) problemlos umzugehen, nur der Gembird "spinnt".



Es scheint so, als ob der Mac irgendwie anders "ergründet", was da angeschlossen ist und diese Methode den Gembird zum Absturz bringt ...



Hat jemand eine Idee?



Frank


Im Handbuch steht nix von MAC Support. Das wird also warscheinlich nix. Es wird halt kein std Massenspeicher sein und unter WIN mit einem speziellen Treiber arbeiten. Thomas

Hmm ... das da was nicht kompatibel ist, ist mir auch klar. Aber unter Win2000 brauchte es keinen speziellen Treiber - definitiv.

Frank

Es gibt noch schraegere Sachen. Ich hab einen USB-Stick hier der laeuft unter Solaris 8 x86 problemlos, unter Solaris 9 Sparc gibts einen SCSI-Error, Windows XP sieht ihn meist erst nach dem 2. einstecken und beim Mac haengt sich der USB-Controller bis zum Reboot weg wenn ich ihn als USB2-Device probiere. Mit einem USB1.1-Hub dazwischen geht es.

Soviel zum Thema 'USB ist problemlos'... USB ist inzwischen aehnlich instabil wie damals die Basteleien am Parallelport.

Gerrit

USB war *von Anfang an* instabil. Wenn ich da an meine ersten=20 USB-Versuche denke, Webcam unter Win98SE . Auch eine HDD =FCber= =20 USB brachte erhebliche Probleme mit sich. UnSauberer Bus halt. USB 1.0=20 hat ja bekanntlich gleich gar nicht funktioniert ...

GG

Externe Festplatten laufen hier grundsaetzlich ueber Firewire. Nebenbei kommt da noch genug Saft raus um 2.5"-Platten zuverlaessig (*) zu betreiben.

(*) Es braucht keine Hacks a la Y-Kabel oder die Hoffnung, dass es gerade so eben reicht.

Gerrit

Gerrit Heitsch schrieb:

Same here, hab aber USB2.0/Firewiregeh=E4use. USB nur im Notfall, wenn de= r=20 Zielrechner kein Firewire hat.

GG

Reine Firewire-Gehaeuse gibts nur noch selten, also muss ich die Kombination kaufen. *Aerger* Die kostet mehr.

Wobei Firewire-Gehaeuse normalerweise 2 oder manchmal 3 Anschluesse haben, also problemlos kaskadiert werden koennen. Kein Hub noetig (u.U. dann aber eine eigene Stromversorgung :))

Gerrit

Gerrit Heitsch schrieb:

Die Kaskadierung hat bei mir unter WiXP nicht funktioniert. Es wurde immer nur ein LW erkannt. Tolle Wurst ...

GG

Unter MacOS X gehts... (gerade nochmal getestet). Beschwerden also bitte an Microsoft richten. Deren Firewire-Implementation ist wohl etwas lueckenhaft.

Gerrit

Gerrit Heitsch schrieb:

Da ist aber als Ziel /dev/null effektiver als Microsift.

Streich "Firewire-" im obigen Satz. ;-) Aber ich hab auch schon=20 Firewirecontroller gesehen, die als maximale Paketgr=F6=DFe 2 KByte gemel= det=20 haben, also ist Mickeysoft doch nicht immer Schuld. Oder?

GG

Hallo Frank,

Frank Esselbach schrieb:

Das vergiß mal ganz schnell. Ich habe hier einen ganzen Schwung USB-Geräte, von denen sich kaum zwei gleich verhalten. Darunter auch mehrere, die ganz eindeutig gegen grundlegende Anforderungen des USB-Standards verstoßen. Und unter Windows trotzdem erkannt werden und benutzbar sind, weil die um den Fehler herumarbeiten.

Gruß Martin

Bitte nicht an der E-Mail-Adresse fummeln, die paßt so. ------------------------------------------------------- Softwarepatente? Nein, danke. Hier eintragen: http://petition.eurolinux.org/index_html

Kann ich nichts zu sagen. Ich weiss nicht, was Apple verbaut hat, aber die beiden Karten in den Linux-Kisten sind vom billigen Typ mit Chip von Lucent/Agere. Kann keine Probleme festellen,

20MB/sec beim Kopieren auf die externe Platte (P3-600 auf 440BX) bieten keinen Grund zur Klage.

Gerrit

Das Zwischenklemmen eines USB-Hub hat zumindest das Laden des Akku über USB ermöglicht und die ewige Ein- und Ausschalterei beseitigt. Ein Zugriff auf den Speicher ist aber trotzdem nicht möglich ...

Gibts eigentlich für USB irgendwelche Analysetools, die spezielle Eigenschaften solcher Geräte testen bzw, anzeigen? So eine Art Protokoll-Validator?

Frank

Gerrit Heitsch schrieb:

Ich such das mal raus - das war ein extrem billiger Controller.

GG

Hier:

formatting link

USBCV testet aber nur das Lowlevel-Protokoll, bei dir hakts wohl eher an der USB Mass Storage Implementierung...

Georg Acher, acher@in.tum.de http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Hast Du einen 1.1 oder 2.0 Hub dazwischen gesetzt? Ich hatte neulich eine ähnliche Konstellation: MP3-Player läuft an Rechner A mit USB 1.1-Ports wunderbar, Rechner B (mit NVidia-nforce2-Chipsatz und USB 2.0-Ports) erkennt das Teil, kopiert auch manchmal ein paar Daten, und hängt sich dann weg.

Des Rätsels Lösung: einen USB-2.0-Hub dazwischen klemmen. Der Player erzeugt wohl das Taktsignal mit einem leichten Jitter. Einige USB-Controller kommen damit klar, der NVidia-eigene jedoch nicht. Ein USB-2.0-Hub erzeugt das Taktsignal neu und vermeidet so den Jitter am NVidia-Port. Problem gelöst...

Sebastian

Unter OS-X gibts den "USB Prober", zumindest wenn man die Developer-Tools mit aufgespielt hat, der liefert schon einige Informationen über das was der Mac da erkannt hat.

Herbst und Winter, die friedlichste Zeit am Bodensee... Fehler sind geistiges Eigentum des Autors, die Weiterverwendung ist untersagt. Patrick Rauter

Einen USB 1.1-Hub. Einen 2er muss ich mir erst besorgen bzw. ausleihen. Danke für den Tip.

Frank

USB-Geräte,

Und

das ist definitiv so und kommt meines Erachtens daher dass unter win relativ schnell kaputte devices auf dem Markt waren. Da die Treiber alles andere als ok waren gab es da Workarounds. Ich benutze die teilweise noch heute, damit ich meine Kisten unter allen Win Versionen gleich ans laufen bekomme. Am Mac war ist die Situation generell anders, da die von vorne rein nur wirklich kompatible HW supported haben. Wenn man nur unter Windows entwickelt bekommt man das in der Regel relativ spät mit wenn man einen Bug hat. Die eigendliche Schuld an dem Desaster hat aber nicht MS sondern Intel mit Ihrem UHCI Standart.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required