Hallo liebes Forum,
seit ein paar Tagen haben ich ein kleines Problem beim Öffnen der Subcrates: Bei jedem Auf- oder Zuklappen derselben friert die Benutzeroberfläche für 5 Sekunden ein, unabhängig von der Menge der Subcrates oder der Titelanzahl. Der aktuelle Titel spielt aber problemlos weiter.
Der Rechner hat 4 GB und einen T9400 Prozessor. Die CPU-Auslastung kommt während dieses Vorgangs gerade mal auf 55%. Im englischen Forum gibt es einen Thread zu dem Thema, der mir allerdings nicht weiterhalf.
Gleichzeitig hatte sich auch das gleich Problem mit dem Lesen von ACC-Dateien nach Drag&Drop in die Player ergeben (Benutzeroberfläche friert ca. 5 Sekunden ein). Das konnte ich mit der Aktualisierung von Itunes/Quicktime allerdings weitgehend lösen, auch wenn mp3 immer noch eine Tick schneller eingelesen werden.
Irgendwelche Ideen? Schonmal Danke.
Beste Grüße
eavo

PS: Virenscanner ist aus - soweit man Norton abschalten.

kann.

hast du deine files auf einer externen hd mit dem format FAT32?

nein, intern ntfs.

Weiviele Tracks? Wieviel Crates? Mal versucht das zu reproduzieren mit einer fast leeren Library?

Hey, jetzt versuch doch bitte nicht zu helfen Eavos Weltansicht zu zerstören. Wo sind wir denn hier? Etwas in nem Hilfeforum oder was? Nenene...

-s

Hi Nik und Forum,
danke, dass Ihr mein Weltsicht zerstört. Also derzeit sind es ca. 19000 Tracks und so grob geschätzte 200 Crates.
Reproduktionsversuch gerade gescheitert. Tatsächlich besteht das Problem dann nicht, wenn ich den Scratchlive-Ordner probeweise umbenenne. Meint Ihr das liegt an der Zahl der Crates und Stücke oder eher, dass ich mir was in der Struktur des Scratchlive-Ordners durchschossen habe?
Beste Grüße
eavo

SSL schliessen, "database v2" umbennen in "database v2.old", SSL neu starten. Problem noch da?

hi nik,
ausprobiert. ohne erfolg. veränderung: fast alle längenangaben der songs sind weg und werden erst wieder sichtbar, wenn die songs abgespielt werden, bzw ich overviews baue (letztere sind allerdings noch da).
beste grüße
eavo

Dann ist eventuell etwas an Deinen Crate Dateien defekt. Tritt das nur bei bestimmten Crates auf?

Gibt´s doch gar nicht!

Habe seid meinem Gig letzte Woche genau das gleiche Problem. War von einer auf die andere Minute da. Hatee erst nen Crate wo auf einmal keine Tracks mehr drin waren. (Wer mir die geklaut hat wüsste ich gerne!)Zeitgleich fing auch der andere Fehler an.

@nik: der fehler tritt bei allen subcrates auf.

Logisch, ist doch ein Dual-Core.
Hast Du einen link?

@LosMintos: ja, ist ein dualcore. im task manager steht trotzdem nur ein wert, auch wenn der 'verlauf der cpu-auslastung' zwei graphen anzeigt (die sind aber beide im mittleren bereich, keine peaks).
scratchlive.net
das problem ließ sich so nicht lösen (war ja auch eher ein test) - trotzdem wurde das problem überraschenderweise als gelöst markiert.

Natürlich steht da nur ein Wert, da das die CPU Belastung für diesen Prozess auf die *komplette* CPU Leistung ist. Ein Thread alleine wird nie mehr als (100% geteilt durch die Anzahl der Kerne) haben.



Weil... der Moderator nicht hellsehen kann und nicht weiss, ob das Problem nicht schon behoben ist, aber der User einfach zu faul zum antworten war? ;)

