Browse feature reads tags for files that are in library

[mixxxbot]

Reported by: ferranpujolcamins Date: 2016-08-13T10:11:59Z Status: Triaged Importance: Low Launchpad Issue: lp1612932

---

I've just realized that the Browse library feature reads tags for files that are in the library. Shouldn't Mixxx detect if a file is in library, and if so avoid reading tags from the file and use the database?

[mixxxbot]

Commented by: ferranpujolcamins Date: 2016-08-13T10:18:05Z

---

Related: https://bugs.launchpad.net/mixxx/+bug/1612935

[mixxxbot]

Commented by: daschuer Date: 2016-08-13T18:05:45Z

---

The current behaviour is by design. I would say, won't fix. But if we have valid use cases ...

[mixxxbot]

Commented by: ferranpujolcamins Date: 2016-08-13T19:06:43Z

---

Wouldn't it be faster?

[mixxxbot]

Commented by: uklotzde Date: 2016-08-14T15:06:55Z

---

Please note that tracks are added implicitly to the library once you access them through the browse view. I documented the discussion with RJ in my "Write Audio Tags" PR:

    // NOTE(uklotzde, 2015-12-08): Accessing tracks from the browse view
    // will implicitly add them to the library. Is this really what we
    // want here??
    // NOTE(rryan, 2015-12-27): This was intentional at the time since
    // some people use Browse instead of the library and we want to let
    // them edit the tracks in a way that persists across sessions
    // and we didn't want to edit the files on disk by default
    // unless the user opts in to that.
    return m_pTrackCollection->getTrackDAO()
            .getOrAddTrack(track_location, true, NULL);

According to this code tags should not be re-read when the track is found in the library (master / 2.1.0-alpha-pre)!? The PR only adds some comments.

[mixxxbot]

Commented by: ferranpujolcamins Date: 2016-08-14T15:20:45Z

---

In Joan's GSOC work, he added a new library feature that is similar to browse, but only displays tracks that are in the library. With such a feature, do we still need to add tracks to the library as they are accessed through the browse view?

I personally don't like this behavior. I want total control of what gets added to my library. Do you think it is ok to make an option to disable this?

[mixxxbot]

Commented by: uklotzde Date: 2016-08-14T21:26:19Z

---

One reason for doing this was that any editing of metadata in browse view would otherwise be lost if writing of tags into files is disabled. Modified metadata is currently only stored in the library.

I agree with you that adding tracks implicitly to the library when browsing is confusing.

[mixxxbot]

Commented by: ferranpujolcamins Date: 2016-08-14T22:07:11Z

---

Weren't you working to store metadata to file tags?

[mixxxbot]

Commented by: uklotzde Date: 2016-08-15T08:29:53Z

---

Yes. That's the reason why I stumbled upon this behavior.

The browse view has more issues. We cannot store everything in file tags, e.g. the cue points and waveform. Moreover the BPM in ID3v2 tags will be rounded to integer values. I would drop the browse view entirely.

[mixxxbot]

Commented by: ferranpujolcamins Date: 2016-08-15T08:52:43Z

---

Browse view is useful when a guest dj plays with my laptop and I don't want to add his tracks on my library.

Traktor stores all metadata it generates in id3 tags. It creates custom tags for metadata that can't be store in standard tags. What about this?

[mixxxbot]

Commented by: sblaisot Date: 2016-08-15T08:54:12Z

---

please don't drop the browse view unless you have nested crates implemented. This is the only view I found to have a tree of track containers.