1212 Unsynchronized Tags false for recent edit [#5214]

[chrisjj]

With [X] Update tags when editing properties
1 In a tracklist track tag, press F2 and type some characters. Do not press ENTER.
2 Click on Unsynchronized Tags

Expected: list does not include the edited track
Observed: list does include the edited track

The same happens if after 1, ENTER is pressed and with little delay, 2 performed.

It appears Unsynchronized Tags is failing to wait for the tagging queue to empty.


mod edit:
http://www.ventismedia.com/mantis/view.php?id=5214

[Lowlander]

Not necessarily unexpected.

If you have a long tracks to be tagged cue you would need to wait endlessly for the Unsynchronized Tags node to load. I would prefer that over waiting till all tags have been written. maybe a small delay if few tracks are to be tagged, a info popup indicating tags are still being written or an auto-refresh could be a solution.

[chrisjj]

If you have a long tracks to be tagged cue you would need to wait endlessly for the Unsynchronized Tags node to load.

No.

a) The wait would not be endless - only until tagging was complete
b) the wait needs affect only completion, not start of loading, and given the relative speeds of the operations, most of the time the delay would be zero.

[Lowlander]

In you case you might have zero wait, I have done many mass tagging's where it can take minutes before all tracks have been updated (or longer if tracks are stored externally). So a having to wait either for the start or the completion would be more of a hassle then the having incorrect tracks show up. Especially as no damage is done by showing the incorrect tracks (at most a user decides to synchronize tags while it wasn't needed).

Furthermore the user could be running background tasks that might result in false positives like volume analyzing (although I don't know if difference in volume level in tags vs. database flags files). Then there are scripts that can trigger tag changes. These processes could lead to tag changes during the loading of the Unsynchronized Tags node. All this leads to scenarios that the Unsynchronized Tags node could return false positives.

That being said, I do understand your point. I just don't like your solution to this as it would adversely affect some users in my opinion. This is why offered some alternative solutions. An other solution would be to ask a user to start showing the Unsynchronized Tags node immediately or wait till tracks are tagged, that would be a compromise solution that gives the user the choice of what action to take.

[chrisjj]

> So a having to wait either for the start or the completion would be
> more of a hassle then the having incorrect tracks show up.

I disagree. The incorrect results are a real PITA and have already wasted a good deal of my time.

> This is why offered some alternative solutions.

I look forward to seeing them in the Mantis entry.

[Lowlander]

I think it would be more useful to have other users join in on the discussion and see what they would like MediaMonkey to do in the situation. This unless you claim that 1212 has a change in this behavior from previous beta's or even 3.0.

[Teknojnky]

If there are pending tag/database updates in progress during an unsync tags load, then ideally the track list for the affected files should be updated/removed as needed once the updates are commited. If they are not, then that IMO would be a bug or flaw.

I don't use the unsync tags much due to very large library and takes long time for it complete (most likely due to disk access speed limitations, external usb/firewire drive).

[Lowlander]

Although I in theory agree with the auto-update there is one issue with this solution as well. If you're already working on the Unsynchronized Tag list any updates can result in movement in the list which would be annoying for those who started editing/reviewing the result. It also can raise the question of when the list is finished loading (including all updates) which can be unclear for the user.

I think that this is why the current implementation exists as this is a tough issue to deal with on such a variety of systems and users. I think a simple message "MediaMonkey is tagging in the background do you want to continue?" with wait option or similar might be the best solution as it allows the user to choose what suits him/her best.

I don't use the unsync tags much due to very large library and takes long time for it complete (most likely due to disk access speed limitations, external usb/firewire drive).

I'm not aware if filters already solve this issue, but this is why I asked a long time ago to have the ability to limit the scope of Unsynchronized Tags as for me it's the same issue. Worse even is that I have a very large list of tracks unsynchronized tags that I'm not interested in at the moment. For me being able to limit to a folder would be ideal as I only care to run it on my verified to collection.

[Teknojnky]

If filters did not apply to unsync tags (or any files to edit nodes), then I would consider that a bug. I will try to verify later when I have time to let unsync load unless anyone can confirm in the mean time.

[Lowlander]

Sorry, I didn't mean to say it didn't work. I just said I don't know as I haven't tried out filters + files to edit yet, sorry.

[Teknojnky]

I will start a new thread to avoid hijacking this thread, but the unsync tags node does not appear to respect the current active filter selection, in debug log viewer I see it reading tags of all files not in filter.

[Teknojnky]

I suspect the root issue, which possibly affects many different things, is that when you start a process/script with a song list object, the song list object is static and not updated if subsequent operations affect the tracks within it.

Other examples where this happens (or happened) are volume analysis undoing track field edits (ie update a field while the track is a volume analysis queue).

Not knowing the internals of MM, I can't say how easy or difficult it would be to have all songlists objects be updated if any of their contained tracks are updated.

[chrisjj]

volume analysis undoing track field edits (ie update a field while the track is a volume analysis queue).

Yowch! Please do post a link to the bug report!!

That could certainly explain mysterious missing tags edits suffered by me and I suspect many other users.

[chrisjj]

unless you claim that 1212 has a change in this behavior from previous beta's or even 3.0.

Uh?? Are you saying reports of long-standing bugs are not welcome?

[chrisjj]

The NOTREP marking on this thread is false - the reported behaviour is indeed reproduceable and this topic has no report to the contrary.

Would a mod please remove the NOTREP marking? Thanks.