No info displayed in Library for tracks with no tags

[mixxxbot]

Reported by: geozubuntu
Date: 2020-03-03T23:19:32Z
Status: Fix Released
Importance: High
Launchpad Issue: lp1865957
Attachments: [screenshot of the empty fields and filenames.](https://bugs.launchpad.net/bugs/1865957/+attachment/5333226/+files/screenshot of the empty fields and filenames.), [Please check it all. It is very interesting.](https://bugs.launchpad.net/bugs/1865957/+attachment/5334430/+files/Please check it all. It is very interesting.), [snapshot of new untagged and unparsed tracks](https://bugs.launchpad.net/bugs/1865957/+attachment/5336979/+files/snapshot of new untagged and unparsed tracks), Mixxx_Shot.png

---

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.

[mixxxbot]

Commented by: geozubuntu
Date: 2020-03-03T23:19:32Z
Attachments: [screenshot of the empty fields and filenames.](https://bugs.launchpad.net/mixxx/+bug/1865957/+attachment/5333226/+files/screenshot of the empty fields and filenames.)

[mixxxbot]

Commented by: geozubuntu
Date: 2020-03-07T03:31:33Z
Attachments: [Please check it all. It is very interesting.](https://bugs.launchpad.net/mixxx/+bug/1865957/+attachment/5334430/+files/Please check it all. It is very interesting.)

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-07T08:15:46Z

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-07T09:02:39Z

---

MusicBrainz: #2534

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-07T09:20:10Z

---

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

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-07T10:45:55Z

---

Detection of missing tags: #2535

[mixxxbot]

Commented by: geozubuntu
Date: 2020-03-07T12:30:53Z

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-07T13:58:54Z

---

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

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-07T19:46:43Z

---

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.

[mixxxbot]

Commented by: mevsme
Date: 2020-03-09T20:25:15Z

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-09T22:15:01Z

---

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.

[mixxxbot]

Commented by: geozubuntu
Date: 2020-03-13T19:22:01Z

---

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.

[mixxxbot]

Commented by: uklotzde
Date: 2020-03-13T21:58:24Z

---

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:
#2534

[mixxxbot]

Commented by: geozubuntu
Date: 2020-03-14T20:02:05Z
Attachments: [snapshot of new untagged and unparsed tracks](https://bugs.launchpad.net/mixxx/+bug/1865957/+attachment/5336979/+files/snapshot of new untagged and unparsed tracks)

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2020-03-14T22:57:14Z

---

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.

[mixxxbot]

Commented by: geozubuntu
Date: 2020-04-22T17:59:43Z
Attachments: Mixxx_Shot.png

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2020-04-22T18:11:56Z

---

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

[mixxxbot]

Commented by: geozubuntu
Date: 2020-04-23T13:26:23Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2020-04-23T14:13:04Z

---

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.

[mixxxbot]

Commented by: ronso0
Date: 2020-04-23T14:13:15Z

---

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.

[mixxxbot]

Commented by: tezzy
Date: 2020-10-05T16:34:14Z

---

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.

[mixxxbot]

Issue closed with status Fix Released.