Sorry @jonas, missed the notification that there's activity here.

Just tested https://builds.strawberrymusicplayer.org/macos/bigsur/strawberry-0.8.4.28.gfcd4e5ac-bigsur.dmg and it seems to work. Thanks!

See https://github.com/strawberrymusicplayer/strawberry/wiki/Using-MPRIS2-to-get-information-and-control-playback

Thanks @jonas, all I see is that it uses QUrl and fails.. here's am example where I replace some strings with ???

15:40:34.649 DEBUG DiscogsCoverProvider:185 Discogs: Sending request QUrl("https://api.discogs.com/database/search?key=???&secret=???&format=album&artist=???&release_title=???&type=master") 15:40:34.650 ERROR DiscogsCoverProvider:477 Discogs: "Host api.discogs.com not found (3)"

I guess I'll have to update eventually..

@Hompacko Thanks

Ok. Thanks. I'll rebuild and see if it works

EDIT: It's working now. Thanks

I'm running a different version of chromaprint which may br causing the issue.

chromaprint-fftw 1.5.0-2.

I can't change that at the moment, but it may be the cause.

Thanks again for the support

The manual integrity check lasts less than 1s and gives me a "OK".
All my music files are stored in exFat partition. I have like 400Gb music files mainly ogg.
Everything is fine on Mixxx application.
Regards,

I think it would help if you start strawberry from a terminal, because then you see the files scanned, it might give a hint to what files take unreasonable time to scan.

If you have issues with the scan never finishing you can start strawberry from the terminal to get an idea where it's stuck. Similar problem reported on GitHub turned out to be a permission issue: https://github.com/strawberrymusicplayer/strawberry/issues/583

If you are on Linux or macOS can simply open a terminal window, then start strawberry by simply typing strawberry on Linux. On macOS you can type: /Applications/strawberry.app/Contents/MacOS/strawberry
On Windows you have to use the debug version to see the output.

The default is to adapt the language from the system locale. Are you sure that LANG or LC_ALL isn't set to German?

You can change it in the behavior settings. See screenshots:

2313b5e0-3417-4d8a-b39e-c5d907df8f63-image.png

eaba5e43-9170-498b-b0de-70f008482004-image.png

Thank you, that is useful to know. It makes synchronising the ratings across various machines easy to do by just copying over the single file. Not so useful for trying to move away from Strawberry as all the data is then lost. But hey ho, I doubt I will need to now for quite some time.

@Ton I moved the messages here.

Should work in the same way as on Linux.
I actually added Tidal with the intent that we would apply for official API access, but Tidal does not respond to e-mails, or want to share their API unless your a big company with lots of money. Someone claimed that OAuth login wasn't working. So I removed it, but it caused lot's of complaints and even bad reviews. Many users claimed it still worked fine and they could obtain a token. So I did some research and it turns out it's pretty easy to extract a client id from an android file, and that's why I added it back.

We already have a column called album_id, which is primarily used to separate albums in the models. Currently this is not in use for local files, only Tidal and Qobuz. So basically all you need to do is to update the tagreader code to read the musicbrainz id's:
https://github.com/strawberrymusicplayer/strawberry/blob/master/ext/libstrawberry-tagreader/tagreader.cpp

@jonas Yes, adding a note about this in the warning dialog would be useful, thanks.
For me, it's no catastrophe, I'll just reconstitute my playlists little by little.

Perfect thanks - group by Artist/Album removes the 'Disc nn' from the collection view and it looks like I can leave the metadata as is.

Strawberry has added compilation tag to the edit tag dialog in the new versions.

@jonas It sounds like you are saying that the default settings of; Save album covers in album directory and use hash is broken in the case where files are not physically stored in album specific folders. If this is the case, then why bother to use a hash at all? I would have expected that whether using a hash or a pattern, whether stored in the album's (or more accurately file's) directory or located in a hidden directory in the user's home folder, that there is some database that associates a particular physical image file with a particular physical music file.

To do otherwise creates a hidden trap for any user that may choose to store their music files in any structure other than limiting folders to only containing the files of a single album. If someone were to put all of their Goo Goo Dolls files in a folder, or all their songs from the 80's, or as I have done with some of my folders, just collections of completely unrelated music files then Strawberry's current implementation is unable to correctly handle the situation.

thanks again for your work.