Bitrate value may not appear until the row is manually (3.05, Windows)selected

Environment: MP3tag v3.05 on Windows 10

Today I scanned my MP3 library intending to sort by bitrate, looking for low bitrate files I might need to replace. I noticed that sometimes, the bitrate field would be blank until I selected that row. This is not an issue of a file not having bitrate information, it is a display issue of some kind because the data appears when you click. See the gif below.

Note that doing a select all does not reveal the missing information, nor does a shift-click to select a group.

To try and repro the issue, scan a large set of files and scroll through the list looking for blank bitrates. In my case, bitrate was set to the leftmost column but I don't know if that matters. I did see the problem on 2 different Win 10 systems today. The firs time it had only scanned a couple hundred files, too so I don't think this is an issue specific to a giant library.

Lastly, the tag library was turned on in both test systems. I have not tested to see if that matters.

It looks like the Library already contained data for the listed files, but was missing the bitrate value (for unknown reasons). Selecting the file force-reads the data from the file and updates the Library accordingly.

Do you have an idea why the bitrate might be missing in the first place?

No idea. On one of the computers I tested, I use mp3tag frequently and while I never noticed a problem until now, I can't be positive that the library didn't get mangled somehow.

After I saw this happen on my main PC, I installed mp3tag on another machine. All I did there was install, turn on the library, do the required restart, adjust the column order, and scan the same network drive with the files.

The network drive is a SMB share on a NAS, mapped to a Windows drive letter. I'll try running the same scan on a hard drive with the same files that is directly connected to the system... Should not make a difference of course, but... ya never know. And that disk is already in place so it's no big deal to try.

If you have anything else you'd like me to try, happy to help.

Edit to add: when scanning a local volume, not a network drive, the problem persists. :man_shrugging:

Does this also happen if you move a bunch of files to a folder you've not read with Mp3tag before?

The first time I saw it I was using my regular install and library folder. I then installed mp3tag for the first time on a different computer and scanned the same folder. Those files would have been new to that install. I am not sure if that is the same scenario you are suggesting. If not, I will copy a bunch of files to an entirely new location and see what happens.

Yes. It's the same scenario — I was asking mainly to make sure you've not copied your existing configuration (including the possibly damaged or incomplete library database) to the other machine.

I still fail at reproducing the issue in any way ... if you have any pointers or step-by-step instructions, it'd be most helpful.

I'll see if I can figure out a solid repro!

1 Like

Any updates on this, maybe with the latest Development Build?

I've now moved this to #bug-reports:no-bugs

If the issue reappears please just reply or in case the topic is already closed by then, open a new bug report linking to this topic.

Hey @Florian, I have been messing with this issue a bit and may have a repro for you.

I took another look at my library and I noticed that all of the files which had a missing bitrate also showed a bad ID3 tag warning. (I had long ago turned off the Tag column, and forgot this warning was available until I installed on a new computer and saw the defaults for the first time in a long time!)

I did not find any files with the bad ID3 warning which did display the bitrate on the first pass.

I copied a couple of bad files and one good file to a new directory and scanned them. The problem reproduced easily... On the bad files only, bitrate was blank after the initial scan, but filled in when I clicked the file.

(If the mp3tag library was on, the bitrate was stored to the library once revealed, being visible on restart/rescan of the test folder. I could not find any difference in the initial display of these files with the library off/on.)

We can't ask everything from a bad file, but the bad tag warning isn't always a death sentence as it still pulled out Album, Artist, etc. on the first pass.

As the bitrate is retrievable when mp3tag retries, maybe you can update the scan logic to pick up the bitrate in some of these cases.

Let me know if you would like me to email you a sample file which reproduces the issue.

There are a number of threads that deal with "!BAD" tags.
see e.g. here
Also, you may find relief in one of the tools that are linked here.

The issue here is more that the bad tag is correlated with the bitrate being unreadable when the file is scanned the first time, but it does retrieve the info the second time you touch the file. @Florian may decide it is not worth fixing, but he asked for more info.

I would say that the issue is that the file is somehow damaged. I recommend in all earnesty that you run the files through the tools and see the extent of the damage. If the tools report that everything is fine now, great. But I doubt that.

Good detective work going on here, @Horseflesh. Thanks for the follow-up and the detailed description!

One more mystery resolved :raised_hands: I'll see if I can improve the situation there.

I'll definitely work on the bad files too @ohrenkino, thanks for the links.

Happy to help @Florian... appreciate all your hard work on mp3tag!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.