MakeCD-Problem: Abstürze, Hänger, ...

amiga-news.de Forum > Amiga, AmigaOS 4 > MakeCD-Problem: Abstürze, Hänger, ...

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

24.12.2002, 12:13 Uhr

Schofl
Posts: 20
Nutzer

Hilfe!
Seit Neuestem gibt es bei mir ein Problem mit MakeCD V3.2c und V3.2d.
Es äußert sich wie folgt beim Einlesen von Audiodaten aus gekauften
oder gebrannten Audio-CDs sowohl mit als auch ohne einer Liederliste
(Progdir:Tracks/#?.mcd) auf meine Festplatte:

V3.2c, nicht lokalisiert, unregistriert:
MakeCD 3.70 (5.11.99)
SCSISupport.module 14.29 (5.11.99)
makecdromfs.module 11.3 (5.11.99)
ReadWrite.module 15.61 (5.11.99)
CDR_SCSI3_ATAPI.driver 13.90 (5.11.99)
Brik-Test: alles ok
Im Schreibfenster kommt unterschiedlich spät, meist bereits nach ein
paar Sekunden, der "Software-Fehler"-Requester mit einem Guru 3 für
den Convert-Prozeß. Direkt danach kommt ein Requester von MakeCD, der
einen Lesefehler meldet: Nur 1243062 von 26288 Blöcken konnten von CD
gelesen werden. Klicke ich auf Stop oder Abbruch, bleibt dieser
Requester mit einem Guru 0100000f in einer Dauerschleife hängen.

V3.2c, lokalisiert, registriert auf DAO:
Programmversionen wie zuvor
Brik-Test: MakeCD BAD, Rest ok (wegen Registrierung)
Fehler wie zuvor

V3.2d, lokalisiert, registriert auf DAO:
MakeCD 3.77 public beta 10
SCSISupport.module 15.1 public beta 10
makecdromfs.module 11.3 (5.11.99)
ReadWrite.module 16.0 public beta 10
CDR_SCSI3_ATAPI.driver 14.5 public beta 10
kein Brik-Test
Im Schreibfenster hängt der Rechner nach unterschiedlicher Zeit,
stürzt ab oder einer der drei Prozesse fürs Lesen, Wandeln oder
Schreiben - derzeit meist Schreiben - bleibt stehen. Dies geschieht
meist nach einigen Sekunden. Auch kann der Lese-Prozeß mit Guru 3
hängenbleiben. Der Schreibprozeß wartet auf Signale, die nicht kom-
men. Mit einem Assembler-Entwanzer und eine Systemmonitor konnte ich
feststellen, daß der "Write-Process" in einer Endlosschleife stecken-
bleibt, in der ein ReplyMsg() und ein GetMsg() unmmittelbar hinter-
einanderfolgen. Das mn_Length-Feld zeigt $77fb und das erste Langwort
der Nachricht, auf das im Verlauf der Schleife getestet wird, hat ei-
nen Wert von $5cfa09fb, nicht etwa 0 bis etwa $10! Deshalb verbraucht
der Prozeß dann auch die komplette restliche Prozessorzeit. Ein Ein-
schreiben einer NULL für Message, mit dem notwendigen Ändern der
Register, hat keinen Erfolg, da dann der "Write-Process" an einer
anderen Stelle hängenbleibt.

Kennt jemand solche Vorfälle? Mit meinem Latein bin ich vorerst am
Ende. Alle Dateien sind soweit einwandfrei und vom Internet herunter-
geladen. Ein neues Herunterladen und Installieren hatte keinen Erfolg.
Audio-Abspielen übrigens bereitet keine Schwierigkeiten, obwohl doch
die Daten ebenfalls geschrieben werden - wenn auch ins "audio.device".
Seltsamerweise meldet MakeCD beim Versuch, Audio-CDs mittels einer
Liederliste (.mcd) abzuspielen, einen Konversionsfehler, daß Typ $27
nicht in $21 gewandelt werden kann. Es liegt die richtige CD im Lauf-
werk. Daß MakeCD die CD-Audio-Daten nicht auf die Festplatte schreiben
muß, wie in der Liederliste steht, sondern ans "audio.device" schicken
soll, sollte das Programm eigentlich erkennen können.
Da der Fehler - zumindest so, wie er hier auftritt - früher nicht vor-
handen war, scheint es sich um eine Veränderung des Betriebssystems
(hä??) oder der Hardware zu handeln. Andere Programme habe ich in der
Zwischenzeit nicht installiert. Die Absturz-Probleme betreffen aber
nur MakeCD, nicht etwa andere Programme, die auch einen regen CD-,
Festplatten- und Speicherzugriff haben. Beide SCSI-Busse (s.u.) sind
einwandfrei terminiert und funktionieren auch sonst tadellos.
Was ist da los? Wer kann mir einen Tip geben?

Zuletzt noch meine Kiste: A2000C, Apollo 2030 Turbo (030+882 50 MHz),
32 MB 32-Bit-RAM, 1 MB Chip-RAM, ECS, CGX 64/3D, 2 Oktagon 2008 mit
der letzten Firmware-Version von Oktagon selbst. Seagate Cheetah 34,1
GB und TEAC CD-R56S600 (6fach-Brenner). Platte und Brenner laufen auf
jeweils einer Oktagon-Karte. Die Festplatte ist gekühlt wegen 15.000
UpM. 48-cm-Monitor. Kickstart-ROM 3.1 und Softkick 3.9, derzeit ohne
BoingBags. Die Puffergröße für das Einlesen der Audio-Daten liegt bei
1470 kB mit einer Segmentgröße von 294 kB (kgV von 2352 und 2048
Bytes). Somit liest der Brenner mit rund 10facher Geschwindigkeit.

Gruß Wolfgang

[ - Antworten - Zitieren - Direktlink - ]

24.12.2002, 12:24 Uhr

thomas
Posts: 7718
Nutzer

Hört sich nach einer Speicherverletzung an. Hast du es mal auf einem "sauberen" AmigaOS ausprobiert ?

Hast du ihm mal mehr Stack gegeben ?

Hast du mal ein anderes Programm, das CDDA auslesen kann, ausprobiert ?

Hast du mal einen RAM-Test durchgeführt ?

Hast du mal auf Hitze geachtet ? Gehen alle Lüfter noch ?

Versuch mal einen runden Wert als Puffer zu nehmen, sodaß es nicht genau auf die Blockgröße paßt. Vielleicht schreibt er hinten drüber und erwischt etwas, was er lieber nicht überschreiben sollte.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

04.01.2003, 23:38 Uhr

Schofl
Posts: 20
Nutzer

Danke, Thomas!
Mit 'nem reinen OS 3.1 und ohne irgendeine Startup-Sequence habe ich dieselben Probleme gehabt (richtig: gehabt). Der Stapelspeicher war ebenfalls ausreichend, andere Programme funktionieren soweit einwandfrei. Das RAM ist in Ordnung und Hitzeprobleme gibt es keine. Einen anderen Wert als 294 kB zu nehmen - z.B. 256 kB oder einen ähnlichen Wert - hat bei mir nur die Auswirkung, daß die Datenübertragung auf 1,2fache Geschwindigkeit heruntergeschaltet wird.
Den eigentlichen Fehlerverursacher für die meisten meiner eingangs erwähnten Probleme habe ich endlich nach vielen Basteleien gefunden: eine unglückliche Einstellung der Task-Priorität des Oktagon-SCSI-Host-Adapters, an dem der Brenner hängt. Die war auf 2 gestellt und damit hat sich offenbar der Write-Task von MakeCD verschluckt - insbesondere, da letzterer ja eine Priorität von 6 hat.
Nun sind die Prioritäten beider Oktagon-Karten bei 8. Das Einzige, was mich jetzt noch stört, ist, daß sich immer wieder MakeCD sowohl beim Audio-Lesen einer CD als auch beim Schreiben (bislang nur TAO umfangreich probiert) gerade dann aufhängt, wenn ein neues Lied geschrieben werden soll (egal, ob auf Festplatte oder CD). Der Eingangspuffer ist voll und die bei mir eingestellten 20 MB Puffer wurden von CD bzw. Festplatte auch geladen. Da bislang keine Schreibunterbrechung innerhalb der Lieder - und somit ein Untersetzer - produziert wurde und ich ja im TAO-Modus an der Stelle weitermachen kann, ist das vielleicht verschmerzbar. Allerdings ist das noch nicht perfekt! Wer weiß Rat?
Noch eine Kleinigkeit gefällt mir an MakeCD nicht besonders: seine Dokumentationswut. Ich brauche keine .cdt-Dateien, die beim Einlesen eines Liedes von CD erstellt werden. Wie kann ich MakeCD zum Schweigen bringen? Und wie überrede ich MakeCD dazu, die angelegten Dateien nicht bis zum Abschluß einer Serie von Liedern geöffnet, sondern gleich schließen zu lassen? Dann wären die Lieder sofort für andere Programme verfügbar. Sollte ein Absturz erfolgen sind nämlich so auch alle Dateien von Disk-Validator weggeputzt! Wer weiß da Abhilfe?
Noch ganz kurz: Ich finde es toll, wenn sich leidgeplagte Amiga-Besitzer gegenseitig helfen. Weiter so! Danke
Gruß Wolfgang

[ - Antworten - Zitieren - Direktlink - ]

12.01.2003, 20:14 Uhr

Skyrider
Posts: 63
Nutzer

Hallo Schofl,

hast du beim Oktagon Controller schon mal eine negative
Priorität getestet ? Ich hatte bei CD-Brennen damals auf Probleme
mit MakeCD. Ich hatte die Priorität auf -1 weil sonst die GUI von
MakeCD hing.

Ich habe einen Yamaha CDR400t daran betrieben und von IDE CDROM und
Festplatte gebrannt.
Ausserdem musste ich für den Brenner Reselection abschalten.

CU SkyRider

[ - Antworten - Zitieren - Direktlink - ]

12.01.2003, 21:05 Uhr

Schofl
Posts: 20
Nutzer

Hallo, Skyrider!

Zitat:
hast du beim Oktagon Controller schon mal eine negative
Priorität getestet ? Ich hatte bei CD-Brennen damals auf Probleme
mit MakeCD. Ich hatte die Priorität auf -1 weil sonst die GUI von
MakeCD hing.

Danke auch Dir für Deine Anmerkung. Was ich festgestellt habe, ist, daß die GUI immer langsamer wird, je höher die Prioritäten der beiden Oktagons eingestellt werden - insbesondere desjenigen, an dem der Brenner hängt. Dabei wird aber das Brennen selbst immer sicherer.
Nun habe ich ja den Kompromiß (ich hasse Kompromisse - warum kann denn ein Computer nicht 'mal richtig funktionieren?) gefunden, die Prioritäten auf 8 einzustellen. Damit klappts einigermaßen, ohne Untersetzer zu produzieren.
Ich werde versuchen, in der nächsten Zeit das mit Pri=-1 auszuprobieren, obwohl ich da wenig Hoffnung habe, daß der Brennprozeß störungsfrei abläuft. Immerhin wird dann ja ein simpler Task von Pri=0, der den Prozessor fordert, den Datenstrom zum Brenner abreißen.
Reselection mußte ich bei meiner Kiste kpl. abschalten, da sich der Brenner sonst aufhängt. Das scheint ein verbreitetes Problem bei allen SCSI-Geräten zu sein. Vergeblich suchte ich nach einem Schalter für Synchrontransfer in OktagonPrefs. Den wirds wohl nicht geben - das Handbuch schweigt sich auch aus. Der nämlich würde mit Sicherheit helfen, die Datenmengen 'rüberzubekommen.
Gruß Wolfgang

[ - Antworten - Zitieren - Direktlink - ]

13.01.2003, 01:10 Uhr

Skyrider
Posts: 63
Nutzer

@ Schofl

Benutzt du die OktaPussy Treiber aus dem Aminet ?

Die sind für CD-R optimiert.
Haben bei mir wesetlich besser funktioniert als die auf der
Treiber Diskette. Sind auch aktueller.

CU

SkyRider

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Amiga, AmigaOS 4 > MakeCD-Problem: Abstürze, Hänger, ...

[ - Suche - Neue Beiträge - Registrieren - Login - ]