No info displayed in Library for tracks with no tags

Bug #1865957 reported by geozubuntu
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
High
Unassigned

Bug Description

2.3.0-alpha-pre (build master r7148) on Linux Mint 19.3 and win7 Locale setup is Greek (in Linux Greek UTF8). In mixxx options set as System.

Mixxx sometimes will not fill the title and artist fields of the database from the filename. I noticed this in some own rips without metadata. File type seems not to matter. It appears in opus, ogg and mp3 files. I can't tell if it happens in all files without tags. There are some that have been recognized normally. It also seems not to depend on the language since it has happened in Greek and English titled files.
Rescan of the library doesn't change anything.

If metadata are imported from musicbrainz this file is corrected after saving of the metadata, as expected.

Attached a screenshot showing the issue.

Revision history for this message
geozubuntu (geozubuntu) wrote :
Changed in mixxx:
importance: Undecided → High
milestone: none → 2.3.0
Revision history for this message
geozubuntu (geozubuntu) wrote :

This problem is more serious than I thought and described above. It should be marked as critical.

Title, artist, album, year

Usability of library naming and organization by import and export metadata is uncertain. Sometimes works other times don't. So addition of new tracks without metadata isn't usable.

Import from musicbrains sometimes hangs. If it finds matches and you select one it is not sure that it will be stored in library and passed to the file. Sometimes it does sometimes it doesn't. Most times only the year is stored.

If managed to edit manually the data then it is stored, I think.

I don't know which build was the first that this bug appeared. I know for sure that it was after February 16 because at that time I added some files successfuly with no problems.They stored and they are available. After that day I added some more but I didn't manage to add info to all of them. In fact I managed to import metadata only in a few, I think by luck.

Please take a close look at the screen capture video I attached. It shows exactly what I wrote above.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

I don't consider this issue critical, not even high.

The implicit assignment of tags depending on unknown naming schemes is a non-feature and we should better remove it. It only covers a few use cases and fails for many other cases in unpredictable ways. Users complain about it for a reason, but we cannot do anything about it.

Please use a tag editor to properly tag your files or fetch the tags of individual tracks from MusicBrainz. Tag editors usually allow to customize the naming scheme for parsing file names.

The MusicBrainz issue might be caused by some recent changes. I am able to trigger a debug assertion in certain cases that may cause a crash. A fix will follow.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Changed in mixxx:
assignee: nobody → Uwe Klotz (uklotzde)
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Reason: TagLib returns an empty `Tag` even for files without any file tags! Only tested for MP3.

Changed in mixxx:
status: New → In Progress
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Revision history for this message
geozubuntu (geozubuntu) wrote :

Thanks for your time.

I thought it was a feature since it was working somehow in earlier builds.
Thats why I bothered you.

Have a nice day.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

It will work again after the PR has been merged. Unfortunately TagLib seems to be unreliable at detecting missing tags.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Btw, thanks for the report! It revealed 2 other bugs that are only indirectly related to the actual feature. Should be fixed soon in master if someone finds time to review and merge the PRs.

Revision history for this message
mevsme (mevsme) wrote :

I was going to submit a FR, but I stumbled upon this issue.

I think Mixxx should show filename if there is no title and artist tags in the file.

I use wav files for sampler and I can't understand what samples are loaded becuase sample widget doesn't show any info.

The same issue with Decks. If you play wav files without tags, you simply have no idea what file is in the deck now, if you move your cusour through the library \ playlist. The title field of decks are just empty.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

I would also prefer plain obvious file names as title instead of the half-baked parsing of artist + title. I remember that I suggested it once, but it was rejected.

Changed in mixxx:
status: In Progress → Fix Committed
Revision history for this message
geozubuntu (geozubuntu) wrote :

Sorry but fix is not committed. It was reported in git 7148 and now git 7169 still has the problem.
Don't even the filename is appeared.
Metadata aren't retrieved from Musicbrains every time. If retrieved they aren't stored neither in database nor the file tags.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

This bug primarily addresses parsing "artist - title" from file name. The fix has been merged into master. I have performed manual tests with MP3/M4A/FLAC files and can confirm that the bug is fixed. Otherwise please provide an example file that doesn't work for you including instructions about how you tested and the expected behavior.

Both artist and title are saved in the internal database. Please note that Mixxx only exports track metadata into existing tags, i.e. no new file tags are added to files that come without any tags. If such a feature is desired this needs to be implemented. Mixxx has not been developed as a replacement for a full-featured, general purpose tag editor.

