# \[X\] Massenänderung Cover-Typ führt zu Absturz

**URL:** <https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166>\
**Category:** Fehlermeldungen\
**Created:** [November 26, 2012, 5:45am UTC](https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166 "2012-11-26T05:45:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [November 26, 2012, 5:45am UTC](https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166/1 "2012-11-26T05:45:12Z")

</div>

Beim Ändern des Covertyps von "other" auf z.B. "Front" stürzt MP3tag letztlich ab.

Man nehme: einige tausend Dateien (also so 3000).  
Rechts-Klick auf den Platzhalter für Cover im Tag-Panel.  
Wähle Cover-Typ Front  
Drücke Speichern.

Mp3tag beginnt, die Tags zu speichern, bricht dann aber nach einigen ab mit der Fehlermeldung, dass die Datei nicht geschrieben werden könne.  
Nach Bestätigen mit OK erscheint die Meldung erneut aber für eine andere Datei.  
Dieses Spiel wiederholt sich ein paar Mal, bis MP3tag schließlich die Meldebox für schweren Fehler zeigt.  
Anschließend lässt sich MP3tag nur noch über den Task-Manager beenden.

Nimmt man kleinere Mengen Dateien (dreistellig) scheint der Fehler nicht aufzutreten.

Der Fehler trat bei derselben Tätigkeit auf mindestens 2 unterschiedlichen Rechnern, die von 2 unterschiedlichen Benutzern mit unterschiedlichen Dateien befüllt waren, auf.

---

<div class="post-metadata">

**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\
**Post date:** [April 4, 2013, 5:52pm UTC](https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166/2 "2013-04-04T17:52:34Z")

</div>

Ich hab's mit 3200 Dateien mehrmals ohne Probleme probiert.

Tritt der Fehler immer noch auf?

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [April 4, 2013, 6:00pm UTC](https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166/3 "2013-04-04T18:00:10Z")

</div>

kann ich erst morgen noch einmal testen ... (so oft nudelt man den cover-typ ja auch nicht um ... ;-))

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [April 5, 2013, 4:12am UTC](https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166/4 "2013-04-05T04:12:25Z")

</div>

> [@ohrenkino](#):
>
> kann ich erst morgen noch einmal testen ...

Guten Morgen!

Der Fehler ist nicht mehr aufgetreten.  
Im EInsatz war 2.54b

Getestet habe ich an 11000 Dateien  
mal mit gesetztem Filter (NOT %\_covers% IS "" AND NOT %\_cover\_type% HAS Front)  
mal völlig ohne.  
Ich habe den covertype mal auf BACK und dann wieder zurück auf FRONT gesetzt.

UND KEIN FEHLER.

Nun muss man allerdings auch sagen, dass das Testumfeld nicht ganz das gleiche war, wie damals, da sich die Datengrundlage geändert hat.  
So sind etliche "unsichtbare" streams aus den Dateien verschwunden, es gab keine Dateien mehr mit covertype "other", die MP3tag-Version war 2.54 und nicht 2.54b.  
Kurz und gut: damals war der Fehler reproduzierbar, jetzt nicht mehr.

---

<div class="post-metadata">

**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\
**Post date:** [April 5, 2013, 7:18am UTC](https://community.mp3tag.de/t/x-massenanderung-cover-typ-fuhrt-zu-absturz/14166/5 "2013-04-05T07:18:23Z")

</div>

Super, danke für's Testen und Deinen Report.