Library file could not be written

[MartDann]

Ein kleiner Erfahrungsbericht meinerseits (und vielleicht etwas Thead hijacking, aber es passt dazu), da mein Foobar zurzeit auch nah an der Grenze operiert wo die Library nicht mehr gespeichert wird.
Also, bei ist es so das die Library erst nach einiger Spielzeit nicht mehr geschrieben wird, deshalb hab ich letztens auch (nachdem ich den einen Thread in Hydrogenaudio gelesen habe) bei allen meine Files die Embedded Album Art gelöscht (die meisten habe ich auch noch extra in einem anderen Verzeichnis abgespeichert), mit dem Effekt, das es bei mir (leider) überhaupt nix gebracht hat.
Die Library ist hat nach wie vor dieselbe Größe und kann nach einiger playtime kann die Library wieder nicht abgespeichert werden.

Aber falls irgendwer noch andere Ideen zum Thema "Library File could not be written" hat, wäre ich gern bereit Vorschläge anzunehmen.

Threadsplit von hier - grimes

[AldiMp3]

@MartDann,

sicher ist nichts, könnte auch ein erneuter Bug sein, der nur unter bestimmten Bedingungen auftritt und nichts mit der Datenbankgröße zu tun hat. Wenn ich darüber nachdenke, was ich zwischenzeitlich getan habe, fällt mir nur ein, daß ich foo_playcount und foo_run nutze. Egal was die Ursache ist, der Datenbestand muss so oder so in eine sinnvolle und schlange Struktur gebracht werden.

Gruß AldiMp3

[huber71]

... da mein Foobar zurzeit auch nah an der Grenze operiert wo die Library nicht mehr gespeichert wird.

ab wann ist denn damit zu rechnen ?

[Frank Bicking]

Eingebettete Bilder haben im Normalfall keinen Einfluss auf die Größe der Library. Entsprechende Tags werden (bis momentan angezeigte Bilder) nicht im Arbeitsspeicher gehalten und genausowenig in die database.dat oder Playlists im FPL-Format geschrieben.

Wir hatten bisher erst einen Fall, bei dem Bilder auf eine Weise in den Tags vorkamen, die nicht dem Standard entsprach, und dementsprechend als Textdaten behandelt wurden. Leider hatten wir damals versäumt, uns nach der Herkunft dieser Tags zu erkundigen. Ich habe den Nutzer inzwischen angeschrieben und hoffe auf baldige Klärung.

Sollte es sich hier nicht um die gleiche Ursache handeln, dann wäre es wirklich hilfreich, wenn du dein Problem näher ausführen könntest. Über welche Größenordnungen reden wir hier? Wieviele Tracks befinden sich in deiner Library, wie groß ist die aktuell geschriebene database.dat? Wie groß wird die .fpl-Datei wenn du deine Library über File, Save Playlist speicherst?

Falls das vom Verhältnis her weit über die 55 MB für 150.000 Tracks hinaus gehen sollte, die ich im obigen Thread als Vergleichsgröße genannt hatte, dann wäre die nächste Frage, ob du sonstige große Datenmengen (Lyrics, Biographien, EAC-Logs) in den Tags gespeichert hast.

[MartDann]

So aus dem Kopf (bin gerade in der Mittagspause in der Firma)
Tracks ca. 65k
Library war gestern ca. 200 mb (wobei ich gestern geeinige nicht benötogte Tags gelöscht habe und dadurch auf ca. 190 mb runter gekommen bin)
fpl abgespeichert ist meines Wissens nach genauso groß (habe eine Autoplaylist mit allen Tracks), kanns zuhause auber dann noch genauere Angaben geben.

Außerordentliche Tags: ein paar Biography (aber gestern unter anderen eleminiert)
Lyrics für ca. 2/3 der Tracks

[Cabalist]

hmm, wieso is die so riesig? Meine "database.dat" is bei mehr Tracks nur 76MB groß (hab auch zu Standard Tags noch bei ca. 75% der Songs Lyrics Tags mit drin, Biography Kram speichert hier das Biography View ja in nem extra Ordner, dürft die DB nich stören).

[tedgo]

200MB für 65.000 Files ist wirklich ganz schön groß...
Ich habe derzeit 23.000 Titel in meiner Library (bin gerade am neu Enkodieren) und meine database.dat ist knapp 28MB groß.
Dabei habe ich meine Files mit allen nur erdenklichen Tags versehen (u. a. haben alle embedded artwork und Lyrics).

Das macht einem ja Angst, dass es ein Limit gibt, an dass ich irgendwann - wenn ich mal alle meine CD's in der Library habe - stoßen werde... 

[grimes]

Ich halte 200MB bei 65000 Titeln für realistisch.

Bei mir: 37MB/19000Titel hochgerechnet auf 65000Titel ergibt 127MB.
(Zur Erklärung: Ich habe z.B. ellenlange "Biography"-Tags und "Lyrics"-Tags)

[MartDann]

Ja, ich habe auch noch andere Tags(FOOID, MUSICBRAINZ, z.T Discogs), aber Lyrics bzw Bio sind ja eher die die größer sind....
Wobei...sehe gerade, FOOID ist 848 Byte lang, macht also bei der Anzahl schon mal grob 55MB aus.

[huber71]

entspannt zurücklehn':

27.5 MB Datenbank bei 44,000 Titeln (keine Biographys, keine Lyrics, aber komplett embedded art mit z.t. fetten jpgs)

[Gen. Bully]

17484 Titel. Database 9MB. Normal getaggt. Nix Biography. Keine Cover. Fast keine Lyrics.
Hm, ich dachte ja echt ich hätte eine große Musiksammlung...

[grimes]

Wie lautet denn die genaue Fehlermeldung?

"library file could not be written (bad allocation)".

??

Dann:
foosion:

Code Auswählen Erweitern

The "bad allocation" error indicates that foobar2000 has run out of memory.
http://www.hydrogenaudio.org/forums/index.php?showtopic=77701

Du hast in einem anderen thread geschrieben, foobar2000 benötigt 800MB RAM.
Unter Vista habe ich teilweise auch 700MB RAM-Belegung (bei 2GB RAM) durch foobar2000, sodaß ich insgesamt 80-90% RAM-Auslastung habe. Das ist aber nicht schlimm, benötigt eine andere Anwendung RAM wird der Wert für foobar2000 z.B auf 150MB reduziert.

Hier im Forum gab es auch schon mal das Problem:
http://foobar-users.de/index.php?topic=1778.0

bei 50000 tracks, RAM-Belegung unbekannt, Lösung des Problems unbekannt, nur scheint ein Zusammenhang mit der Anzahl der tracks der Media library nicht gegeben.

Wieviel RAM hast Du zur Verfügung?

[MartDann]

Ja, das ist die genaue Fehlermeldung.

Ram ist eigentlich kein Problem, habe 4 GB (zurzeit aber auch 80-90 % Ramauslastung, laufen noch einige andere Sachen.
(Habe aber noch nicht gesehen das Foobar reduziert wird, wahrscheinlich aber aufgrund des noch verfügbaren Phys. Speichers).

Stimmt ja, Vista ist ja Großzügig bei der Speicherzuteilung, erinnere mich gerade das ich da mal was aufgeschnappt habe...

Hast also Recht, muss nicht wirklich im Zusammenhang mit dem Ram stehen...