I've had some instances where mp3tag needed permission to access a network folder, but since updating to 1.7.3. and MacOS 13.2, I'm getting this error only on files that already have album art:
Is there a permissions issue or hack I should try?
Not sure if it's about files with or without album art (the topic title says something different than what you write in the post).
BackLog is an option to gain some insight to what's happening. You can set the process to Mp3tag and send the logged events.
Sorry for that confusion. I am using a Macbook to connect to NAS drives on my local network; the NAS drives have sharing and permissions open to all devices on the local network and this issue only happens with mp3trag on my Mac.
There are three things going on and I can't tell which is the root cause:
- I can write FLAC files with and w/o image art
- I can write MP3 files that already have album art
- I cannot write MP3 files w/o album art (this may be coincidental)
Here's the reoccurring error (I've removed path info):
2023-02-05 18:03:43.192-0500 -- Mp3tag (Mp3tag) -- Exception at writing MP3 metadata to '/xx/K_Alexi_Shelby--Compute-(GMND010)-WEB-2014-BABAS/02-k_alexi_shelby--the_way_home-f9ecc6c0.mp3': Seek offset out of range.
2023-02-05 18:03:43.286-0500 -- Mp3tag (Mp3tag) -- Cannot write tags to file "02-k_alexi_shelby--the_way_home-f9ecc6c0.mp3" in folder "K_Alexi_Shelby--Compute-(GMND010)-WEB-2014-BABAS" (cannotWrite(file:///xx/K_Alexi_Shelby--Compute-(GMND010)-WEB-2014-BABAS/02-k_alexi_shelby--the_way_home-f9ecc6c0.mp3))
2023-02-05 18:08:32.448-0500 -- Mp3tag (Mp3tag) -- Exception at writing MP3 metadata to '/xx/Kafkactrl-006-(ZMNT006)-Vinyl-2022-DPS/01-kafkactrl-interzone-dps.mp3': Seek offset out of range.
2023-02-05 18:08:32.505-0500 -- Mp3tag (Mp3tag) -- Cannot write tags to file "01-kafkactrl-interzone-dps.mp3" in folder "Kafkactrl-006-(ZMNT006)-Vinyl-2022-DPS" (cannotWrite(file:///xx/Kafkactrl-006-(ZMNT006)-Vinyl-2022-DPS/01-kafkactrl-interzone-dps.mp3))
A successful write on a FLAC file:
2023-02-06 07:02:14.771-0500 -- Mp3tag (Mp3tag) -- Cannot use atomic rename for temporary file '/xx/Ice_Cube-The_Predator-CD-FLAC-1992-PERFECT/01-ice_cube-the_first_day_of_school_(intro).flac.sb-8c1f1701-JJyCDl/01-ice_cube-the_first_day_of_school_(intro)-hNC73J.flac' to be renamed to '/xx/Ice_Cube-The_Predator-CD-FLAC-1992-PERFECT/01-ice_cube-the_first_day_of_school_(intro).flac'. Attempting to remove original and copy temporary file.
I've seen this issue a few times, but it was generally something I could fix by granting access to a folder when the program prompted for it. Granting that access without a prompt hasn't been successful.
Thank you for providing those details!
Does it work if you copy one file that produces an error on the NAS to your Desktop and perform the changes there?
The error looks like it's either a problem with the internal structure of the file (so it also won't work on your Desktop) or the NAS providing incorrect file stats for the file.
Odd...that worked.
Near as I can tell, this is a MacOS permissions issue, but other than when mp3tag requests permission for a folder, I don't know how I can pre-authorize that folder/drive permissions. Any ideas?
Yes, you can try this command via Terminal.app while Mp3tag being closed:
defaults delete app.mp3tag.Mp3tag SecurityScopedBookmarks
After that, load the folder (not the individual files) via ⌘O and see if the issue persists.
You can also load the root folder of the music on your NAS to pre-authorize everything that's inside (you can also cancel the reading process if it takes to long).
Darn, that unfortunately didn't work. Permissions are wide open on the NAS drive, which I should mention is on a Windows PC; Windows firewall is off.
I love the Mac version because it strips and overwrites the existing tag, where the windows version merges. If the Windows version could strip/overwrite, I'd solely use it.
Exactly the same errors in the log for me. Macbook SMB mounted to NAS, full permissions to NAS folders. If I use MusicBrainz Picard instead it works fine. Also if I copy the mp3 file locally and update the album art. Tried with both the Mp3tag App store version and the downloaded trial version
OK, thanks for chiming in. Is this also on a Windows NAS or are you using something different?
Hi! I have a Synology NAS
Some questions regarding the Synology NAS:
- Do you know which file system you're using on the Synology share?
- If you're using SMB, can you post a screenshot of the advanced settings at
Control Panel → File Services → SMB Settings → Advanced Settings?
I've just released Mp3tag for Mac v1.7.5 and hope to have fixed the issues both of you are experiencing. Please let me know if it's working now for you.
Thanks Florian. My NAS is NTFS, but I updated and that did the trick!!
That's why I paid for the Mac app, my friend...amazing program and developer.
1 Like
Many thanks for the kind feedback and for confirming the fix.
Glad it's working now for you and thank you for raising the issue initially. The combination of provided details made it possible to find and fix the cause of the problem.
Great support! I can confirm that it works for me also now
1 Like
Excellent! Thanks for confirming the fix.
Do you know which file system you’re using on the Synology?
Hi! Synology filesystem is btrfs and and smb is level 3
OK, thanks! I'm keeping notes of which combinations do show the problem.
An explanation for fellow developers:
ftruncate()doesn't work on certain file systems and network shares when the target size extends the current file size. A possible workaround is to usepwrite()to write one byte at the target size, thus, exceeding the size by one byte and then useftruncate()to truncate to the target size.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.