Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [Bug] File Operations -> Rename (Read 1151 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[Bug] File Operations -> Rename

I frequently use the File Operations -> Rename function to batch rename albums into the file naming format I use throughout my library.  When I recently updated foobar to the newest version 1.3.14 I started having a problem I've never had before through many different versions and my File name pattern has always been the same.

File name pattern: %discnumber%.%tracknumber%. %title%

Which would give me either
01. Thunderstruck
if there was no value in the Disc Number

- or -

1.01  Thunderstruck
if there was a value in the Disc Number field.

However, now, with the exact same File name pattern it is producing this
[unnamed].01 Thunderstruck

So any file where the field is blank it fills in the %discnumber% variable with [unnamed].  I have attempted to clear the Disc Number field numerous times and there is definitely no value there.

Now I obviously could create 2 separate file name patterns for whether I have a multi-disc album or not, but wanted to pose the question on this since it seems like an odd development after all these years and would be further odd to me if it was intentional so thought I better pose the question.

Re: [Bug] File Operations -> Rename

Reply #1 –
Try [%discnumber%].%tracknumber%. %title%

Re: [Bug] File Operations -> Rename

Reply #2 –
Quote from: Rollin on
Try [%discnumber%].%tracknumber%. %title%

Thank you. very much  That did fix it.  Any idea if this change was intentional or if I was just using a sloppy syntax before that finally bit me in the backside?

Re: [Bug] File Operations -> Rename

Reply #3 –
The latter. Also, I'd include the dot within the brackets, else you will get filenames starting with a dot if there is no discnumber tag present and windows is sometimes very allergic to such files. The stuff enclosed in square brackets will only be added if the tag within is present. I do something similar when tagging my files, but I only prepend the discnumber if disctotal is > 1. And While we're at it, also replace any characters NTFS doesn't like:
Code: [Select]
$replace([$ifgreater(%totaldiscs%,1,%discnumber%.,)]%tracknumber%. [%artist% - ]%title%,':','：','*','＊','?','？','"','”','<','＜','>','＞','|','｜','/','／')

Re: [Bug] File Operations -> Rename

Reply #4 –
Interesting.  I don't know how I ever got away with that all this time.  Thank you for the detailed response.  Your file name pattern definitely leaves little if any room for error.  Just a curiosity, but on the topic of the unfriendly NTFS characters how is that being allowed with the characters you are using?  And will that ever cause any possible file system problems down the road?  It would certainly be nice to be able to have the question mark and full colon available for song titles.

Re: [Bug] File Operations -> Rename

Reply #5 –
The characters we are using are referred to as "half-width", while the ones I'm substituting them with are "full-width", so they don't have the same character code as the half-width ones, thus they are not forbidden in NTFS names.