Hast Du das alles ausprobiert was dort steht?

Hm, ich hätte den Thread offen gelassen ... Na ja, der User dort nutzte Version 1.7.4. Ich hoffe, Du hast eine neuere Version, andernfalls mach ein Update ...

Der Test scheint sinnvoll, würde ich auch mal probieren, kostet ja nicht viel Zeit.

Was war eigentlich anders vor ein paar Tagen? Sind Dir Änderungen bewußt?

Threads werden nach einer gewissen Zeit von den Mods geschlossen. Da der Thread aus 2007 ist und der ursprüngliche Poster nicht mehr geantwortet hat, ist er wohl geschlossen worden. AFAIK kann der urspr. Poster jederzeit auf den Thread antworten und neu eröffnen.

Dann würde das auch in meinen Augen Sinn machen ;-)

@LosMintos & Nik: ja, habe die 1.8.2. drauf. habe ich bereits probiert. mir sind keine änderungen am system bewusst, ausser dass ich mein ganzes serato vor drei wochen auf mein neues notebook übertragen habe, da lief es aber anfangs problemlos (wobei ich das jetzt nicht beschwören kann, zumindest ist der fehler nicht aufgefallen).
ich erinnere mich allerdings daran, dass ein ganzer crate mit ca. 30 subcrates nach dem rechner-umzug doppelt war und ich den gelöscht habe.
wie die auslastung des dualcores angeht - sorry keine ahnung, klingt logisch, was du sagts. habe gerade nochmal die sache überrpüft: tatsächlich geht der linke core für ca. 5 Sek bis auf ca 90% hoch - gibt also viel zu rechnen, aber nicht bis zum anschlag wie zb beim erstellen der overviews.
der test war insofern nervig, dass danach alle tracklängen der mp3s fehlten (genauso wie bei dem versuch mit der database V2).

wie=was

Wie gesagt, mach das was dort beschrieben ist.

das habe ich doch. die crates sind dann schneller. nach restore des alten scratch live folders, ist wieder alles genauso lahm und ich die zeiten fehlen.

Wo steht, dass Du das alte Verzeichnis restoren sollst?

scratchlive.net ganz unten "After this test you ..."

Es ist ja nur ein Test, er soll ja nicht seine Crates wegwerfen, soweit ich das verstehe.

Welches Crates sind das denn?

also ich habe den alten scratchlive-ordner aufs desktop gezogen. nach neuem programmstart von serato hat serato einen neuen scratchlive-ordner generiert. daraufhin habe ich ein paar songs in serato geladen und subractes in drei ebenen angelegt. diese öffneten und schlossen sich schnell.
Nachdem ich den alten ordner wieder zurückverschoben (='restored') habe, war das problem wieder da.

Der schwierige Teil ist es, den Punkt zu finden, an dem es langsam wird ;-) (Welches Crate, wieviele Crates, welcher Track, wieviele Tracks ...)

das ist schwierig. ja. habe gerade schon eine große menge überflüssiger crates gelöscht - ohne erfolg. überflüssige tracks sind leider etwas aufwändiger zu separieren.

wobei das ja überhaupt die frage ist, ob es an der quantität der tracks und crates liegt. kann ja auch sein, dass das library-system irgendwie durchschossen ist (habe leider keine ahnung von der inneren struktur des scratchlive-ordners).

Asche über mein Haupt... ich glaube Zach war da nicht sehr genau mit seiner Beschreibung. Ich denke sinnvoller ist es (und das habe ich da auch leider reingelesen, obwohl es so nicht da stand, sorry), wenn man Crate für Crate die Dateien zurückkopiert und nicht das ganze Verzecihnis.

Genau, nachdem der Test ergeben hat, dass eine leere Library (oder nur wenige Crates) schnell ist, sollte man sich Stück für Stück an den kritischen Punkt herantasten. Also entweder die große Library reduzieren bis die Crates hinreichend schnell öffnen oder eine leere Library solange befüllen bis es langsam wird. Natürlich behält man den Backup dabei ;-)

