![]() Registered Member ![]()
|
So I\'ve got these perfectly tagged MP3s using the MB-Tagger, with ID3v2 included.
amaroK hoses these regularly, primarily due to accidently clicking a title or something twice in the playlist. I lose the ID3v2 tag, even if no information is changed. I would never use amaroK for tagging (due to ID3v2 usage in my own databases), and all my files are perfectly tagged before they get added to my collection. There\'s no way to prevent these *accidents* from occuring. A way to tell amaroK \"Don\'t ever touch my MP3 tags!\" is very necessary, especially when they can be so easily hosed by an accidental click in the playlist. Second option: When this happens, it saves the tag whether any info was changed or not. A simple comparison which determines \"don\'t save the tag if nothing\'s changed\" would also avoid this situation. |
![]() Moderator ![]()
|
Nope, but you have alternatives:
1) make your files read only 2) set the sticky flags for the amaroK app to user/group with permissions to only read the files |
![]() KDE Developer ![]()
|
The undo/redo buttons really should work with tags.
Amarok Developer
|
![]() Registered Member ![]()
|
Changes in 1.3: \" When editing tags in Playlist Window, only try to write the new tag if it\'s different from the old one.\"
Woohoo, thank you! This solves the problem I was having. ![]() (Side note, referring to previous post above: From what I\'ve seen, Undo doesn\'t fix the tag. I still end up EasyTag-ging it again.) |
![]() KDE Developer ![]()
|
Yes I know that, I\'m just saying that it should.
Amarok Developer
|
![]() Registered Member ![]()
|
Ah. \'kay. Just read it wrong.
![]() |
Registered users: bartoloni, Bing [Bot], Google [Bot], Yahoo [Bot]