filter differences MM4 vs MM5 is a problem ... workaround? [#17173]

[Barry4679]

My installations of MM4 & MM5 index the same collection of tracks.

In MM4, if want to see any classical track belonging to Opus 70 of any composers' output, I can Ctrl+F and then AnyTextField search on Op. 70 ==> I see 36 tracks, all containing Op. 70 in their title ... all good in MM4

If I do the equivalent in MM5 ==> I see 67 tracks, many of which are not from Opus 70 ... this seems because you seem to be doing optimisations in MM5 that ignore any special characters in my filter criteria ... which means that I have lost some control over what I am trying to filter to.

Is there any workaround in MM5, so that I can replicate the filter facility in MM4, which treated special characters as significant characters?

Most of the unwanted tracks are due also to the MM5 default where path is one of the "tags" that are searched ... here is an example of an unwanted track

\\NAS-xxxx\flac\David Oistrakh\Mozart Brahms; David Oistrakh; The Complete Recordings, Disc 7\07.flac
Artist Cleveland Orchestra; George Szell; David Oistrakh
Title Violin Concerto in D Major, Op. 77: 1. Allegro Non Troppo
Album Mozart Brahms: David Oistrakh: The Complete Recordings, Disc 7
Track 04/6
Disc 07/17; 07/17
Genre Classical - Concerto
Year 2008{CR}2008
Rating
Composer Brahms, Johannes
Size 123.84 MB (46% Compressed)
Original Size 227.93 MB
Length 22 minutes 34 seconds
Channels 2 (stereo)
Sample Rate 44.1 kHz;
Sample Size 16 bit
Bit Rate 1,411 kbps
Encoder FLAC reference libFLAC 1.2.1 20071117
Encoder Settings
Audio Quality Perfect (Lossless)
Contains Album Art, CRC, ID Tag [Vorbis Comments]
Channel Mapping
File 04
Type FLAC Audio [.flac]

If I turn path off .... which should be the default IMO ... I still get 4 unwanted tracks
Here is one:

\\NAS-xxxxx\flac\Neeme Järvi\Rachmaninov; Symphonic Dances; Dances from Aleko; Capriccio bohémien\04.flac
Title Aleko, Opera, TN Ii/70: Dances
Album Rachmaninov: Symphonic Dances; Dances From Aleko; Capriccio Bohémien
Track 04/6
Disc 1; 1/1
Genre Classical - Orchestral
Year 1992{CR}1992
Rating
Composer Rachmaninov, Sergei
Size 15.65 MB (65% Compressed)
Original Size 44.45 MB
Length 4 minutes 24 seconds
Channels 2 (stereo)
Sample Rate 44.1 kHz;
Sample Size 16 bit
Bit Rate 1,411 kbps
Encoder FLAC reference libFLAC 1.2.1 20071117
Encoder Settings
Audio Quality Perfect (Lossless)
Contains Album Art, CRC, ID Tag [Vorbis Comments]
Channel Mapping
File 04
Type FLAC Audio [.flac]

[Ludek]

I think that the workaround is to use quoted strings and/or disable path from search fields. Or search for specific fields

E.g.
"Op." 70
title: "Op. 70"
title: "Op." "70"

... all these will get different results based on what you are searching

As for ignoring the special characters: as you remember these were part of the optimizations when matching tracks from GPM and Spotify and also improves searching when you search for variants of AC/DC , A-ha or similar artists not always correctly spelled in tags.

e.g. so that searching for acdc finds ac/dc variants etc.

[Barry4679]

as you remember these were part of the optimizations when matching tracks from GPM and Spotify and also improves searching when you search for variants of AC/DC , A-ha or similar artists not always correctly spelled in tags.

Nope ... 3+ years of posting up reports here, and then moving on because I can't do anything to fix things, sort of means that I remember not too much actually

This works ok. So the funnel is a good all_text_fields workaround

You might want to look at why context filter string of "Op." finds nothing at all .. ?

ie. context filter of Op. finds 3386 tracks
context filter of "Op." finds nothing

Maybe the quoted form can't handle special characters atm?
There is a lot to find, even if the quoted form is capitalisation specific. Is it btw?

[Ludek]

Nope ... 3+ years of posting up reports here, and then moving on because I can't do anything to fix things, sort of means that I remember not too much actually

Really? I would bet that we fixed majority of issues you reported here. Including all your use-cases re Google Play Music integration, sync and pairing -- which all goes to waste as GPM service has been just shutdown.

ie. context filter of Op. finds 3386 tracks
context filter of "Op." finds nothing

Seeing the same, added as https://www.ventismedia.com/mantis/view.php?id=17173

[Barry4679]

Really? I would bet that we fixed majority of issues you reported here

Uh ... I didn't say it clear enough.

Not at all saying you didn't fix things. You fixed nearly everything.
Just saying that I don't recall all of the details, like you do ... due to limited involvement, because I drop out once the problem is defined.

The only reason that I said anything at all, is because you sometimes get irritated when I report problems more than once ... because over three years it is hard to remember the status of things.

... which all goes to waste as GPM service has been just shutdown.

Hopefully not entirely wasted.

Maybe useful for other streaming services ... maybe even YTM, if Google ever get around to publishing an api ... or someone reverse engineers something

[Ludek]

Hopefully not entirely wasted.

Maybe useful for other streaming services ... maybe even YTM, if Google ever get around to publishing an api ... or someone reverse engineers something

Yes, not totally wasted, I used many of these in the Spotify plugin. Luckily Spotify has a nice and well documented api, is popular and most probably isn't going to shutdown soon.

The problem with big companies like Google, Amazon, Apple and their music services is that they don't seem to be interested with publishing an official api for third parties, so we must often use reverse engineering that is time consuming with unwarranted results (and often is on the law's edge). Unfortunatelly these are the most popular music services.
There are many others music services (Spotify, Deezer, Tidal, Napster, ...) that have open apis for third parties, but are not so popular (with except for Spotify )
So lets see how the future is going to evaluate which of the music services make sense to integrate. We have already a good framework prepared thanks to GPM (and further could services) integration But this is off topic here and is for another thread.

[Barry4679]

The problem with big companies like Google, Amazon, Apple and their music services is that they don't seem to be interested with publishing an official api for third parties, so we must often use reverse engineering that is time consuming with unwarranted results (and often is on the law's edge). Unfortunatelly these are the most popular music services.
There are many others music services (Spotify, Deezer, Tidal, Napster, ...) that have open apis for third parties, but are not so popular (with except for Spotify )
So lets see how the future is going to evaluate which of the music services make sense to integrate. We have already a good framework prepared thanks to GPM (and further could services) integration But this is off topic here and is for another thread.

OK, I agree is off topic here.
I will close with a couple of links for anyone interested in this topic:

• a project which is reverse engineering a YTM api in C#: https://github.com/jamesbrindle/YTMusicUploader

• an article discussing some online music lockers alternatives to GPM: https://www.androidpolice.com/2020/11/2 ... d-library/

I have started testing MM5 integration with Dropbox, and have opened a new thread for that.