Zum Inhalt springen

DTS Ausfall bei "Überblendung" von Laufwerk A auf B


Empfohlene Beiträge

Geschrieben

Mein DTS läuft soweit einwandfrei, jedoch in dem Moment, in dem der Aktübergang stattfindet, in dem von Disc A auf Disc B "überblendet" werden muss, setzt es kurz aus und braucht zwischen 5 bis 10 Sekunden, bis der DTS Ton wieder da ist. Der Timecode wird jedezeit laut Anzeige einwandfrei erkannt.

 

Es handelt sich um einen DTS Prozessor der alten Version mit den 2 Laufwerken.

 

In einem anderen Saal habe ich einen DTS 6D Prozessor (mit den 3 Laufwerken), dort tritt bei derselben Kopie dieses Problem nicht auf.

 

Kann mir jemand sagen, woran es liegen könnte ?

Geschrieben

nein, es sind NICHT die alten Caddy Laufwerke, also urteilt bitte nicht ganz so schnell ;-)

 

Ich werde Michaels Vorschlag prüfen und dann berichten.

Die genaue Typenbezeichnung der neuen Laufwerke werde ich in Erfahrung bringen und mitteilen.

 

Welche Version von ROM DOS es ist,weiß ich nicht, ich verstehe leider nicht viel von PCs

Geschrieben

Lief das denn in diesem Gerät früher mal einwandfrei bei Dir, oder hast Du das Ding erst kürzlich angeschafft. Kannst Du die Typbezeichnung der Laufwerke rausfinden?

 

- Carsten

Geschrieben

Sorry für die Voreiligkeit ;) Ich hatte mal versucht neue Laufwerke einzubauen. Hat irgendwie nicht geklappt, deshalb dachte ich es seien die alten Caddys.

Ich hab hier übrigens noch 2 SCSI Laufwerke liegen. Falls es am Laufwerk liegt kannst du sie gegen Porto haben.

 

Du könntest auch eine Grafikkarte reinstecken und Monitor anschließen und mal sehen ob er da irgendwelche Fehler ausgibt.

Geschrieben

Hallo Leute , PROBLEM GELÖST :-)

 

Zuerst habe ich Michaels Vorschlag geprüft und Disc A mit Disc B getauscht.

Der Fehler ist mit den Discs gewandert bzw. im Laufwerk gleich geblieben, d.h. die 10 Sekunden Ausfall waren nun nicht mehr beim Übergang von Disc A auf Disc B,

sondern direkt beim Start von Disc A (die ja nun im Laufwerk B lag). Der Übergang (Von Laufwerk B nach A) ging unterbrechungslos vor sich.

Das Problem konnte also am Laufwerk B festgemacht werden.

 

Ich habe daraufhin das Gerät geöffnet und konnte feststellen, dass am Laufwerk B KEINE Jumper gesetzt waren.

Anhand eines anderen DTS-Gerätes habe ich mir angesehen, wie die Jumper an Laufwerk B gesteckt sein sollen.

Dies habe ich getan und seitdem funktioniert Laufwerk B einwandfrei.

 

Keine Unterbrechung mehr *freu*

 

Vielen lieben Dank an Euch, allen voran Michael, der mich auf die richtige Spur gebracht hat.

 

 

 

 

  • Like 1
Geschrieben

Master-Slave gabs bei SCSI nicht ;-)

 

Wird Terminierung oder ID gewesen sein. Erklärt zwar nicht, warum es nach längerer Wartezeit dann doch auch ohne weiter geht, aber SCSI und Voodoo waren eh synonym zu verwenden.

 

Die dts Doku hat recht ausführliche Infos dazu, welche IDs und sonstige Jumper bei welchem Laufwerk zu setzen sind.

 

- Carsten

Geschrieben

Master-Slave gabs bei SCSI nicht ;-)

 

