View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000010 | MMW v4 | DB/FileMonitor | public | 2003-01-29 22:02 | 2006-07-07 01:11 |
Reporter | rusty | Assigned To | |||
Priority | low | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Summary | 0000010: Import: forces desynchronization b/w database and ID3 properties | ||||
Description | Upon importing songs, Song-DB is automatically populated with guesses of the file properties, however, this info isn't propagated to the ID3 file. This is painful to the user because the user perceives that file properties are based on (or are equivalent to) ID3 info, but the information that is presented to the user is based on the database contents (which differ from the tag info). Making it worse is the fact the user is not even made aware of the fact that the 2 data sets don't match. Possible solutions are: a) to have some kind of flag/coloration indicating that ID3 tag info is inconsistent b) to avoid guessing file properties in the first place, thereby avoiding the problem c) to update the ID3 tags with the guesses Jiri pointed out that c) isn't really an option since a DB scan should be read-only. I prefer the first solution, since it allows for the value-add of the 'guessing' but also helps the user know where additional organizing work is needed. | ||||
Additional Information | See bug #89 for high-level info. | ||||
Tags | No tags attached. | ||||
Fixed in build | |||||
|
I propose to add an option for scanning - do not use filename information. The coloration would require storing many information about where the information came from, probably better would be to show a dialog after the scan, where user would see all proposed guesses and could confirm them as well as specify if ID3 tags should be updated for all of them. |
|
OK, that should resolve this bug, somewhat. I would suggest that the default be: ( ) Guess Album/Title when tags are missing (o) Do not guess Album/Title p.s. when you tag a bug as suspended, the only way for me to add a comment is to re-open it. I would suggest that if you wish to defer action on a bug to a future release, to change the priority to 'low' (is this what you meant by 'suspend'?) |
|
I am not sure here. I would prefer to guess these info by default, but then DB and tags would not be synchronized. This could be solved by showing a dialog with a list of guessed information in red and user could confirm which are valid and if tags should be updated. However, this approach is not possible for automatic scanning of new songs in a folder. |
|
If the app were to guess information by default, then it would need a way of identifying id3 tags that are inconsistent with the db. The approach you propose is ok, but is a bit onerous, since it potentially forces the user to go through this activity all at once when they import there files (imagine importing 1000 files!!). You had previously indicated that an implementation involving coloration would require storing metadata about the information, but here's another idea: -User imports data via db scan & db automatically guesses info -User is given some kind of warning along the lines of 'Guessing Album/Title can occasionally lead to incorrect guesses. You can verify this data via the 'Inconsistent Tags' node under 'Songs to edit'. -The user clicks the inconsistent tags node and the application does a live comparison of the DB vs. tags and lists all titles for which inconsistency exists. He/She can then modify the DB entry/Tags as appropriate. (Everytime the user goes back to this node, a new live query would have to be done). Note: I still don't believe in guessing the tags at scan time as this is an organizational task that the user should initiate. If this is the default behavior, though, we should also at least have a means of configuring (at scan time) the means by which the app guesses the tags (this could prevent what happened to me: I have like 100 songs where the Album is called 'My Shared Folder'). |
|
It is already being fixed in other bugs. (Correct me if I'm wrong). |
|
Jiri, can you mark this one as resolved:fixed once you implement optional guessing (per metabug #89)? Once you tag this as fixed, I'll test the optional guessing functionality. Note: bug #77 is for the textual changes to the settings UI and not for any functional changes. |
|
Raising priority to match bug #89. |
|
After bug #9 was fixed, this seems to be unimportant. Now user can quite well control what is used during the scan phase (see Options|Library) and possible inconsistencies are solved by Out-od-date tags node. |
|
Changed to severity:minor, priority:low. It does seem much less important now, but I want to test on users before closing this one completely. |
|
This has long been sufficiently resolved. |