playcount-replacement unterbricht Musik

Begonnen von fooamp, 03. Juni 2006, 13:46:18

« vorheriges - nächstes »

fooamp

03. Juni 2006, 13:46:18 Letzte Änderung: 28. Januar 2014, 21:02:22 von grimes
Hallo,

ich habe da so ein Problem mit dem playcount-replacement: defekter link entfernt - grimes

Über Sinn oder Unsinn, Abspielstatistiken in tags zu speichern, wurde schon reichlich auf hydrogenaudio diskutiert, mir sagt das Konzept zu - und damit gut. Mein Problem nun taucht dort zwar auch auf, wird jedoch nicht gelöst: http://www.hydrogenaudio.org/forums/index.php?showtopic=42625

Es ist folgendes, daß das plugin öfters (bei Vorbis mehr als bei mp3) den Spielfluß unterbricht, sprich: die Musik setzt aus. Dabei liegen die geschriebenen tags laut Konsole unterhalb eines kB. Andere derartige Aktionen machen bei mir keine Probleme (z.B. ReplayGain scan & write im laufenden Titel). Nun habe ich den playback-Puffer schon auf 2048 angehoben und den "Playback thread priority"-Regler munter hin- und hergeschoben - alles ohne Erfolg. Und mein 1,5 Banias kann einfach nicht zu langsam sein dafür... andererseits scheint nur eine Handvoll Nutzer davon betroffen zu sein.

Was tun? Hat einer von euch ähnliche Erfahrungen gemacht? etc.

Wie üblich Danke im Voraus.

wallawalla

Bei dem Plugin ist es auch bei mir so dass es sich komisch verhält. Bei mir setzt zwar die Musik nicht aus, aber immer wenn die Grenze wo dem Playcount-Tag ein Punkt hinzugefügt wird erreicht wird plopt für eine Sekunde ein fenster auf. Manchmal kommt foobar dann sogar in den Vordergrund. Aber dass die Musik aussetzt konnte ich noch nicht beobachten.

fooamp

Darüber, daß ein Fenster hochkommt, haben sich auf hydrogenaudio auch schon einige beschwert. Aber dies ist halt nur ein typisches update-irgendwas-Fenster, vielleicht wird der Autor es in einer späteren Version abschaltbar machen. Ich glaube aber nicht, daß das Fenster so viel Resourcen verschlingt, daß bei mir die Musik stockt; es wird eher was mit dem Schreiben an sich zu tun haben.

wallawalla

Was hast du denn für ne Platte wo die Musik liegt?

download123

Es sit nur so ne idee ich habe keine ahnung, aber kann es sein das das Plugin so geschrieben ist dsa es die Musik unterbricht um vollen zugriff auf die Datei zu bekommen, und sie nach der änderung sovort wieder anfährt ??? und je nach dem wie schnell das geht :...

Ist mir eingefallen, weil versucht mal eine datei währen dem Abspielen umzubenen..

Ja foobar kann während dem abspielen die Tags ändern, aber das ist ja kein Plugin

fooamp

03. Juni 2006, 15:14:57 #5 Letzte Änderung: 28. Januar 2014, 21:02:44 von grimes
@wallawalla
Eine "FUJITSU MHT2040AT" Notebook-Festplatte und eine "WDC WD16 00BB-98DWA0" USB-Festplatte. - War auch einer meiner ersten Gedanken, die Laufwerke könnten mit im Spiel sein, da sie nicht die allerschnellsten sind. Aber erstens geht es hier eben nur um einige Byte und zweitens habe ich ja auch den Puffer testweise hochgefahren (auch cachen die Laufwerke ja selbst). Und, wie gesagt, andere (wirklich prozessor- und speicherfessende) Aktionen machen keine Probleme.

Ich werd' mal den Puffer auf 10 MB hochsetzen (also auf weit über Trackgröße) - mal sehen, was passiert...


@download123
Hmmm, eigentlich unnötig - denn tags und frames sind in der Datei räumlich getrennt, sowohl bei mp3 als auch bei Vorbis - der mpeg-stream muß also nicht unterbrochen werden, wenn in die tags geschrieben wird.

Auch gibt der Autor keine besonderen requirements an, also gelten wohl die von foobar2000 selbst: requirements.html defekter link entfernt - grimes


