Fehlersuche · Directory Opus 13
Directory Opus 13: Wenn deine Rename-Presets nach dem Update streiken
Nach einem Update griffen plötzlich fast alle meine gespeicherten Umbenennungs-Presets nicht mehr — die Vorschau zeigte einfach keine Änderung. Die Ursache lag aber nicht in meiner Konfiguration, sondern im Programm selbst. Hier die komplette Spurensuche und die Lösung.
Ich nutze in Directory Opus seit Jahren eine ganze Sammlung gespeicherter Rename-Presets — für MP3-Dateien, für Bilder fürs WordPress-Blog, für das Umbenennen von Dropbox- in Android-taugliche Dateinamen und so weiter. Diese kleinen Helfer laufen so zuverlässig, dass man sie irgendwann gar nicht mehr bewusst wahrnimmt.
Bis sie nach einem Update auf Version 13 von einem Tag auf den anderen nichts mehr taten.
01Das Symptom
Ein typisches Preset von mir soll aus einem Dateinamen die führende Tracknummer entfernen — aus 12. alphaville.txt soll alphaville.txt werden. Dafür lief der Modus „Regular Expressions + Find And Replace“ mit einem simplen Suchmuster:
Old name: \d{1,3}\.\s*
New name: (leer — die Nummer soll ja weg)
Das hat jahrelang funktioniert. Nach dem Update aber blieb die Vorschau unverändert: In der Spalte „New Name“ stand exakt der alte Dateiname. Das Muster griff schlicht nicht mehr. Kurioserweise liefen einige andere Presets weiter — ausgerechnet die einfachen. Genau dieser Widerspruch war am Ende der entscheidende Hinweis.
02Die Eingrenzung
Statt blind an einem Preset herumzudoktern, habe ich ein funktionierendes neben ein kaputtes gelegt und verglichen. Der Unterschied lag nicht im regulären Ausdruck als solchem, sondern an einem unscheinbaren Detail: Alle Presets, die nicht mehr funktionierten, verwendeten einen Quantifizierer in geschweiften Klammern — also Ausdrücke wie \d{1,3} („eine bis drei Ziffern“).
Die noch laufenden Presets kamen entweder ganz ohne diesen Quantifizierer aus oder liefen in einem anderen Modus. Damit war klar, wo ich suchen musste — und der nächste Schritt war ein Blick ins offizielle Support-Forum, statt weiter zu raten.
03Die Ursache: ein Bug in Directory Opus
Im offiziellen Directory Opus Resource Centre wurde ich fündig — und zwar an einem aktuellen Thread, in dem ein anderer Nutzer genau dasselbe Phänomen beschrieb. Die Antwort kam direkt von den Entwicklern bei GPSoftware: Es handelt sich um einen bestätigten Fehler.
Regex-Quantifizierer wie {1,3} wurden im Modus „Regular Expressions + Find And Replace“ nicht mehr korrekt verarbeitet. Im reinen Modus „Regular Expressions“ funktionierten sie weiterhin. Laut GPSoftware wurde der Fehler als Nebenwirkung eines anderen Fixes in der Version 13.21.6 eingeschleppt — also kein Konfigurationsfehler auf meiner Seite.
Kleine Ehrlichkeit am Rande: In dem Thread gab es kurz zwei verschiedene Versionsnummern für den Ursprung des Bugs; die Entwickler haben sich am Ende auf 13.21.6 festgelegt. Ich gebe hier den Stand wieder, auf den sie sich geeinigt haben.
Das erklärte rückwirkend alles: Warum nur die Presets mit {} betroffen waren, warum die einfachen weiterliefen, und warum am Verhalten meiner Konfiguration objektiv nichts falsch war.
04Der Workaround (ohne Update)
Wer nicht sofort updaten möchte, kann das betroffene Preset auf den Modus „Regular Expressions“ (ohne „Find And Replace“) umstellen. In diesem Modus tritt der Bug nicht auf — man muss den Ausdruck nur etwas anders aufbauen und mit einer Capture Group arbeiten:
Modus: Regular Expressions
Old name: \d{1,3}\.\s*(.+)
New name: \1
Der Unterschied zum Find-And-Replace-Ansatz: Statt nur den unerwünschten Teil zu „löschen“, fange ich den Teil, den ich behalten will, aktiv ein und setze ihn als neuen Namen. So zerlegt sich der Ausdruck an 12. alphaville:
12
verworfen
.
verworfen
alphaville
→ \1
Im Feld „New name“ steht dann nur \1 — also genau der eingefangene Rest. Alles davor (Nummer, Punkt, Leerzeichen) fällt weg, weil es nie in eine Gruppe gepackt wurde.
05Die eigentliche Lösung: das Update
Der Workaround ist sauber und funktioniert — aber die wirkliche Lösung ist, den Fehler dort zu beheben, wo er sitzt. Und genau das hat GPSoftware getan.
Der Bug wurde in Directory Opus 13.23.8 (Beta) korrigiert. Nach der Installation dieser Version liefen bei mir sämtliche Original-Presets im Find-And-Replace-Modus wieder genau so, wie es die Anleitung beschreibt — mit Quantifizierer im „Old name“ und leerem „New name“.
Ein Hinweis zur Einordnung: 13.23.8 war zum Zeitpunkt meiner Recherche eine Beta. Wer ausschließlich auf stabile Releases setzt, fährt bis zur Übernahme des Fixes in eine reguläre Version mit dem Workaround aus Schritt 4 völlig problemlos. Am einfachsten prüft man über Hilfe → Nach Updates suchen direkt in Directory Opus, welche Version angeboten wird.
Zum direkten Vergleich noch einmal beide Wege nebeneinander:
Find And Replace
✗ Bug in 13.21.6 – 13.23.7
Old: \d{1,3}\.\s*
New: (leer)
Regular Expressions
✓ Funktioniert immer
Old: \d{1,3}\.\s*(.+)
New: \1
06Kleiner Exkurs: Was (.+) und \1 bedeuten
Für alle, die hier zum ersten Mal über Capture Groups stolpern — die Mechanik ist schnell erklärt. Runde Klammern ( ) in einem regulären Ausdruck bilden eine Capture Group: Der Teil des Treffers, der in den Klammern landet, wird gemerkt und kann anschließend wiederverwendet werden.
Die einzelnen Bausteine:
. → ein beliebiges Zeichen
+ → ein oder mehr davon
.+ → ein oder mehr beliebige Zeichen
(.+) → dasselbe, aber der Treffer wird als Gruppe gespeichert
\1 → Verweis auf diese erste Gruppe
Ohne Klammern würde .+ den Text zwar finden, ließe sich aber danach nicht erneut ansprechen. Erst die Klammern machen aus einem Treffer eine nutzbare Variable — und mehrere Gruppen lassen sich entsprechend mit \1, \2, \3 usw. ansteuern.
07Fazit
Wenn nach einem Update von Directory Opus plötzlich Rename-Presets nicht mehr greifen, lohnt sich vor dem stundenlangen Konfigurations-Debugging ein nüchterner Blick: Sind ausgerechnet die Presets mit Quantifizierern in geschweiften Klammern betroffen? Dann ist die Wahrscheinlichkeit hoch, dass nicht die eigene Konfiguration schuld ist, sondern dieser Bug.
Die Handlungsoptionen sind überschaubar: entweder auf 13.23.8 (Beta) oder neuer aktualisieren, oder die betroffenen Presets vorübergehend auf den Modus „Regular Expressions“ mit Capture Group umstellen. Beides bringt einen wieder ans Ziel.
Und ganz nebenbei eine ungewohnt angenehme Erkenntnis für jeden, der beruflich mit IT zu tun hat: Manchmal liegt der Fehler eben doch nicht bei einem selbst.