Wird Terminierung oder ID gewesen sein. Erklärt zwar nicht, warum es nach längerer Wartezeit dann doch auch ohne weiter geht, ...

 

Bei fehlender Terminierung auf dem Bus gibt es Übertragungsfehler, Laufwerk und Controller versuchen es dann mit einem langsameren Übertragungsmodus. Mit viel Glück geht's dann ...

 

 

... aber SCSI und Voodoo waren eh synonym zu verwenden.

 

Kann ich so aus meiner Erfahrung nicht bestätigen.

 

 

Gruß

 

Salvatore

Geschrieben

 

...

Mit viel Glück geht's dann ...

...

Kann ich so aus meiner Erfahrung nicht bestätigen.

 

Die einen nennen es 'Voodoo', die anderen 'mit viel Glück'

 

- Carsten

Geschrieben

Die einen nennen es 'Voodoo', die anderen 'mit viel Glück'

 

Die Aussage "Mit viel Glück geht's dann ..." bezog sich eindeutig auf den Betrieb ohne Terminator.

Was bei einem Betrieb gegen die Spezifikationen (z.B. zu lange Kabel, fehlender Abschlußwiderstand usw.) passiert, das kann man dem System nicht anlasten.

Sollte hier die Terminierung gefehlt haben (meine Glaskugel ist zur Reparatur), so spricht es doch für das System, wenn sich die Geräte trotzdem mit dem Controller unterhalten können.

Daß das bei einem Gerät einmalig bis zu 10sec. braucht, ist einfach nur Hochfrequenztechnik und ein gutes Protokoll, aber kein Voodoo.

 

Im Vergleich zu IDE, wo nicht jedes Gerät mit jedem anderen Gerät am selben Bus betrieben werden konnte oder unbedingt Master sein wollte, war SCSI einfach nur stressfrei.

 

 

Gruß

 

Salvatore

Geschrieben

Genau so sehe ich das auch.

Im Vergleich zu IDE konnte man an SCSI eine ganze Batterie an Laufwerken an einem

Strang anschließen, man mußte lediglich auf die Adressierung achten und einem Terminator

am Ende des Strangs.

Der Nachteil an SCSI war lediglich der Preis.

Geschrieben

Soso, konnte man ;-) In der Nachschau sieht ja oft vieles besser aus als es war. Ich empfehle mal die Lektüre eines Datenblatts mit Jumperbelegungen einer typischen SCSI-Festplatte aus den 90ern und den Vergleich mit einem IDE/ATAPI Laufwerk.

 

Ich habe noch kistenweise SCSI Krams im Keller liegen und habe damals mit dem Beheben von Problemen und der Reparatur von geschredderten Filesystemen auf externen Festplatten bei Agenturen viel Geld verdient...

 

Im Vergleich hatte IDE/ATAPI zwar Limitierungen, aber bei weitem nicht soviel Konfliktpotential. Ob das dem Standard oder den Nachlässigkeiten bei Gerätebau und Dokumentation angelastet werden darf, ist dabei doch reichlich egal, es heisst ja nicht 'SCSI-Standard-Voodoo', sondern 'SCSI-Voodoo'.

 

 

http://www.catb.org/...CSI-voodoo.html

 

http://www.essential...m/fix/scsi.html

 

https://68kmla.org/f...i-voodoo-howto/

 

http://www.quillserv...scsivoodoo.html

 

http://encyclopedia..../sc/SCSI_voodoo

 

- Carsten

Geschrieben

Soso, konnte man ;-) In der Nachschau sieht ja oft vieles besser aus als es war. Ich empfehle mal die Lektüre eines Datenblatts mit Jumperbelegungen einer typischen SCSI-Festplatte aus den 90ern und den Vergleich mit einem IDE/ATAPI Laufwerk.

 

Und was steht da in den Datenblättern nun so Schlimmes drin, daß Du das hier nicht schreiben kannst?

 

 

