simon-weber / autoplaylists-for-google-music Goto Github PK

I have an autoplaylist with 930 songs through the web UI, and only 21 songs on phone and tablet. I've tried multiple force syncs through Chrome extension, and refresh via the Android app, with no luck. Weird.

From this mailing list post, the name is misleading:

"Creation date" might be what GPM calls it, but after a bit of trial and error, it isn't the "track creation date" (i.e. Help by The Beatles would be 1963), it's the date when you added it to your music library. "Date added to library" might be a better name for this field. (I've a full subscription to GPM, hence where some of the confusion might have come in.) I can't believe it's just me that's a little confused at the name given to this field.

This will be useful in figuring out the cause of syncing errors, since historically many have applied solely to All Access users.

I believe this is stored in window.USER_CONTEXT[13], which we could pull via the content script as we do user id.

This means the description is inaccurate for the time between a post-write sync and a periodic sync. This isn't too big of a deal since periodic syncs are very frequent.

I've gotten questions from a few folks about donations, so I guess it's time to figure that out.

Here's my most recent plan, copied from an older comment on an unrelated issue:

• free version: all features, but limited to one playlist
• full version: no limit on playlists. $2 a month? I'd love to do $1+ pay-what-you-want, but the Web Store doesn't have an easy way of doing that.
• keep everything open source. contributors get full tier for free (by adding their email to be a trusted tester, which I need to check doesn't violate some ToS).
• people can build from source and sideload if they really don't feel like paying

Feedback in the issue would be great, but I'm also planning to link it where people ask me about it (so feel free to reply there instead).

I would like to have an option for subsorting playlists.

Right now if I sort by artist, within that artist the songs are sorted by ID, and if I sort by album, they are not grouped by artist.

What I would like:

• Artist 1
  • Album 1
  • Album 2
• Artist 2
• ...

I hope this makes sense.
Thank you.

Edit: also even more subsorting by track number within those albums :)

Is there a way to have 'not played in the last 30 days' or something like that? What's the syntax as it stands regarding last-played?

setInterval should be fine since the background script is persistent. Playlists should be pushed after cache updates too.

From #10 (comment), @johnrobertlawson says:

So after creating a playlist, there's a few minutes of flux where the webpage is not responsive and there a lots of duplicates, but afterwards the playlist is fixed. However, the page still refreshes every minute or so and locks up temporarily, presumably as the script is checking the remote playlist?

I am having a hard time getting the results I expected when building auto playlists based on rating. I am using the 0.4.1 beta release.

I see the description: "rating: 0: no thumb, 1: down thumb, 5: up thumb."

My thumbs up playlist has 693 tracks, but building an autoplaylist in your extension yields the following:

Rating equal 5 : 277 tracks
Rating greater than or equal 4: 606 tracks
Rating greater than or equal 3: 776 tracks

Maybe my understanding of the rating system is lacking, or the definition of rating 5 = up thumb is not entirely correct? Several years ago my music was managed with iTunes, so preexisting ratings could be the issue?

Thank you!

This is a weird one. Here's what happened:

• signed into chrome for the first time on a new linux computer
• opened google music, extension initialized as expected and synced extension state properly (notable, #41 did not happen)
• autoplaylists were cleared on the first sync
• testing a new autoplaylist showed that the track cache contained 0 items
• once a song finished playing, the track cache contained just it
• reloading the extension then the page fixed the problem

My best guess is that the indexedb contained 0 tracks on the first load, since the diff update should work to pull the entire library. This makes sense, since google's client wouldn't have had a chance to pull down the library yet.

I'm not sure how to detect this since I didn't get a good look at the idb before reloading the page (oops). At very least, it ought to be possible to test this hypothesis by blowing away all cached data for google music, then reloading the page.

Google doesn't support playlists over 1000 tracks [0]. We handle this by automatically truncating and logging a warning, but this should definitely surface in the ui.

[0] https://support.google.com/googleplay/answer/1250213?hl=en

Build times jumped from a few seconds to ~20 after I added it.

A big psuedo-random number is probably fine for user ids.

This has popped up on sentry consistently, and I don't know what to make of it. I don't think it's causing #35 or #20 - this prevents a request from ever being made, and those clearly see requests being made - though it probably does cause syncs to fail.

It could be a chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=113994.

Logging data shows that cookies.getAllCookieStores is returning [] when this occurs, though I think that's expected since we don't request cookie permission.

Some ideas for mitigating this if it can't be fixed:

• include the endpoint in the error report so we know which requests it affects (presumably all of them)
• cache the xt value in case the cookie is still around, but not available to us for some reason
• see if the xt value can be pulled from the content script instead
• ask for cookies permission and see if that fixes the problem (though introducing new permissions should not be done lightly)

While navigating Google Music in the browser (Chrome) the page keeps refreshing over and over (about every 5 seconds).
Not sure why it's polling this often, I believe it should be once a minute. This is making it difficult to navigate around Google Music on the browser.
It seems the issue is only on the browser, on my iPhone the playlists are updating perfectly.

creationDate and lastPlayed queries work if provided microsecond timestamps, but ideally they'd support queries like "since two days ago". Introducing another downdown would require changing business-rules, so I'm thinking of doing free-text input instead and parsing with eg http://www.datejs.com. We'd still store timestamps.

Sourced from this mailing list post.

The implementation can probably be almost the same as the current negative-lookahead neq implementation.

I've gotten into this state twice in the past 24 hours or so. It looks like the playlist update lock is being acquired and never released due to errors during a previous update. Here's an example:

lock [auto] not heard recently
background.js:123 [auto] not heard recently found 592
background.js:125 first is Object
https://play.google.com/music/services/loaduserplaylist?... Failed to load resource: net::ERR_NETWORK_CHANGED
googlemusic.js:47 request failed: https://play.google.com/music/services/loaduserplaylist?format=... Array[2] Objectabort: ... @ googlemusic.js:47
background.js:217 periodic update for 17736759431493700887
background.js:51 get poll for 17736759431493700887 1452397617030000
background.js:31 index for 17736759431493700887 1
googlemusic.js:62 getTrackChanges 1452397617030000
googlemusic.js:111 1 "tracks"
googlemusic.js:114 Object
background.js:61 done with diff upsert of 1
background.js:63 done with diff delete of 0
background.js:43 set poll for 17736759431493700887 1452445341027000
background.js:153 renaming to [auto] frequent metal
background.js:31 index for 17736759431493700887 1
googlemusic.js:124 updatePlaylist Object
background.js:177 skipping forceUpdate since playlist is being updated: [auto] not heard recently

I had a feeling this would happen because the unlock isn't in something like a finally, but I didn't think it'd be as common as this.

edit: this is handled pretty well today; see the wiki for details.

Sourced from this mailing list post:

I have some playlist rules matching more than 1k results, and due to Google limitation on number of tracks in a playlist, I am locked with only 1k tracks in a playlist relatively to sort criteria.
As an alternative, is it possible to add extra fields to the limit option in order to :

• choose from $number to $number in result (choose from 1001 to 2000 to create an extra playlist for example)
  AND/OR
• check an option to automatically create multiple playlists for each set of 1000 tracks (playlist1 (1 to 1000), playlist2 (1001 to 2000), playlist3 (2001 to last) for rules matching more than 2k tracks for example)

The first could be done by exposing lovefield's skip. The second would be a bit trickier, since it'd require some new syncing logic (creating/deleting playlists based on number of tracks).

I've triggered this twice. Both times it was caused by sortby/sortorder not being persisted (or maybe persisted as null?), which caused this error during querying. I fixed it by manually resetting the sort from the ui.

Here's a traceback on sentry: https://app.getsentry.com/simon-weber/autoplaylists-extension/issues/111114969.

I just triggered this after installing the extension on a new device. Sync worked properly, and on my other devices sortby/sortorder are properly set. So, this ought to provide a way to replicate it.

Like gmusicapi, I don't really think unit tests would give us much value -- the parts that are going to break are the interactions with Google Music.

I wonder if extensions can be loaded into Chrome with a script? Then selenium and a real account could work (though I'm actually not sure if selenium can click a page action...).

If I do "Rating = 5" then "Any" of any two conditions, the 'test' is undefined, and the playlist is blank. Doesn't work if the subconditions are "All".

From a mailing list post:

The key to the system I linked to is being able to link to other "smart" playlists. I'm not sure if the GMusic API gives you that info however (this song exists in these playlists). Seems no other "smart" playlist app is able to do this so IDK.

This would unlock a multitiered playlist that allows for greater complexity. Like, "Playstist 1: Thumbs up, not played in 2 weeks, sorted by playcount + Playlist 2: unrated, added in the last 60 days sorted at random...etc.)

The system prioritizes new and highly rated music (add more new/unrated songs while also adding higher rated songs more often) so you get a good mix of new & loved tracks.

eg the datetime fields (#12) and type aren't obvious.

The solution to #18 interacts strangely with the solution to #9: any tracks that aren't deleted because they might be playing will end up at the top of the ordering.

This is because the current reordering solution attempts to mirror the local ordering, which won't contain the maybe-playing tracks.

I think this should be an easy fix: instead of mirroring the local order, use lovefield to properly order the remote ids with one big id in <all remote ids> sort by... query.

On OSX, when I click the autoplaylist icon, nothing happens. Works fine on Windows and Linux.
Background sorting still works as normal.
Issue since at least 0.7.

I did this in https://travis-ci.org/simon-weber/Autoplaylists-for-Google-Music/builds/110800320 and it caused a ton of errors that I don't have time to fix right now.

Sourced from this mailing list post:

It would be nice to be able to adjust the order of criteria and sort. I have found my self deleting criteria I added later because I want to add an extra criteria to the earlier section purely for aesthetics. I.e. I created 3 in scope genres and then added a rating filter. Decided later I want to add another genre and in order to get them aligned next to each other I delete the ratings, add the filter, then put the ratings back.

Supporting reordering might be tricky since the UI is entirely provided by business-rules. Maybe always sorting rules on presentation would work? It's a little bit strange to have them jump around after saving, though.

In playlists_editor, the check to disable the add playlist button needs to also check that we have more than one playlist already before locking.

Even though the ui supports all queries, the only playlist definitions that work are single-depth all queries. It should be straightforward to support everything else, though.

I double checked that I'm using the correct field, but lastPlayed still doesn't make any sense. I'm seeing tracks that I haven't played recently (or ocasionally ever) with recent playtimes that aren't correct. Most of time it seems to be roughly correct, though.

albumPlaybackTimestamp and recentTimestamp are worth looking at too.

Hi,

An auto-playlist with "Last Played" = "before 30 days ago" is created successfully, but as you're listening to it, only ~30 seconds of each song will play before skipping to the next one. There needs to be a way to delay the refresh of the playlist by the length of the track (not sure what Google's criterion for 'last played' is; evidently it triggers a Play as soon as the track starts playing, rather than XX% completed). I'm surprised, as I thought shuffling a playlist added a random selection to the Queue, and ignored any changes to the original playlist? This was done through the Web UI. There was no issue through Gear for Mac, which doesn't remove recent recent plays from the playlist full stop (not sure why).

If you save a playlist without naming it (stupidly!), you can't re-click it to edit it, as no hyperlink is created. Maybe use an [untitled] default title if the user messes up?

I'm not actually sure if this happens anymore, but I seem to remember triggering it.

Sourced from this mailing list post:

Took me a while to realize that if you used the 5 star system prior to it going away the 5=thumbs up and 1=thumbs down doesn't hold true. I.e. I have 1-5 in the mix. Might be worth updating the notes as I thought it wasn't working.

So I had suspected this as a problem for a while, but I hadn't confirmed it until now, when I accidentally recreated it on my account.

streamingloadalltracks turned out to be the key, since it actually sends back json. I was getting back:

{"success":false, "reloadXsrf": true}

Sure enough, the xt cookie had been changed.

We'll need to have the background script detect this and send a message to the content script to retrieve it. I confirmed that window._GU_getCookie('xt') returns the new token.

That would be useful for badly tagged uploaded-and-not-matched songs.

I think this involves me uploading sourcemaps to Sentry, since the source is hosted locally: https://docs.getsentry.com/hosted/clients/javascript/sourcemaps.

Even though playlists are limited to 1000 songs, is there a way you could show the real number of matches when testing a playlist definition? I.e. in Matched X tracks. The first was ... the X should be able to exceed 1000.

I was trying to see if any of my tracks didn't have ids in uuid form, so I tried "id does not contain ........-....-....-....-............". This returned all my tracks. However, "id contains ........-....-....-....-............" also matched, so I think all of them are in uuid form and "does not contain" is just broken for this case.

I can't see anything related to this so wondering if it's isolated (or I didn't look too well).

There is a problem, followed by questions. If you'd like me to split these into two topics I can but thought it's best not to when they are questions relating to the same playlist rather than two seperate problems.

I have a playlist that is created by "greater than rating 3" AND "last played before 30 days ago" and sorted by "last played descending". And limited to 1000. I think they are the terms but away from the pc.

Main problem is, the playlist summary says the rules give a total of over 2000 songs and originally the limit meant the playlist was 1000 songs exactly. But since clicking thumbs down on a number of songs they appear to be removed instantly from the playlist and it has reduced to 980 songs but hasn't repopulated with new songs that match the criteria even though there are plenty of sings that do. I think the reduction is due to thumbs down and not the last played criteria but not certain.

The playlist seems to be updating occasionally (the title of the playlist says that anyway) although I noticed it hadn't updated since yesterday until I went into the playlist and saved it again. Although this is not my concern at the moment, nor have I looked into what could cause it to not update for the past day.

First question is, before 30 days ago means more than 30 days ago, as in 30, 31.... 100 days yes?

Second question is, last played ascending sorts them into 30 days ago, 31 days ago, 32 days ago.... A long long time ago yes?

Regards the rating condition.

The "unrated" rating equals null if the track has never been rated.

Deselecting thumbs up or down to get get rid of a thumbs makes the rating equal 0.

So "unrated" is null and de-rated is 0.... Or maybe use better terminology.

Sourced from this mailing list post.

It seems like they're looking for this option as a workaround for the 1k playlist limit, which is something that's been mentioned before (though I think in the context of "include random songs until the playlist reaches 1k).

I'm not sure how exactly the ux for this should work, since the simplest (stateless) implementation would shuffle the list every minute.

Sorry but I don't have a debug but happy to do so if you suggest the best method (seeing it doesn't happen during usage).

I think the extension gets de-activated, perhaps due to security settings.

I hope this the right way to post problems.. First day on github and not familiar with how it all works.

I created a playlist with rating "does not equal" certain values (0 to 5 I believe play uses). On the extension it says there are songs that fit the category of the playlist but google play music see only empty playlists. Although the playlists names are in my library, just empty.

The manager interface queries storage for a few different items now, and there's noticeable blinking now as elements get hidden or shown.

Rendering should be delayed until we know what the interface will look like.

The matched tracks - or at least the number of them - should show up when playlist rules are being updated. Lovefield should be fast enough to do it realtime.

This is mostly useful for me to move my definitions between development and store copies of the extension, but could be nice for other people too (maybe to enable sharing?).

The old import/export code does most of this already. It'd need to be adapted for plaintext input and output rather than drag events, though.

#30 seems to be happening for me on stable 49 + linux.

Currently, remote playlists are handled like a set: when we update, we add and delete the minimum amount of tracks to result in the desired tracks. This doesn't respect the desired ordering, but does result in the correct tracks.