Update:
Andererseits steht immer das Problem, ob "padding" oder nicht, also ob ein Zusatzraum freigehalten wird, um tags ändern zu können, ohne die ganze Datei neu schreiben zu müssen - ein Problem seit ID3v2 (http://www.audiohq.de/index.php?showtopic=22). Nun heißt es aber bei Frank Bicking an dieser Stelle, daß VorbisComment immer mit padding geschrieben wird (ich hab meine Dateien mit foobar2000 codiert, müßte mir also keine Sorgen machen). Und so ist es um so mehr verwunderlich, daß besagtes Phänomen bei Vorbis stärker auftritt als bei mp3. Könnte es sein, daß das plugin prinzipiell alles neu schreibt, ohne die Datei auf vorhandenes padding zu prüfen?

Wie dem auch sei: Ich bin mittlerweile bei einem Puffer von 16MB angelangt und nichts wurde besser! Das kann's also nicht sein.

Lego

Guten tag,

ich hab grad mal quer gelesen. Mir scheint es eher so, daß die Latenzzeit auf dem USB-Bus das Probleme ist. Witerhin sollte man die neuesten Versionen von Foobar2000 0.9 benutzen (aktuell Beta 4 0.9.2), da gab es IIRC in den vergangenen Wochen einige Updates bei denen es speziell um das schnelle Schreiben von Vorbis-Tags ging.

Ich spekuliere aber mehr darauf, daß der Rechner einfach durch die Latenzen und das Schreiben des Vorbis-Comments so über das USB/IDE Interface beschäftigt wird, daß eben die Musik aussetzen muss.

Tritt das Problem denn auch bei lokal gespeicherten Dateien so krass auf?

fooamp

03. Juni 2006, 18:42:32 #7 Letzte Änderung: 03. Juni 2006, 21:41:05 von fooamp
Hallo Lego,

vielen Dank für den Hinweis.

Einen möglichen Unterschied nach Laufwerken hab ich so jetzt nicht festzustellen versucht. Ich werde dann mal die Dateien nach Laufwerken abspielen - für den Fall, daß genau das zutrifft: Gibt es ein denkbares workaround?


Update:
Habe getrennt nach Laufwerken und noch mal getrennt nach Codecs abgespielt - ein Muster ist jedoch leider nicht erkennbar. Auf allen Platten dasselbe und bei allen Codecs (wie gesagt: Vorbis mehr als mp3). Nur eben nicht bei allen Stücken! Es ist aber auch nicht die Länge der Stücke. Ratlos, ratlos...

Lego

Ich werd mal übers Wochende versuchen was ich rausfinden kann, sowas wie einen Workaround jedoch ich (befinde mich noch in der Phase des simplen Ratens) keinesfalls in Aussicht stellen.

fooamp

Einige Tage später...

Mittlerweile läuft bei mir kein 0.9.1 mehr, sondern ein 0.9.2 - und: Das Problem hat sich fast erledigt.

Es scheint tatsächlich in der Hauptsache an der Schreibgeschwindigkeit für Vorbis Comment und ID3 gelegen zu haben. Die hat sich generell mit der neuen Version erhöht und also auch bei der Verwendung mit playcount. In vielen vielen Testreihen gab es bei mir nur noch einige wenige Aussetzer beim Schreiben der tags, mit denen ich leben kann. Sie traten nur dann auf, wenn ich den Rechner zusätzlich noch intensiv in Anspruch nahm. Vielleicht optimiert der Autor, dem das Problem bekannt ist, sein plugin ja auch noch weiter.

Warum es nur bei mir (und einigen Wenigen auf hydrogenaudio) auftrat, bleibt vorerst ungeklärt, einer der bisher genannten Gründe wird es schon gewesen sein (bei der Gelegenheit: Dank an wallawalla, download123 und Lego).

Fazit: Updaten hilft!

wallawalla

08. Juli 2006, 14:22:59 #10 Letzte Änderung: 08. Juli 2006, 16:48:23 von fooamp
Es gibt auch eine Version von Playcount (die offizielle) die keine Tags schreibt sondern die daten in die database speichert. Das Problem bei dieser Version ist dass die gespeicherten Informationen nach einem Verschieben oder Umbennennen verloren gehen.

Gen. Bully

08. Juli 2006, 15:30:45 #11 Letzte Änderung: 08. Juli 2006, 16:48:45 von fooamp
Zumindest in der 0.8.3 Version von Playcount kann man eine "DB Only Mask" definieren (file write is deferred). Keine Ahnung ob das jetzt in den 0.9er Versionen mit dem "inoffiziellen" Plug-In auch funktioniert und wann er die Tags dann aktualisiert. Jemand eine Ahnung? Beim beenden von Foobar vielleicht?

Frank Bicking

08. Juli 2006, 16:17:25 #12 Letzte Änderung: 08. Juli 2006, 16:49:20 von fooamp
Bitte streicht diese "database" aus eurem Sprachgebrauch.

Es handelt sich bei der Datei database.fpl lediglich um einen Cache (Zwischenspeicher) aller in die Library aufgenommenen Dateien und ihrer Tags, damit diese Informationen nicht jedes Mal neu von der Festplatte gelesen werden müssen. Unter Version 0.8.3 gab es einen Programmierfehler(!), der dazu führte, dass nicht erfolgreich geschriebene Tags dennoch in diesem Cache landeten, etwa weil das Taggen generell deaktiviert wurde oder der Dateityp bestimmte Felder oder Tags allgemein nicht unterstützte. Von einigen Nutzern wurde dieses Verhalten als Feature missverstanden und ausgenutzt.

Mit Version 0.9 wurde das Problem behoben, und Entwicklern in Grundzügen eine ordentliche Methode bereitgestellt, Daten außerhalb von Audiodateien zu speichern, wie etwa in einer externen Konfigurationsdatei, wie es die offizielle foo_playcount-Komponente macht. Diese Methode hat allerdings auch den Nachteil, dass Änderungen am Aufenthaltsort der Datei nicht entsprechend weitergeleitet werden, so dass nach dem Umbenennen oder Verschieben selbst mit Boardmitteln die Zuordnung zu den Feldern verloren geht.

fooamp

Allgemeiner Nachtrag

Mittlerweile bietet auch die offizielle Version ab 1.2 auf Wunsch die Möglichkeit, in tags zu schreiben (Prefereces|Advanced). Allerdings wird dies vom Entwickler nicht empfohlen. Auch werden nur %last_played_timestamp% und %play_count% geschrieben, nicht %first_played%. Desweiteren unterscheidet sich die Syntax:

offizielles plugin: %play_count% / inoffizielles plugin: %play_counter%
offizielles plugin: %last_played_timestamp% / inoffizielles plugin: %last_played%