Version: 2 beta 3 (using KDE 4.1.2) OS: Linux Installed from: Ubuntu Packages I right clicked on a bunch of files in the collection explorer. I was taken to the statistics tab where I edited the score field (I wanted to set a score/rating for a bunch of files to test out the dynamic playlist filters). When I clicked ok it appears to have left the meta title for each of the 949 selected files alone, but has unset the tag for every other field - Artist, Album, Year etc. At some point I had selected and then deselected 'per file' checkbox, but can't remember if I closed and reopened the window after that. This might be more of a usability issue than a bug, though it may be a bug because it unsets the tag. I'm not sure whether this affects 1.4.x. I might have expected it to leave the tag information alone unless I'd explicitly asked for it to be changed - e.g. I have found this useful in the past for correcting spelling errors in band names. Hurrah for backups!
Teo this is fixed by now right?
No, it is not fixed. Lydia, for huge data destructing bugs like these I think we should leave them open rather than close awaiting feedback. It's too dangerous to miss.
Seb I know there was another bug that is a dupe of this one and since it was no longer on my list of 2.0 bugs I assumed it was fixed. Sorry.
I can't reproduce it. Could you please provide us with more info, maybe with a simpler situation with 2 or 3 tracks and describe your steps in more detail?
I'm not sure if this is related or not but it's a close match. When I edit the tag for multiple entries (i.e. I was changing half the entries of a 2-disc set to disc 1, the others to disc 2) and I apply the tags, it all seems to work right. However, I'm not sure if this happens after a database change or not, when I go back to them the tag isn't there anymore but the original tags are still present. It's like Amarok doesn't write to the actual file and just holds it in it's database until it changes.
@Teo 1) Left click on 'Collection' 2) Expand so that two tracks - preferably different album and artist are visible 3) Select both tracks using ctrl + left click 4) Right click on one of the selected tracks and click 'Edit Track Details' 5) I am taken to the 'statistics' tab. Change the score to '56' then 'Save and Close'. Actual outcome: the collection refreshes (collapses). When you expand the tree the tracks that you edited appear to have disappeared. When you inspect them in the filesystem you find that the Artist/Album tags have been blanked. This appears to me to be a usability issue because at step (5) if I look in the 'Tags' tab the Artist/Album fields are blank - Amarok determined that those attributes weren't common. If however I select two tracks with common attributes (e.g. same Artist) then that field is filled in. So, in short, Amarok did what I told it to do - set Artist/Album to blank - but I didn't know it was going to do this because I wasn't editing that information.
This happens to me to for more than 2000 songs ... It occurs from the playlist (select several track in the playlist, right click, edit, go to the statistic tab, change the rating and save -> done, all the artist/album/year blanked It has to do with the way amarok want to handle massive tag editing: For example, if one selects two or more songs with a different 'album' tag, it is better to open the edit window with a grayed album field (aka not editable) as it is done for the name of the track. There should be an option to "explicitly" edit the tag even if it's different. Maybe one way to handle when editing several track : - for each field test if the information is the same in all the track. - If yes : make the field editable with the default value which is the same for all the tracks - If no : make the field uneditable with a default value "different tags, click to edit ..." with a gray background and in italic. - If the user click in the field, make it editable, default value should be the most representative value (10 tracks with "Aphex Twin", 2 with "Aphex Twi" and 1 with "APHEXTWIN" should default with "Aphex Twin") When the user click on save, only explicitly edited field should/will be saved. Is this reasonable ?
Yo, After a look in the code, here is a small patch which at least will protect the huge blanking stuff ... It's my first patch and i'm not exactly sure of the syntax, can anyone try it ? Index: src/dialogs/TagDialog.cpp =================================================================== --- src/dialogs/TagDialog.cpp (revision 883291) +++ src/dialogs/TagDialog.cpp (working copy) @@ -872,6 +872,13 @@ ui->kLineEdit_title->setEnabled( false ); ui->qSpinBox_track->setEnabled( false ); + ui->kComboBox_artist->setEnabled( false ); + ui->kComboBox_album->setEnabled( false ); + ui->kComboBox_genre->setEnabled( false ); + ui->kComboBox_composer->setEnabled( false ); + ui->kTextEdit_comment->setEnabled( false ); + ui->qSpinBox_discNumber->setEnabled( false ); + ui->qSpinBox_year->setEnabled( false ); ui->pushButton_guessTags->hide(); @@ -962,40 +969,47 @@ int cur_item; if( artist ) { + ui->kComboBox_artist->setEnabled( true ); cur_item = ui->kComboBox_artist->currentIndex(); m_currentData.insert( Meta::Field::ARTIST, first.value( Meta::Field::ARTIST ) ); selectOrInsertText( first.value( Meta::Field::ARTIST ).toString(), ui->kComboBox_artist ); } if( album ) { + ui->kComboBox_album->setEnabled( true ); cur_item = ui->kComboBox_album->currentIndex(); m_currentData.insert( Meta::Field::ALBUM, first.value( Meta::Field::ALBUM ) ); selectOrInsertText( first.value( Meta::Field::ALBUM ).toString(), ui->kComboBox_album ); } if( genre ) { + ui->kComboBox_genre->setEnabled( true ); cur_item = ui->kComboBox_genre->currentIndex(); m_currentData.insert( Meta::Field::GENRE, first.value( Meta::Field::GENRE ) ); selectOrInsertText( first.value( Meta::Field::GENRE ).toString(), ui->kComboBox_genre ); } if( comment ) { + ui->kTextEdit_comment->setEnabled( true ); m_currentData.insert( Meta::Field::COMMENT, first.value( Meta::Field::COMMENT ) ); ui->kTextEdit_comment->setText( first.value( Meta::Field::COMMENT ).toString() ); } if( composer ) { + ui->kComboBox_composer->setEnabled( true ); cur_item = ui->kComboBox_composer->currentIndex(); m_currentData.insert( Meta::Field::COMPOSER, first.value( Meta::Field::COMPOSER ) ); selectOrInsertText( first.value( Meta::Field::COMPOSER ).toString(), ui->kComboBox_composer ); } if( year ) { + ui->qSpinBox_year->setEnabled( true ); m_currentData.insert( Meta::Field::YEAR, first.value( Meta::Field::YEAR ) ); ui->qSpinBox_year->setValue( first.value( Meta::Field::YEAR ).toInt() ); } if( discNumber ) { + ui->qSpinBox_discNumber->setEnabled( true ); m_currentData.insert( Meta::Field::DISCNUMBER, first.value( Meta::Field::DISCNUMBER ) ); ui->qSpinBox_discNumber->setValue( first.value( Meta::Field::DISCNUMBER ).toInt() ); }
teo, can you comment on this?
Thanks everyone who provided more info. I'll review the patch as soon as possible.
I haven't been able to get blanked tags because when I follow Stephen's procedure Amarok crashes on me with a really weird backtrace. I'll confirm the bug as there's definitely something fishy going on with TagDialog here.
Oups doesn't really works after some more testing, forget about this patch version. The problem is in "applyToAllTracks()" method in TagDialog, if the value "" is different than the artist the tag will be marked has changed and written as "" Still searching for a workaround :)
Created attachment 28522 [details] Proposed patch ... Here is a second patch which should works better. After following Stephen procedure, I no longer have any trouble, and can rate several tracks at once without blanking the tags ... Now if someone select 2 or more tracks with differents tags, this tags are just uneditable ... Can be seen as a regression or has a temporary workaround ... Can someone test ? Thxs
I just added another bugreport for the behavior described in comment #5. Just to let Ian know. https://bugs.kde.org/show_bug.cgi?id=174984
*** Bug 174574 has been marked as a duplicate of this bug. ***
SVN commit 886276 by lfranchi: make sure the user has edited a text field before overwriting any changes when editing multiple tracks. note: i tried to break it, but am sure i missed some cases. please test! BUG: 174878 M +110 -72 TagDialog.cpp M +14 -1 TagDialog.h WebSVN link: http://websvn.kde.org/?view=rev&revision=886276
I have compiled from SVN and I can't break it. The new behaviour seems correct to me - thanks Leo.
This is happening again with trunk. Try editing two songs from different albums and artists. Maybe just to change the genre or rating: all the fields but the "Title" will be erased.
It seems that when the Tag editor dialog is opened, the slots : artistModified() albumModified() genreModified() commentModified() and only them no are invoked if the 2 selected songs have different tags. Hence, m_fieldEdited["artist"]; m_fieldEdited["album"]; m_fieldEdited["genre"]; m_fieldEdited["comment"]; are set to true and never unset. Then, when applyToAllTracks() is called, we store empty information in the corresponding field. TagDialog.cpp is not very easy to read so I don't understand how it should have worked properly :|
I believe that part of the issue is that editTextChanged() is emitted when the text is first set on the combobox. This results in m_fieldsEdited[*] always being true.
Exact, maybe just set m_fieldEdited.clear(); checkModified(); after the first init will be enough, no ?
Created attachment 31444 [details] TagDialop.cppp patch Little patch which solved the pb here, simply copy m_fieldEdited and restore it in the dataQueryDone() method, because this was what was messing and caused the slot editTextChanged() to be called, ending with the blanked tags in case of several track with different tracks ... Can someone test ?
SVN commit 930301 by lfranchi: don't erroneously mark a field as edited when we clear it manually to add completion items. thanks for the patch/inspiration go to Simon Esneault. as usual with TagDialog spaghetti code, touching one thing may subtly break 5 others. so please try to edit some track details and make sure the completions work OK as well as saving to file. CCMAIL: amarok-devel@kde.org BUG: 174878 M +10 -1 TagDialog.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=930301