The issues with subsequently fetching multiple tracks from MusicBrainz is still waiting to be merged:
https://github.com/mixxxdj/mixxx/pull/2534

Revision history for this message
geozubuntu (geozubuntu) wrote :

Thanks for reply.

The problem is exactly the same as in the video I posted above the other day. Nothing has changed.
I also backed up my huge database and rescanned my collection, to exclude the possibility of a corrupted database, but nothing changed. I also completely removed and reinstalled last master build git7170 to be sure that the installation is correct.
Unfortunately nothing better.....

Please take a look in the snapshot below.
Inside the red marked area you will see files with and without entries. They are newly inserted untagged files. The ones that have entries were manually edited by me or tagged with Picard. The rest are still empty as you can see and not parsed.
You will see mp3 and .ogg and .opus files that aren't parsed. No artist - title appears. They appear empty. Properties are also empty. Rescanning not affect tracks, nothing changes. I have the path visible to be able to see them.

Regarding lossy codecs I usually prefer .opus or .ogg than .mp3 (with this order) because they have better quality to size ratio. As you can see this is happening to .opus and .ogg and .mp3 files.
I don't know about .Flac because all of my flacs are already tagged and mixxx unfortunately doesn't support M4A out of the box and I am a simple radio DJ, I don't have the skills or time, also most of the users, to build mixxx myself. (Btw an insertable plugin would be very useful; not to have to build from scratch to enable .m4a support just copy something).

It is not due to the special Greek characters. There are also English files not parsed. All of them are in UTF. It didn't happen with builds before 16 Feb.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

It might be the case that your title and artist metadata files are there, but empty.
We have changes this behavior in Mixxx some time ago to preserve explicit empty fields.

I have been stumbled over this in my manual tests myself, but than I consider it as correct.
However I am not sure if there is a use case for this.

Revision history for this message
geozubuntu (geozubuntu) wrote :

Unfortunately this still exists making usage not only inconvenient but really difficult sometimes.
Think of a party where the owner comes with a memory stick with some tracks asking to blend them with the rest. Dragging them to Mixxx and what appears is like the screenshot below.. very difficult to decide which one to load..

At least the filename should appear as with every other program in the market.

Sorry If I become a pain but I really like Mixxx and would like it to be above the other similar programs.

Revision history for this message
Be (be.ing) wrote :

There already is a filename column in the library. Right click the table header to select which columns to show.

Revision history for this message
geozubuntu (geozubuntu) wrote :

There is nowhere a "Filename" column. At least it is not implemented in the versions downloaded from the https://downloads.mixxx.org/builds/master/release/ location.
Even in today's last version, there is only a "Location" column which was always there. This show a very very long string which is the whole file path, not the filename. It is useful, but it also can be really long, practically unreadable, if the collection is very big and has a hierarchical structure.

Anyway this is definitely a regression. Older versions of Mixxx were working as good as should, at least for Mp3s. We could read under Title Track1.mp3 or filename.mp3 or 02.whatever-filename.mp3 etc if the files were saved with this filename. The Title field of the database was populated with this (Not the metadata tags but it is OK) and we could have an idea at a glance. Now we have to scroll left - right to see what is each empty field.

It is a disappointment to see that a good program lacks the most common feature in every other program out there from the simplest to the most complicated.

Thanks for your time.

Revision history for this message
Be (be.ing) wrote :

It would be nice to split the path column into a folder name and file name. This could be useful for people who use file system folders to organize their music.

Why don't you tag your tracks? The pull request Uwe posted above for using Mixxx's MusicBrainz tagging feature with multiple tracks has been merged.

Revision history for this message
ronso0 (ronso0) wrote :

The filename column is only in Browse feature, isn't it?
This is okay since it fits the use case for removeable drives.

If you permanently add your tracks to your library, just use a tag editor to fill the tags. In Mixxx itself you can even do that per track via the Track Properties window, just copy the snippets from the filename displayed at the bottom.

Revision history for this message
Terry Belton (tezzy) wrote :

I am using 2.3.0-beta (build 2.3 r7597)

$ lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal

On 2.3.0-beta (build 2.3 r7597) Mixxx no longer adds artist and title to the database if there are no ID3 tags. 2.2 worked fine.

Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9891

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.