discogs: Track IDs not fetched

[welch]

Problem

While importing tracks correctly identified as
https://www.discogs.com/The-Larry-Goldings-Trio-Moonbird/release/8913670
the import appears to succeed, yet track id's are not stored.
beet info moonbird gives this same set of id's for each track:

    mb_albumartistid: 354487
    mb_albumid: 8913670
    mb_artistid: 354487
    mb_releasegroupid:
    mb_trackid:

those are discogs id's, and no track has an mb_trackid, although the tracks
are given their proper titles.

This came to my attention because the duplicates command sees all these
tracks as duplicates of each other. I've done the drill of beet rm moonbird
and reimporting their directory, behavior is consistent.

Setup

• OS: ubuntu 16.04
• Python version: 2.7.12
• beets version: 1.4.2
• Turning off plugins made problem go away (yes/no): uuuuuuhhhhh

My configuration (output of beet config) is:

format_item: $artist - $album - $title .$format-$bitrate
duplicates:
    tiebreak:
        items: [added, bitrate, country]
        albums: [added]
    format: $artist - $album - $title .$format-$bitrate $path
    count: no
    full: no
    keys: []
    move: ''
    tag: ''
    path: no
    copy: ''
    album: no
    strict: no
    checksum: ''
    merge: no
    delete: no
library: /music/beets/musiclibrary.blb

ui:
    color: yes
    colors:
        text_success: green
        text_warning: purple
        text_error: red
        text_highlight: red
        text_highlight_minor: lightgray
        action_default: turquoise
        action: blue

plugins: acousticbrainz convert duplicates edit fetchart fromfilename info lastgenre play discogs
directory: /archive/music/

import:
    move: yes
    duplicate_action: remove
    log: /music/beets/log/flacs-2016-12-09.log
    ignore_hidden: no

match:
    strong_rec_thresh: 0.15
edit:
    itemfields: track title artist album
    albumfields: album albumartist
    ignore_fields: id path
acousticbrainz:
    auto: yes
discogs:
    tokenfile: discogs_token.json
    apikey: REDACTED
    apisecret: REDACTED
    source_weight: 0.5
lastgenre:
    count: 1
    source: album
    prefer_specific: no
    force: yes
    min_weight: 10
    auto: yes
    whitelist: yes
    separator: ', '
    fallback:
    canonical: no
play:
    warning_threshold: -2
    use_folders: no
    warning_treshold: 100
    raw: no
    command:
    relative_to:
fetchart:
    auto: yes
    minwidth: 0
    sources:
    - filesystem
    - coverart
    - itunes
    - amazon
    - albumart
    google_engine: 001442825323518660753:hrh5ch1gjzm
    enforce_ratio: no
    cautious: no
    maxwidth: 0
    store_source: no
    google_key: REDACTED
    fanarttv_key: REDACTED
    cover_names:
    - cover
    - front
    - art
    - album
    - folder
convert:
    never_convert_lossy_files: no
    album_art_maxwidth: 0
    format: mp3
    dest:
    auto: no
    threads: 4
    copy_album_art: no
    tmpdir:
    max_bitrate: 500

    paths: {}
    pretend: no
    quiet: no
    formats:
        alac:
            command: ffmpeg -i $source -y -vn -acodec alac $dest
            extension: m4a
        aac:
            command: ffmpeg -i $source -y -vn -acodec libfaac -aq 100 $dest
            extension: m4a
        opus: ffmpeg -i $source -y -vn -acodec libopus -ab 96k $dest
        mp3: ffmpeg -i $source -y -vn -aq 2 $dest
        flac: ffmpeg -i $source -y -vn -acodec flac $dest
        ogg: ffmpeg -i $source -y -vn -acodec libvorbis -aq 3 $dest
        wma: ffmpeg -i $source -y -vn -acodec wmav2 -vn $dest
    embed: yes

[Freso]

Having any mb_*id set to a Discogs id is wrong. mb_*id are for MusicBrainz ids. A number of applications use those ids to get additional data or for other features, so having a non-MBID in the field will break any lookups of those.

If Discogs ids are wanted, they should go into their own tags. (Also Discogs has no concept of Recordings or Tracks (or Works or …) that MusicBrainz have, so a discogs_trackid tag is not applicable.)

[welch]

I see this behavior on a coupla other discogs tagged imports (for at least one of these, I supplied the discogs id to the importer, but the other it found on its own. i think.).

[sampsyo]

Yep, it looks like the track ID is never fetched from discogs. See:

beets/beetsplug/discogs.py

Line 415 in 8cc2ac5

track_id = None

However, I can't tell whether there is any sensible ID to use from discogs. It looks like there's no specific URL or individual page for tracks. Do you know whether there concept of a "track ID" exists there?

[welch]

pulling from the discogs API reveals nothing to me that might identify a track beyond its position in the album.

is the duplicate plugin's behavior with these tracks as expected/intended, or should I open a separate issue about that?

[Freso]

From my previous comment:

Also Discogs has no concept of Recordings or Tracks (or Works or …) that MusicBrainz have, so a discogs_trackid tag is not applicable.

[Freso]

is the duplicate plugin's behavior with these tracks as expected/intended, or should I open a separate issue about that?

I'd say that:

1. The duplicate plugin should ignore 0 length/empty ids.
2. Empty ids should not be written in the first place (And Discogs plugin should not write "MBIDs" at all: Discogs (and other metadata sources) polluting mb_albumid #604), just like mb_workid is not stored for Recordings that do not have a Work associated.

[sampsyo]

Agreed. (And sorry for reading your earlier comment too quickly!)

[dbogdanov]

pulling from the discogs API reveals nothing to me that might identify a track beyond its position in the album.

Why not inventing our own track IDs as a workaround? It is better then nothing as we can expect that Discogs won't introduce those IDs ever. For example, using the release ID + the string describing the original track position as reported on Discogs could work: "4157155-1", "1921107-A", "4365812-B2", "3786928-Side A".

These IDs would be stable in most of cases. As a bonus, storing the original naming for track positions will be very useful, and it is currently not done (the original values are lost, they are converted to medium and track indices).

[dbogdanov]

I guess this can be closed now.

[sampsyo]

Indeed! Fixed in #2891.