Version: 2.0 beta3 (using KDE 4.1.2) OS: Linux Installed from: SuSE RPMs KDE 4.1.3 (someone should add that to the bugzilla) I just wanted to edit the id3 tag of a whole new album that I have. So I was going through every single file and edited the song title. After 10 or so songs amarok was getting pretty slow. The metatag editor would take 10 seconds to save & close, the next time 30 seconds and then even 3 minutes. So I closed amarok after that and restarted and some of the changes had not been saved so I had to reenter the song titles. I also tried to edit a whole album making the first letters of the album name capital letters. I saved & closed the changes but after restarting amarok the changes were gone.
I can confirm the behavior for 2.0-rc1 and svn trunk that amarok forgets about changes made to id3 tags that were empty before. It seems that changing contents of existent id3 tags works.
I am using Amarok 2.0 with KDE 4.1.3 and the bug is still there. It is the same with assigning the "Various Artists"-flag (or whatever it maybe) to a single music file. These are not forgotten after a restart but take longer to perform the more you assign. In this case it doesn't matter if the file is already tagged or not. The output looks like this: amarok: BEGIN: void Playlist::ViewCommon::trackMenu(QWidget*, const QModelIndex*, const QPoint&, bool) amarok: END__: void Playlist::ViewCommon::trackMenu(QWidget*, const QModelIndex*, const QPoint&, bool) - Took 1.5s amarok: BEGIN: void Playlist::ViewCommon::trackMenu(QWidget*, const QModelIndex*, const QPoint&, bool) amarok: END__: void Playlist::ViewCommon::trackMenu(QWidget*, const QModelIndex*, const QPoint&, bool) - Took 1s amarok: BEGIN: void Playlist::ViewCommon::trackMenu(QWidget*, const QModelIndex*, const QPoint&, bool) amarok: BEGIN: void Meta::SqlAlbum::setCompilation(bool) amarok: [WARNING!] NOT-IMPLEMENTED: void Meta::SqlAlbum::setCompilation(bool) amarok: User selected album as compilation amarok: BEGIN: virtual void Meta::Album::notifyObservers() const amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::AlbumPtr) amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.0011s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00093s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00032s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00032s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.0003s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00031s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00031s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.0003s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00032s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00026s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.0003s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00028s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.00031s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.0003s amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::AlbumPtr) - Took 0.013s amarok: END__: virtual void Meta::Album::notifyObservers() const - Took 0.014s amarok: END__: void Meta::SqlAlbum::setCompilation(bool) - Took 2e+02s amarok: END__: void Playlist::ViewCommon::trackMenu(QWidget*, const QModelIndex*, const QPoint&, bool) - Took 2e+02s As you can see "Took 2e+02s" is a really long time (was more than 3 minutes, I think). Maybe it has something to do with the following three rows where it states that the setCompilation method is not implemented: Meta::SqlAlbum::setCompilation(bool) amarok: [WARNING!] NOT-IMPLEMENTED: void Meta::SqlAlbum::setCompilation(bool) While this operation is going on, you can't do anything else in Amarok the window is "frozen". Sadly, you currently can't just select multiple files and make them count as "Various Artists" by rightclicking and selecting the fitting option. If you do so, only the file where you rightclicked will be filed under "Various Artists".
*** Bug 177702 has been marked as a duplicate of this bug. ***
I am using a recent SVN version of Amarok and editing tags stopped working. The changes are not being written the the files. Please let me know if you need additional information on this issue.
This happened to me very recently. I kept editing a tag but Amarok would not save it. Unfortunately I don't have any output :(
*** Bug 178410 has been marked as a duplicate of this bug. ***
Created attachment 29528 [details] Output of amarok -d including failed change of id3 tags
*** Bug 178004 has been marked as a duplicate of this bug. ***
I'm currently trying to debug this problem. What I need to know is the following: Is this problem a regression or an old bug? "Regression" means, it worked a while ago in Amarok 2, but then it stopped working. "Bug" means, it has never worked in Amarok 2.
Ok, the class is clearly buggy in a number of ways. I've inserted lots of debugging code and found some issues. E.g. this here: amarok: BEGIN: void TagDialog::storeTags(const Meta::TrackPtr&) amarok: [TagDialog] TagDialog::TAGSCHANGED amarok: [TagDialog] TagDialog::SCORECHANGED amarok: [TagDialog] TagDialog::LYRICSCHANGED amarok: END__: void TagDialog::storeTags(const Meta::TrackPtr&) - Took 0.004s amarok: END__: void TagDialog::storeTags() - Took 0.0041s amarok: BEGIN: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void Playlist::Model::metadataChanged(Meta::TrackPtr) - Took 0.0013s amarok: [TagDialog] Tags not editable. Aborting loop. I'll try to fix it up.
SVN commit 900336 by dmeltzer: QFile::isWritable is apparently not accurate. Use this construct instead. Please test to see if it works. CCBUG: 174984 CCBUG: 177058 M +4 -2 collection/sqlcollection/SqlMeta.cpp M +2 -1 meta/file/File.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=900336
It seems that tags won't get saved if one modifies and saves tags from the filebrowser via "Edit track details".
Have you updated to latest svn?
yes
It seems to be working for me now. Thanks.
@Michael Seiwert: What you describe seems to be a different bug. If I open the context menu in the Files browser, the "Edit Track Details" entry is always disabled. So the dialog cannot be opened in the first place. I'll try to fix that. But if I drag an album from the Files tab to the playlist, the tag editing works fine (of course the album must be in the collection). So I think this report can be closed.
Update: "Edit Track Details" _does_ actually work from the Files tab, if the track is in the collection. I initially made the mistake to click on the directory instead of the file. </stupid>
It should work even if the file is not in the collection...
@Dan: I've tested editing id3 tags of files which are not in the collection again, and it seems that one can edit artist, track, title, tack, comment, genre but not composer and disc number could you please have a look at this ? Btw. Should I open a new bug report for this ?
Created attachment 29886 [details] Patch solving tag saving issue of files not in the collection Could anybody please review and apply the attached patch which should solve the tag saving issues (discnumber, composer) mentioned in comment #19 ? Thx!
SVN commit 905370 by markey: Allow setting the "discnumber" and "composer" tags for local files. Thanks for the patch go to Michael Seiwert <seiwert@kde.org>. CCBUG: 174984 M +6 -10 File.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=905370
Created attachment 29893 [details] Patch removes spurious space which prevented the display of changed "composer" tag for flac files please review & apply. Thx!
*** Bug 179704 has been marked as a duplicate of this bug. ***
Change the composer of a file outside collection now works. But the discnumber doesn't get saved. The new value doesn't stay in the field when focus leaves the field.
@Rindert: Saving the discnumber works for me with latest svn. What do you mean by "doesn't stay in the field when focus leaves the field" - Does it mean that if you set the discnumber to say 1 and swich to edit genre the discnumber ist lost ? Which filetype are you editing (mp3, flac, ogg ...) ?
After playing with meta data some more, I found out that setting discnumber (or year or track) to "0" (zero) or any other value does work and does save it as it should. But setting any of year,track and discnumber to "" (nothing) doesn't save the entered value and put back the of old value. This behaviour is for files in and outside of a localcollection. So it might be more a bug of the used widgets in the metadata-dialog.
Try using the down arrow in case of the discnumber to set the discnumber value to "".