Summary: | Amarok2 doesn't update mp3 tags in its db when editing + crash | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Mikko C. <mikko.cal> |
Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | maximilian.kossick |
Priority: | NOR | ||
Version: | 2.0-SVN | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Mikko C.
2008-06-15 09:17:56 UTC
still happening with today's SVN Confirmed by me too. For some reason the SqlCollection (Local Collection)'s TreeView isn't getting updated, and I think that when you try to edit again, the TagDialog starts to get constructed, looks for the unchanged tag still in the TreeView, fails to find it, calls the TagDialog destructor, and crashes on a double-delete. Not sure of this yet though. The important thing to note here is that the TreeView isn't being updated. This is a bug by itself, and could be a cause of this bug. OK, I've temporarily stopped the double-delete which avoids the crash, but something is seriously wrong here, as the TreeView should be getting updated. Will investigate further. Not sure if this is an issue with sqlcollection not updating, or if its an issue with the view not updating, Do you know anything Max? We'd need some kind of 2PC here to make sure that the database and the file are in sync under all circumstances, which we won't implement. The actual reason for that crash was fixed a few days ago. The logic which updates the database on some changes is not quite correct, but that's another bug... Yea, the crash is fixed, but the tags aren't updated correctly until Amarok is restarted. That is not quite correct. Some tags are correctly updated (e.g. try to change the track title), some are not, for example the album (well, they are updated, but not correctly) You're right, editing the title works, but not more than once.. Ok, i won't bother you anymore since it seems you guys know where is the problem :) thanks I'm able to edit a title more than once from both the collection view and the playlist. The issue with editing Artist that I mentioned before is still present and the problem seems evident: the treeview isn't being updated. Question is, how to inform the treeview to update itself on tagchange. tell the collection to emit the updated signal, or change the collection browser filter. both will trigger a new query (the former way is obviously the correct one). Unfortunately it looks like there's still some logic missing to handle corner cases when changing track attributes that require SqlCollection to update foreign keys. On Sat, Jul 12, 2008 at 10:46 AM, Alejandro Wainzinger <aikawarazuni@gmail.com> wrote: [bugs.kde.org quoted mail] For IpodTrack, after editing many tracks using TagDialog, if you use the updated signal at the end of the metadata update, it creates a race condition with the next tracks to be updated, such that TreeItemModel's update method gets called an arbitrarily large amount of times, so this solution does not seem to work, or I am implementing it wrong. I see that Playlist::Model is making use of observers to deal with this problem, and I think that TreeItemModel could do the same, but I'm not familiar enough with the code to implement it. A temporary hackish fix could be to have the TagDialog emit the collection whose tracks are being edited's updated signal, but this is far from optimal I think. I just did that "hackish" fix but by means of a new UpdateCapability. Basically, whenever editing data gets done, the collections implementing this update themselves. I'm going to see if I can fix the update to preserve the state of collapsed/restored and where in scrolling the user was before the update, but no promises. See SVN commit 832869 for details. Is it just me, or now Amarok does update tags in its database correctly, but doesn't actually change the file's tag? Is this wanted? I hadn't noticed that. Well, the Sql stuff needs some good looking into, but I'll leave that to the Sql Foo black belts =) On Thu, Jul 17, 2008 at 12:56 AM, Mikko C. <mikko.cal@gmail.com> wrote: [bugs.kde.org quoted mail] |