When I use Quick Actions to import cover images from the tag field %CoverImagePath%, I get an error that the cover file cannot be accessed if the path is a UNC instead of a local address. Am I doing something wrong? The path looks like this:
\\192.168.0.56\d$\Music\_Ref\Cover\Album_cover.jpg
There are no issues opening a playlist containing UNC paths and updating the tags from a text file in which the MP3 files are UNC paths.
I just tried it.
The first problem I get: I can not enter a value into a field called COVERIMAGEPATH that starts with two backslashes like \\192.168.123.123
Are you sure that you have
\\192.168.0.56\d$\Music\_Ref\Cover\Album_cover.jpg
in your COVERIMAGEPATH?
Please show us a screenshot from Alt + T with that content.
Importing a cover from an UNC path (manually entered) in the Action works fine in my environment:
You are correct. Thank you for alerting me to this.
I used Convert: Text file - Tag to populate the tags. Although the leading backslashes are in the source text file, MP3Tag dropped them when importing the tags.
Here is the relevant line from the text file. The CoverImagePath value is the last column.
^|State Azure|Stillness|Stillness||2025||||\\192.168.0.56\d$\Music\Misc\State Azure--Stillness.mp3|\\192.168.0.56\d$\Music\_Ref\Cover\Stillness.jpg|$
Here is a screenshot after I imported the tags. The leading backslashes survived in the path column but not in the CoverImagePath column.
Mp3tag is using the double backslash \\ as separator for multiple values in tag fields. So if you're importing something like \\server\share via Text file - Tag, Mp3tag detects two values — one empty, one server\share — and imports the one which is not empty.
The correct workaround to the issue you're observing is manually adding the two missing backslashes to the format string at importing covers as described above.
Thank you for the explanation, Florian. Manually adding two backslashes to each file is rather cumbersome when tagging files in bulk. An escape character that would allow a backslash to be read as part of a field would be nice. Mapping the network drive is another alternative.
This is not what I meant. Instead, I was referring to
