"last played" playlists cut off tracks that are playing when updating the playlist

[johnrobertlawson]

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).

[simon-weber]

Weird; #8 made me think that the field wasn't updated that accurately.

In the meantime, you could work around this with something like:

• any
  • last played before 30 days
  • last played after 5 minutes ago

which can false positive in a number of ways, but is probably better than the current situation?

[johnrobertlawson]

Yeah, I'm still trying to work out in which circumstances the play count isn't registered. I wonder if it's "saved offline" on mobile?

Good idea. Though you underestimate the amount of Pink Floyd in my collection with those five minutes.

[simon-weber]

Hm, I'm having trouble reproducing this. I tried:

• create playlist with just rule "last played before 30 days"
• set periodic sync interval to 10 seconds
• play songs of about 1 minute through the web client

It seems like lastPlayed is being reported only at the end of a track playing, so the playlist doesn't remove tracks while they play.

@johnrobertlawson, can you try again and see if this is still a problem? It could be that reporting lastPlayed early was a Google client bug that's now fixed.

[johnrobertlawson]

I tried again yesterday, and it's an issue for me still, unfortunately. It kills the track and removes from the playlist ~20-30 seconds into the song.

Also, the play count in the UI ticks over about 5-10 seconds into playing the song for me.

[simon-weber]

Woah, so I just recreated this: it seems to only happen with AA tracks!? I have no idea why they'd have play counts recorded differently, but they do consistently tick over at 12 seconds in, while uploaded tracks tick over only once the track is finished playing.

This feels like a bug, so I reported it via their built in feedback tool. Who knows if they'll see it. Between this and gmusicapi we find the most bizarre bugs. . .I really wish I had a better way to report them.

[simon-weber]

d60fe2b syncs less often (every 5 minutes instead of 1), which will prevent this for shorter tracks. We could potentially bump this even higher if we want, but I'd rather not push this issue under the rug at the cost of update latency.

I don't think we have many other options to address this on our end: the core problem is that playCount is being updated while a track is playing.

How well is the "last played after X minutes ago" workaround going?

[johnrobertlawson]

It doesn't work while there's an issue with "Any" #21 .

[simon-weber]

Ah, right. I'll see if there's anything we can do temporarily to get it working.

[simon-weber]

@johnrobertlawson that should be fixed in https://github.com/simon-weber/Autoplaylists-for-Google-Music/releases/tag/0.2.1; let me know how it goes.

[johnrobertlawson]

The latest 0.2.1 is labelled as 0.2.0 in chrome://extensions - is that just a typo?

[simon-weber]

Whoops, it is. I forgot to upgrade the version: https://github.com/simon-weber/Autoplaylists-for-Google-Music/blob/5a834a7352045a7ad2f1e248d3d58ad1a19e76a4/src/manifest.json.

I think that Chrome will install it anyway, but I'll upload a new one later just in case.

[simon-weber]

Ok, you can use https://github.com/simon-weber/Autoplaylists-for-Google-Music/releases/tag/0.2.2 to be sure of the version. Thanks for letting me know!

[simon-weber]

I managed to figure out a (mostly) reasonable way to deal with this. When syncing a playlist, tracks that are likely playing (lastPlayed > now - trackLength) won't be deleted. This required adding logic inside the google music client library - which I'm not super happy about - since that's the only place we have access to the playlist diff.

There was another catch, too: for whatever reason, all recently played tracks have lastPlayed equal to 0 when retrieved via loaduserplaylist. This meant also adding a query to the track cache inside the client library. The end result works as you would expect: tracks are removed automatically, but only once they're finished playing. Skipping tracks will throw this off, but only by delaying the removal by the time you had left in the track.

I'll have to experiment with the lastPlayed = 0 semantics -- if it gets properly set after some short amount of time, we might be able to just use it instead.

[johnrobertlawson]

OK, so my two playlists aren't updating in Google Play, but the values when I "test" the script in the extension are fine. Both involve "last played": one is just the last 100 tracks played in reverse chronological order, and another is the "Not played in 60 days; 5 stars" autoplaylist.

[simon-weber]

Huh, that's odd. You're sure it's not just the ordering that's incorrect (#9)? Is there anything interesting in the logs? Does doing a force update work?

It might also be that the sync interval is too long now. https://github.com/simon-weber/Autoplaylists-for-Google-Music/compare/lastplayed addresses that as well.

[johnrobertlawson]

Hmm, the "not played in 60 days" is fixed this morning - I'm wondering if there's a longer lag like you say - but "last played" is broken when you sort by chronology. That's been reported elsewhere though right?

[simon-weber]

"last played" is broken when you sort by chronology

By broken, do you mean there are songs present/not present that should be? Or do you mean the ordering is wrong, but the expected tracks are there?

The ordering being wrong is known (#9), but I'd expect the set of tracks to be correct.

[johnrobertlawson]

Both issues: the list also includes recently added tracks to my library that I haven't listened to. But it seems to have the correct tracks (hard to conclusively say).

[simon-weber]

Ah, right, I forgot that #8 complicates this even further, haha.

[simon-weber]

It looks like Google fixed the weird AA difference I noted in #18 (comment), so I'm going to remove my code to work around it.