2152: observations

Help improve MediaMonkey 5 by testing the latest pre-release builds, and reporting bugs and feature requests.

Moderator: Gurus

Barry4679
Posts: 2408
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

2152: observations

Post by Barry4679 »

Sync GPM->MM
I have GPM sync configured as: http://www.dropbox.com/s/f3097tixoy43ds ... g.png?dl=0
ie. "Scan GPM Music content to local" and "Only include contents that matches MM"
But you appear to sync all my GPM playlists to MM .... these are not music "content" ... and they aren't "local", as MM did not know of them prior to the sync.

ie. you do not appear to be syncing as per my sync specification .. ?

Artist Images
The auto-download for artists misses some artists.
The manual LookupImage (right click menu) facility is confusing, or broken. .... ie. select an image for an albumartist who does not have one, and press OK has no action. ... or select an image, and press "Default Image: button has no action ... to use the image, selected from the list of images you provide, we need to double click the desired image.

Images are not always relevant ... ie your algorithm chose this image for the band Cream: https://www.dropbox.com/s/44kua4zqque72 ... e.png?dl=0
I know that I can override it, but here are the alternates that you offer :): https://www.dropbox.com/s/q849smhq65cb8 ... s.png?dl=0
You should search for "band:cream", which gives https://www.dropbox.com/s/4gxksehjtvt05 ... m.png?dl=0 ... probably affects other artists with generic names: such as Love or Gaudi
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
Ludek
Posts: 4958
Joined: Fri Mar 09, 2007 9:00 am

Re: 2152: observations

Post by Ludek »

Barry4679 wrote: Wed Jan 30, 2019 10:33 pm Sync GPM->MM
...
But you appear to sync all my GPM playlists to MM .... these are not music "content" ... and they aren't "local", as MM did not know of them prior to the sync.
The playlists are not local, but includes content that matches files already in the database, so it fits the option
'[x] Only include content that matches files already in the database'.

FYI: starting from build 2153 the playlists will appear under the 'Google Play Music' playlist parent, details and reasons here https://www.ventismedia.com/mantis/view ... 396#c52303


Re Artist Images:
Thanks, will be fixed in the next build.
willyvds
Posts: 439
Joined: Tue Feb 24, 2009 3:30 pm

Re: 2152: observations

Post by willyvds »

I also had cream yesterday ;-)

But indeed: artist tagging needs some improvements. How would MM know what are "common words"?
Maybe the (most played) song title could be included in the search?
Barry4679
Posts: 2408
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2152: observations

Post by Barry4679 »

Ludek wrote: Thu Jan 31, 2019 7:16 am The playlists are not local, but includes content that matches files already in the database, so it fits the option
'[x] Only include content that matches files already in the database'.
OK (maybe), but is it what people are likely to want?

As you know the client from GPM is an inadequate tool to build playlists. I think that the ability to build playlists with MM, for use at GPM, is one of the key deliverables coming from the GPM|MM integration that you are delivering.

And then you muddy that by also enforcing a sync of playlists in a GPM->MM direction each time that we sync to GPM.
I can't think of a situation where I would want to import the GPM version of a playlist. ... Maybe their autoplaylists like ThumbsUp or LastAdded, but that is all ... but it would good to have control.

Couldn't you either?:
  • or even better, let me record which playlists that I want to sync from GPM via the Playlists display at Devices&services>GPM?
willyvds wrote: Thu Jan 31, 2019 2:12 pm I also had cream yesterday ;-)
But indeed: artist tagging needs some improvements. How would MM know what are "common words"?
Yes, the day is improved by a little Cream :) ... I was suggesting that they do all art searches using the "band:xxxxx" format.
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
MiPi
Posts: 868
Joined: Tue Aug 18, 2009 2:56 pm
Location: Czech Republic
Contact:

Re: 2152: observations

Post by MiPi »

Barry4679 wrote: Thu Jan 31, 2019 8:31 pm I was suggesting that they do all art searches using the "band:xxxxx" format.
There is probably no general way of improving artist search by adding something like this. E.g. compare results of image search "band:Madonna" and "Madonna". It definitely improves reliability for some look-ups, especially, where the artist is really band (like Cream), but can ruin it for other.
Ludek
Posts: 4958
Joined: Fri Mar 09, 2007 9:00 am

Re: 2152: observations

Post by Ludek »

Re: GPM playlists
In true, I have never understood your (so propagated) use case of scanning only GPM content that is already included locally. What is the purpose of this? Why one would want to scan a content that he already has locally? I guess that much more typical use-case is that user wants to scan GPM content (playlist/tracks) that he hasn't locally yet. In either way with the option ''[x] Only include content that matches files already in the database' it only imports the playlists that include local tracks and imports them grouped under the 'Google Play Music' parent playlist (starting from 2153). So they are not of any mess in your local library, you can remove the whole 'Google Play Music' parent playlist anytime later.
Barry4679
Posts: 2408
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2152: observations

Post by Barry4679 »

Ludek wrote: Fri Feb 01, 2019 6:53 am In true, I have never understood your (so propagated) use case of scanning only GPM content that is already included locally. What is the purpose of this? Why one would want to scan a content that he already has locally? I guess that much more typical use-case is that user wants to scan GPM content (playlist/tracks) that he hasn't locally yet.
OK, here is my Use Case. It is also the Use Case of many of the people who contact me about my MediaMonkey add-on application, which includes some GPM integration.

nb. I notice that quite a few people read these threads. If there are other Use Cases, please feel free to contribute, or disagree.