Ich habe noch kistenweise SCSI Krams im Keller liegen und habe damals mit dem Beheben von Problemen und der Reparatur von geschredderten Filesystemen auf externen Festplatten bei Agenturen viel Geld verdient...

 

War das vielleicht zu einer Zeit als Filesysteme i.d.R. defekt waren, wenn beim Schreibvorgang der Rechner abgestürzt ist oder das externe Laufwerk abgezogen wurde?

Und welche Alternativen gab es zu dieser Zeit zu SCSI bei externen Laufwerken?

Hast Du die genaue Ursache für die Fehler gefunden? Wenn ja, woran lag es?

 

 

Im Vergleich hatte IDE/ATAPI zwar Limitierungen, aber bei weitem nicht soviel Konfliktpotential.

 

Stimmt, da gab es gar keine Möglichkeit externe Laufwerke anzuschließen und damit kamen auch nicht so viele Leute in die Versuchung, den Bus auf eine unzulässige Länge zu vergrößern. Da war die nur interne Nutzungsmöglichkeit mit maximal 2 Geräten und einer maximalen Kabellänge von ca. 40 cm schon ein Vorteil gegenüber SCSI, das mit 1,5 m bis 3 m Bus-Länge (bei Heimrechnern, mit HVD deutlich mehr) und 7-15 Geräten je Bus die armen Anwender nur verwirrt hat.

Achtung, die letzten zwei Sätze können Ironie enthalten.

 

Wenn man sich an die Vorgaben hält, dann läuft SCSI völlig stressfrei. Häufige Anwenderfehler bei externen SCSI-Geräten sind:

* Zu langer Bus (interne Kabellänge wird nicht bedacht und dem externen Kabel nicht hinzugerechnet).

* Passiver Terminator obwohl ggf. aktiver Abschluß vorgeschrieben ist.

* Nur die unteren Bitleitungen terminiert.

* Adapterkaskade (vielleicht der einzige Vorwurf, den sich SCSI gefallen lassen muß - das Steckerchaos).

 

In Tonstudios gab es oft externe SCSI-Festplatten. Lief einwandfrei ohne Probleme. Und warum hat sich SCSI in Servern so lange gehalten, obwohl Plattenplatz mit IDE deutlich günstiger war, wenn es doch angeblich gar nicht sicher funktionierte?

Meinen letzten privaten SCSI-Rechner habe ich mit Windows 2000 außer Betrieb genommen. Mit externem DDS2 Bandlaufwerk. Auch der lief bis zum Schluß problemlos.

 

Man kann natürlich auch von "Voodoo" sprechen, wenn z.B. fehlerhafte DCPs nicht auf allen Servern laufen und unterschiedliche Fehler produzieren. Ist dann aber IMHO das falsche Forum dazu. ;-)

 

 

Gruß

 

Salvatore

Geschrieben

Und was steht da in den Datenblättern nun so Schlimmes drin, daß Du das hier nicht schreiben kannst?

 

Das könntest Du per Google ja selber tun. Tust Du aber aus dem gleichen Grund nicht, warum ich es nicht tue - weils eigentlich nicht interessiert.

 

...oh, ich seh grade, Cinerama ist wieder da, dann muss ich ja nicht mehr deine Spielchen mitspielen und geh jetzt ein Eis essen...

 

- Carsten

 

post-76064-0-44130600-1400946034.jpg

Geschrieben

Das könntest Du per Google ja selber tun.

 

Ich suche doch nicht bei Google nach Datenblättern, um dann zu überlegen, was genau aus diesen Datenblättern Du gemeint haben könntest. Deine Argumente musst Du schon selbst vorbringen.

 

 

Tust Du aber aus dem gleichen Grund nicht, warum ich es nicht tue - weils eigentlich nicht interessiert.

 

Nimmst Du öfters an Diskussionen teil, die Dich nicht interessieren? Oder bist Du im Auftrag des Herrn unterwegs und glaubst, das für andere entscheiden zu können?

 

 

