Cannot remove IDv1 or IDv2 tags at all - Mac version 3.2.0
Audio Tag Editor
Brought to you by:
ufleisch
Menu
▾
▴
#109 Cannot remove IDv1 or IDv2 tags at all - Mac version 3.2.0
The MacOS version cannot remove the IDv1 or IDv2 tag, in the way it is done on v3.1.2 of the software. Checked it many times before posting here. Reverted to 3.1.2 and works perfectly.
Whether on a DIR basis or FILE basis (left panel) clicking on "Remove" button (on the right) doesn't flag the file to be saved (as a change is happening). This is valid for either tags.
I am on Mavericks 10.9.5. Many thanks.
Discussion
Strange, I tried to reproduce this with different kinds of files, both on a local hard drive and on a slow SMB share. All tags can be removed without problems. I am on Mac OS X 10.10.3.
Does it happen with all files or only with a specific format (e.g. MP3 with ID3v2.3.0 tags)?
Do you have enough permissions?
Can the files be modified otherwise (e.g. are the files marked as modified when tag fields are changed, can the changes be saved) and it is only remove which does not work?
Are the files on a hard disk or on a network share?
If the files are MP3, could you disable the Id3libMetadata plugin in the settings, restart Kid3 and check if it is still happening?
Do you have more debug information (e.g. start kid3.app/Contents/MacOS/kid3 from a terminal and check if errors are reported or dtruss to monitor the process)?
Could you provide me an example file so that I can reproduce the issue?
Hello Urs and thank you for your immediate response. I will reply ASAP. What I can tell you is that I tried to open a folder that had M4A and MP3 songs, and tried to only edit (remove tags) from MP3 files. Luckily I had kept 3.1.2 and with 3.2.0 will try to replicate problem (on 10.9.5).
UPDATED:
My first bug encountered was the Open Directory feature. Please try it. My Mac has 3 HDDs and I open a folder from /Volumes/X/Y/Z not on main HDD. The moment it opens, there was a root/tree showing on the left panel, not the files (like in 3.1.2 or previous). This happens every time... pressing the RIGHT arrow on top of that left panel somehow ends up showing the MP3 files.
Then, when the files open/show (in tree mode) anything pressed (e.g. remove TAG which was my only action) doesn't register as action hence, no diskette icon!
Then, just as you suggest, I did another edit, this time 1st song changed comment. Diskette icon appears, but nothing is saved at all (when pressing top icon diskette). The file diskette icon is always there :(
If I quit the app, re-launch it and try to open 1 file itself, I still get that expanding folders/tree like you see in the screenshot, not the file itself in the left panel.
See my screenshow, please...
Many thanks.
P.S. Sorry I killed your surname in the comment/picture :-)
P.S. I can provide these MP3s, please contact me in private (which v3.1.2 could handle, obviously).
Last edit: Konstantinos 2015-05-07
I know about the problem with the "root node instead of tree", but I thought that it only occurs on the Mac when accessing files on a network share. This bug is fixed in the following development version:
http://sourceforge.net/projects/kid3/files/kid3/development/kid3-git20150325-Darwin.dmg
Could you please check if it also solves the other problems?
Hi Urs, yes this build seems to bring functionality back to normal, i.e. as expected. Many thanks. I confirm it's resolved (what I posted) as far as I did some quick testing now.
Two small requests, a) please create a bug/ticket group for 3.2.x (as we're forced to post bugs in 3.1.x group instead) and b) also I wanted to ask you:
1/ Top left icon, when mouse hovers, shows bottom text as "Open a directory" but it opens a file instead? Please confirm? I say this because the top window title says "Open" and MP3 files aren't grayed out, hence I must select one file? This is compared to going via the menu to choose "Open Directory" where files are grayed out...
2/ When MP3 files are edited/updated via iTunes (Mac) the MP3 tag group shows at the bottom an "Uknown" tag/field as ticked.This is not visible in non-iTunes edited MP3 files. Since track number is there, disc number too, I suspect it's "COMPILATION=TRUE" flag. Can you perhaps confirm this and/or fix/update this displayed field?
Apologies for posting 2 questions in the wrong thread... meant to write about these 2 long time now!
Last edit: Konstantinos 2015-05-07
I will soon release a bugfix version 3.2.1 so that no more users will be bothered by this bug. Until then I have put a new development release to
http://sourceforge.net/projects/kid3/files/kid3/development/kid3-git20150509-Darwin.dmg
built with the latest code. Could you please tell me if you find any problems?
Regarding the two requests:
Hello Urs, thank you for the updated dmg. I confirm that "kid3-git20150509-Darwin.dmg" works without my original bug (directory is displayed now OK, not as tree) and also the bottom hover text of main Disk icon says "Open files" indeed. Disabling the plugin as you suggested, removes the "Unknown" tag. It is your choice at the end of the day, to keep it pre-enabled or not, but your arguments are understood (especially for a plugin not maintained anymore)...
Thank you again for listening.
A final fix/touch: If you have option to provide title labels in the Open windows, as my eye is used to check the title on top (to understand functionality) kindly introduce "Open files" and "Open directory" instead of a simple "Open". That is, IF your call allows for non-generic text. Thanks... Same for the first "File" menu entry... adding "file(s)" is more clear functionality.
Please don't take me wrong, I am an UI professional and consistency/ease/navigation has been my middle name :-)
Fixed in version 3.2.1. The "Open" text is not changed for the following reason: The KDE version (originally the only platform and reason for the "K" in Kid3) uses "standard actions" with standard texts. Thus "Open" will stay "Open" in KDE and I want to keep the same UI texts in all versions.
Thank you Urs, it's been a pleasure talking to you. Good luck in your releases!