[DaveBlake]

We can also stop fetching the track lists for an album, users just don't care, all they want is the songs they have, although I doubt that will help much.

correct, i haven't implemented it, as the recent forum discussion on this subject seems to indicate users prefer to see a list of the actual tracks they have in their library instead of a scraped tracklist.

@ronie after chatting with @night199uk I have a slightly different take on the reasons for scraping album tracks. I now believe that we should still fetch these if the album has a MBID derived from tags (not name lookup).

They are not for display on the album info dialog, users just want to see the tracks they actually have, so not for storing either (the albuminfosong table can go).

The purpose is for music files that are fully tagged with mbids, combined with "Prefer online info" enabled, that scraping can update even the song titles, and album and song artist credits with those in the Musicbrainz database. It means that users could update their collection with the latest crowd wisdom from MB without having to go though the stage of refreshing the tags in Picard.

It was not intended to unscramble poorly tagged music using name lookup, that soon gets messy. And there were flaws in the implementation which meant that things could get overwritten when they shouldn't. I stopped some of that in v16, but now I know what it was trying to do.

So could tracks still be implemented in the Python scraper after all please.
Also could they have strMusicbrainzTrackID fetched and set (so the merge process can check it is merging the correct song)