We are owners of local music collections, and are committed users of MediaMonkey.
Often we have spent many hours curating and tagging and tidying up our collection with MM... we want to preserve this state.
We have uploaded our music collections to GPM. We did this for the following reasons:
  • primary goal: so that we can stream from our whole collection when we are commuting or away from home ... is very attractive, because it is offered at no charge, and has been available since approx 2012
  • secondary goal: as an offsite backup of our music collection
For the primary goal, the problem is that we have become used to the great browsing and playlist building tools within MediaMonkey.
The browsing and playlists building tools in GPM are crappy ... we want to build playlists using MM, and publish them into our GPM library for use when away from home.
But now we have our music collections in two places, and this results in duplicated work to build playlists, and keep our collection in sync ... and this is difficult due to the primitive state of the existing GPM tools. amd the lack of any integration between our local and our web music collections.

As MM fans, MM|GPM integration is something that we have been wishing for, for a long time.
But we have spent many hours curating and tagging, and caring for our music collection ... so we want sync on our terms ... ie. we don't want pollute our collection with whatever tag crap is in the GPM version of our tracks, or all the tracks that we once added into our GPM library, from the 30+ million tracks available at GPM.

The first step is to sync. to provide connectivity from our MM collection, to our GPM collection ... nb. note direction; from MM -> GPM .... this is so that we can build playlists using MM superior tools, and then publish these playlists to GPM, so that we can listen to our own music collection, using the GPM music client when we are commuting, or away from home. ... to achieve this MM needs to learn the GPM IDs for our tracks ... so we need sync just Google ID's for matching MM tracks ... don't screw up our MM database with all the other bits and pieces from our dirty GPM library ... you have delivered this

The second goal is to take advantage of some of the 30+ million tracks that GPM has to offer.
We are Music Collectors .... we can't relate to a collection of 30+ million tracks ... that is not a music "collection" ... that is an overwhelming fire hydrant of music ... it would be just like listening to whatever an FM radio decided to send us.

The problem that we are looking to solve with MM|GPM integration is this ... we are used to being able to build smart playlists with MM ... smart playlists that may include how long we owned the track, or how long since we heard it, or what its user rating is.

So if these selected new Google tracks are to become part of our "collection", they need to be in MM .... but on the other hand we don't want to pollute our MM library ... we would prefer to pick and choose which new tracks get added collection ... aka sync'd into our MM library
I add lots of tracks to my GPM library .... I listen to them .... a few of them I want to add to my MM library ... most I don't .... some I am still considering whether I want them to be part of my "collection", others are just sitting there because i have not spent the same effort on my GPM library, that I did with my local collection, because GPM lacks good housekeeping tools, and because GPM is not my "real" music collection.

So in this Use Case:
  • we want manual control over which tracks or tracks get inserted into our MM database ... MM5 delivers this
  • and we are using MM to design and publish MM playlists into our GPM library, and for use against our local collection .... it is unnecessary and confusing and annoying, for you to enforce them coming back the other way
Ludek wrote: Fri Feb 01, 2019 6:53 am Only include content that matches files already in the database' it only imports the playlists that include local tracks and imports them grouped under the 'Google Play Music' parent playlist (starting from 2153). So they are not of any mess in your local library, you can remove the whole 'Google Play Music' parent playlist anytime later.
Maybe this is OK ... I have not seen it yet.

Ludek, this isn't a deal breaker for me. ... I am just reporting what i would prefer, and find less confusing.

Sorry if this post is long, but you seemed to asking for the background to the Use Case that I am seeing.
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
Barry4679
Posts: 2408
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2152: observations

Post by Barry4679 »

Post moved to another thread as requested.
Last edited by Barry4679 on Mon Feb 04, 2019 8:49 am, edited 1 time in total.
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
Barry4679
Posts: 2408
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2152: observations

Post by Barry4679 »

Post moved to another thread as requested.
Last edited by Barry4679 on Mon Feb 04, 2019 8:50 am, edited 1 time in total.
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
Ludek
Posts: 4958
Joined: Fri Mar 09, 2007 9:00 am

Re: 2152: observations

Post by Ludek »

Barry, could you please split this thread to several threads with corresponding topics?
There is bunch of unrelated topics that needs to be tracked individually.
It is not providing an easy survey to discuss several unrelated issues in a single forum thread.

Thanks!
Barry4679
Posts: 2408
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: 2152: observations

Post by Barry4679 »

Ludek wrote: Mon Feb 04, 2019 5:08 am Barry, could you please split this thread to several threads with corresponding topics?
I think that i would need to be a forum admin to split an existing thread apart into individual threads.
I leave for three weeks in the morning, so I doubt that i will have time to redo all this.

Ludek wrote: Mon Feb 04, 2019 5:08 am There is bunch of unrelated topics that needs to be tracked individually.
It is not providing an easy survey to discuss several unrelated issues in a single forum thread.
Don't you track issues individually when you transfer verified problems into Mantis?

OK I will change next time. I thought that I was doing as you wanted by starting a new thread for each new MM release.
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
Ludek
Posts: 4958
Joined: Fri Mar 09, 2007 9:00 am

Re: 2152: observations

Post by Ludek »

OK, we will look into the issues / dumps while you are travelling.

Just for the next time, each of these topics could have own thread:

Artist Images
Download from GPM
Protecting uncommitted config changes
Locate Moved or Missing Files menu item
Sync MM->mobile phone

...to prevent from monster threads.

Thank you for your effort and enjoy your travelling !!

PS: I don't think (or at least I don't remember ;-) ) that I wanted you to start a new thread for each new MM release. Having one topic per one issue seems the clearest way how to track/discuss issues IMHO
Post Reply