die frage ist, ob es überhaupt an der fülle liegt? wenn ich zach richtig verstehe, hat die menge der songs und crates keinen oder nur einen geringen einfluss.

Dann müsste ja auch eine Library mit zwei Crates und je 10 Titel schon sehr langsam sein. Kannst Du das bestätigen auf Deinem Rechner?

Abgesehen davon gibt es auch User mit "großen" Libraries, die mit der Geschwindigkeit zufrieden sind.

nein, die laufen schnell. alledings ist das dann ja auch nagelneuer scratchlive ordner. interessant wäre es eventuell den ordner zu sichern und dann alle crates im scratchlive order zu löschen und zu sehen, was dann passiert - quasi rückbau statt neubau.

Oh Mann. Genau. Ignorier' doch einfach mal die Vorschläge. Ich glaube Du willst gar nicht, dass Dir geholfen wird :-)

Tschö und Good-bye Thread.

*unsubscribes*

ähm.. es heisst ja jetzt "stop tracking this discussion"

was ist denn jetzt mit dir los, nik? warum sollte ich die vorschläge ignorieren? nach den vorschlägen hier im thread konnte ich jetzt schon zweimal neue overviews für alle tracks bauen, was jeweils ca. 20h dauert (wenn du mir sagen kannst, wie ich die länge der stücke einfacher wieder herstellen kann, wäre ich dir denkbar, mit rescan id3-tags gehts jedenfalls nicht).
ich will jetzt erstmal das wochenende abwarten, bevor ich an der library weiter rumschraube.
ich weiss auch nicht was an der frage so igorant sein soll, ob es wirklich an der menge der stücke und crates liegt, immerhin sagt zach von rane im internationalen, dass das keinen einfluss hat, wenn ich seine ironische bemerkung richtig verstehe.
naja, danke trotzdem.

Erstelle mal die Overviews neu! -- Ein viel gelesener Ratschlag, oft vorgebracht. Leider selten sinnvoll.

Schau mal in die Datei rein. Wie sieht das Tag aus? Steht da eine Zeit drin? Welches Format?

--

Zur Größe der Library und der Schnelligkeit: Das ist leider schwer zu beurteilen. Es ist mühselig, den Grund zu finden, aber ein mögliches Prozedere wurde Dir genannt. Nik39 wollte nur zum Ausdruck bringen, dass Du das erstmal probieren sollst und Dich dann mit neuen Erkenntnissen wieder meldest. Man sollte nicht alles auf die Goldwaage legen ;-)

Weil bei einem Vorschlag du kommst und behauptest es könne ja daran nicht liegen!

naja, das war jetzt auch nicht sooo schwer zu verstehen, was er meinte. jedoch ist tatsache, dass ich hier nichts behaupte, dazu kenne ich mich mit serato viel zu wenig aus. die frage ist eher, ob man hier nicht nochmal nachfragen darf, bevor man seinen rechner wieder für 20 stunden blockiert? immerhin habe ich hier ja nicht aus dem blauen dunst heraus nachgefragt, sondern vor dem hintergrund eines posting eines rane-mitarbeiters im englischen forum.

lösung! für den fall, das jemand das gleiche problem hat und diesen faden hier findet: die crates im scratchlive-order zu löschen und crate für crate zurückzukopieren ist mir nicht gelungen. die ordner wurden nicht mehr angezeigt in scratchlive und ich musste mein backup nutzen.

mein problem ist allerdings jetzt gelöst. ich habe festgestellt, dass in einem unterordner fast sämtliche tracks aus der library enthalten waren - wie die da hingekommen sind ist mir unklar, evtl aber ein versehen. ich habe die stücke gelöscht und seitdem öffnen sich die subcrates auch wieder zügig wie früher.

auch wenn nik etwas gereizt reagiert hat, danke ich euch allen für eure hilfe.