...oh, ich seh grade, Cinerama ist wieder da, dann muss ich ja nicht mehr deine Spielchen mitspielen und geh jetzt ein Eis essen...

 

Anbei mal ein Beispiel aus der Praxis (Desktop SCSI-HDD aus 1997) und nicht aus der Bildersuche von Google. Weder "Voodoo" noch sonderlich kompliziert. Für den Heimrechner waren im gezeigten Beispiel i.d.R. nur JP 2-4 und JP 6 wichtig.

 

post-79160-0-96293900-1400952907_thumb.jpg

 

post-79160-0-40313800-1400952925_thumb.jpg

 

Gruß

 

Salvatore

Geschrieben

snapback.pngcarstenk sagte am 24 Mai 2014 - 17:39:

 

Tust Du aber aus dem gleichen Grund nicht, warum ich es nicht tue - weils eigentlich nicht interessiert.

 

Salvatore Di Vita sagte am 24. Mai 2014 - 19:39

Nimmst Du öfters an Diskussionen teil, die Dich nicht interessieren? Oder bist Du im Auftrag des Herrn unterwegs und glaubst, das für andere entscheiden zu können?

 

 

 

Deine Fragen sollten mit einem eindeutigen und lauten Ja beantwortet werden.

 

Was glaubst Du denn @Salvatore Di Vita - Was glaubst Du denn, warum er zu

fast jedem Thema etwas zu sagen hat und mit mehr als 7.000 Beiträgen an der

Spitze steht? Vielleicht heißt es in Zukunft bald nicht mehr Filmvorführerforum,

sondern ............. (...ab hier schweigt der Autor.... :wacko: :unsure: :( :huh: :twisted: )

 

 

Gruß

Maximum

Geschrieben

Also ich habe auch nie Probleme mit SCSI gehabt, ganz im Gegenteil.

Außerdem hatte/hat man bessere Möglichkeiten der Datenträgerverwaltung

über den Controller.

Daran kann ich zumindestens nichts finden was Voodoo ist, man sollte sich

natürlich damit auch auskennen und gescheite Controller wie z.B. Adaptec

verwenden.

Ist halt etwas anspruchsvoller als lediglich bei zwei Laufwerken Master oder Slave

zu stecken.

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Filmvorführer.de mit Werbung, externen Inhalten und Cookies nutzen

  I accept

Filmvorfuehrer.de, die Forenmitglieder und Partner nutzen eingebettete Skripte und Cookies, um die Seite optimal zu gestalten und fortlaufend zu verbessern, sowie zur Ausspielung von externen Inhalten (z.B. youtube, Vimeo, Twitter,..) und Anzeigen.

Die Verarbeitungszwecke im Einzelnen sind:

  • Informationen auf einem Gerät speichern und/oder abrufen
  • Datenübermittlung an Partner, auch n Länder ausserhalb der EU (Drittstaatentransfer)
  • Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen
Durch das Klicken des „Zustimmen“-Buttons stimmen Sie der Verarbeitung der auf Ihrem Gerät bzw. Ihrer Endeinrichtung gespeicherten Daten wie z.B. persönlichen Identifikatoren oder IP-Adressen für diese Verarbeitungszwecke gem. § 25 Abs. 1 TTDSG sowie Art. 6 Abs. 1 lit. a DSGVO zu. Darüber hinaus willigen Sie gem. Art. 49 Abs. 1 DSGVO ein, dass auch Anbieter in den USA Ihre Daten verarbeiten. In diesem Fall ist es möglich, dass die übermittelten Daten durch lokale Behörden verarbeitet werden. Weiterführende Details finden Sie in unserer  Datenschutzerklärung, die am Ende jeder Seite verlinkt sind. Die Zustimmung kann jederzeit durch Löschen des entsprechenden Cookies widerrufen werden.