Possible timing issue during update resulting in data fields being blanked out

bug-fixed
#1

Hello,

Recently I have been experiencing an intermittent situation of random occurrences of data loss when editing files with MP3Tag. I cannot say that the situation began with Version 2.80, but that is when I first noticed it. It has occurred on 2.80, 2.80b and 2.80c.

Due to the somewhat random nature of the events, I suspect that both timing and size of the music directories active in MP3Tag are contributing factors.

Problem description:

When editing multiple files, such as all of the tracks from a single disc, there are times when data in fields not [intentionally] being changed is blanked out for some of the records. This situation can impact one, two or several of the selected records.

One example of this problem is documented in the attached pdf.

The missing data can be visually restored by single clicking on the blank line or by using the Refresh File View function. However, if the file(s) are saved while some of the fields are blank, the blank data is written to the music files which results in a loss of data.

Observations:

The problem occurs frequently – perhaps 50% of the time – when the entire music library of 42k+ files are active in MP3Tag. The problem occurs infrequently, perhaps 10-20% of the time, when only 4k files are active. I have not noticed the problem occurring with less than 4k files loaded, but I haven’t performed exhaustive testing looking for the problem.

Configuration information:

The music files are stored on a server located on the same network segment as the desktop that is accessing the files via MP3Tag and/or Windows Media Player. The music library consists of WMA and MP3 files for a total of 310GB, 42K+ files.

Thank you very much for your help. Please let me know if I can offer any additional information.

I will be happy to provide additional documentation and screen prints. I tried to upload more but ran into the 200kb limit.

Regards,

mls

MP3Tag_problem_documentation_pg2_12192016.pdf (131 KB)

#2

This phenomenon has been described already.
/t/17467/1

This seems to be a Windows problem that it polls remote resources as hard as it could and so interferes during simultaneous access.
THe only remedy is to switch off WMP while editing.
Or edit the files on a local drive.

#3

ohrenkino;

Thank you for the response and for pointing me towards showtopic=20640. I did scan the forums looking for similar items, but did not identify any that closely matched the problem symptoms I have been experiencing.

Per your suggestion, my first action was to closely review the exchange documented in topic 20640. Although there are some similarities with what I have been experiencing and the symptoms reported by Starran, I do not believe that the situation I am experiencing is a match for those previously reported.

First off, let me explain that I have been known to blame WMP for anomalous behaviors and as such I make sure that WMP is not active on any network client when I am running MP3Tag. So WMP is not a likely culprit in my situation.

Second, please let me explain one of my previousl comments in greater detail: “The missing data can be visually restored by single clicking on the blank line or by using the Refresh File View function.” I believe that this is a significant point and differentiates the symptoms I am seeing versus those reported in the prior topic.

The “Refresh File” function is one of the ways to restore the visual display of the missing data. It is obvious from the “Reading Data” message and the elapsed time to complete the function that the in memory version of the data maintained within MP3Tag is being refreshed from the stored file(s).

However, simply single-clicking on one of the blank lines will also restore the “missing” data for that line. Of course, I am assuming that simply single clicking on a line does NOT force a reread from the file, but instead, redisplays the data for that line from MP3Tags memory. (This seems to be a reasonable assumption as otherwise; any unsaved changes could be lost simply by clicking on a line.)

So, if this assumption is valid, then MP3Tag actually has the correct and complete information in memory, but something has been messed up in it’s in-memory screen buffer. So perhaps the timing issue has something to do how the screen is being refreshed and not necessarily how busy the actual music files are.

Does this make sense to you?

Again, if there is any additional information I can provide, I will be happy to perform the additional data collection.

Regards,

mls

#4

Actually, MP3tag rereads the information when a file gets the focus again.
On the other hand: if you do not shift the focus and continue editing the blanked file then that is what you get: blank tags.

Editing fields in the file list saves the modification as soon as you leave the field.
Editing fields in the tag panel saves the modifications if you either press Ctrl-S, click the save button in the toolbar or have ticked the option in Tools>Options>Tags>Save tags when navigating - otherwise you are quite right: navigating to another file without prior saving the modifaction looses them.

If you suspect a timing problem and you encounter it on the (slowly accessible) network drive: what does happen, if you edit the same files on your local disc?

BTW: it could just as well be that an indexing program on the NAS slows down the access.
Or to sum it up: I think it is a problem of simultaneous access.

#5

@mls, are you still experiencing any of that with the latest versions of Mp3tag?

#6

Due to missing feedback, I'm assuming the issue has been fixed in the meantime.