Google-play-music-desktop-player-unofficial-: Websocket not emited from GPMDPU

[Nsbx]

OS:
Windows 10

Issue Descriptions:
Hello :)
I have devellop an integration of GPMDPU in discord (screen : https://i.redd.it/o98m080g288z.png) with websocket
Problem sometime the "time data" is not emited from GPMDPU.
Precisly when the windows is minified in the task bar.
But when i reopen GPMDPU, my time bar in discord re-work fine.

I don't know how i can help you to reproduce the problem given i have develop my own integration but if you want more information about my code for example ask me i will show you ;)

debug_info.zip

Thank for advance :)

[Alipoodle]

I've also been experiencing this problem.
It also effects the "Show Progress in Task Bar" and simply leaves it at the last point of the song you were at.
Album, Title and Artist work.

On another note. @BleuDiamant are you using BetterDiscord for that and a custom Plugin?

[jostrander]

It sounds like GPM stops updating the UI once it's minimized, which could be very detrimental.

[Nsbx]

@Alipoodle That exactly that :) No, currently I inject my script manually but i can try "better discord" :)
@jostrander Yeah :( but for some strange reason sometime i receive the packet even minimized

[MZimmermann]

It affects the JSON-api as well. I use it in order to display artist/album/title/song progress via a rainmeter-Skin and as soon as GPMDP is minimized, the time-values in the file retain their last value and won't get updated until GPMDP is re-opened again. Maybe "change:playback-time" is only triggered in a non-minimized state?

[MarshallOfSound]

Can't replicate on macOS, assuming it's a windows specific thing, will explore when I get back to aus

[MZimmermann]

Maybe not reproducable on macOS, but not a Windows-specific problem either. I'm able to replicate it on Linux as well (Fedora 25 with XFCE). The option "minimize" to tray" doesn't seem to make a difference by the way. As soon as it's minimized either way, the time-values in the json-file cease to update.

[MarshallOfSound]

@MZimmermann It's probably a recently added GPM resource saving technique (don't update the UI while the page is hidden / minimized). Currently I only have my macOS machines with me though so I won't be able to investigate till I get back from holiday 👍

[jostrander]

Confirmed issue, definitely stops updating the JSON file when minimized. Does not happen when off screen however. The track information still updates on song change. However the progress status does not.

[MarshallOfSound]

@jostrander At the moment we get track progress from the DOM progress element. I think we are going to have to somehow get it from the Audio element or something, gonna take some investigating. Or maybe disable backgroundThrottling in electron 🤔

[jostrander]

You can visibly see the progress bar update from its last location to the current location when restoring the window, and definitely confirm the aria value and value are not updating on the DOM when minimized. We'll either need to grab it from the audio element, or in the JS somewhere if we can find the object they use to update the UI.

[MarshallOfSound]

@jostrander Or figure out how they know the window is minimized and trick them into thinking it isn't 😉

[jostrander]

While I agree with the principal in order to not break things, we shouldn't do that for people who wish to save energy consumption and/or notify API users that it will use more CPU to keep the API enabled.

[MarshallOfSound]

Yeah, we should definitely look for less brutal ways to get around the issue than disabling the resource saving features of GPM

[jostrander]

In other news, there used to be only one Audio element, now there are 4? Maybe we can look forward to cross fading in the future from Google or some other feature I haven't thought of...

Also, with the audio element being a blob/stream we can't use the currentTime of the audio element because it just keeps counting between tracks and doesn't reset.

[MarshallOfSound]

OK, so I got back to my windows machine. And I can't reproduce this 😕

Minimizing GPM still emits the events for me

[MarshallOfSound]

That said if we want to use an alternative source for the current progress through a track document.querySelectorAll('audio')[1].currentTime appears to return the correct value all the time 👍

[MZimmermann]

Very curious that it's not reproducable. Is google known for silently rolling minor new features out in waves? I.e. could it be that not all accounts get served the new code that stops the UI-updates once the player is minimized?

[Nsbx]

If i minimized GPMDPU just after launch the socket is emited but if i minimized after couple of minutes this doesnt work

[MarshallOfSound]

Fixed in https://github.com/gmusic-utils/gmusic.js/commit/68d7e9da110a0c0eb8a5a174c16b91b609bbabd8

[MZimmermann]

The problem re-emerged with 4.5.0, minimizing to taskbar or tray will cause GPMDP to stop updating the JSON-file (at least under Windows 10, but I'll re-check tomorrow at work with my linux-machine).

EDIT: Yep, just checked, same problem when using the Fedora 26 x64. This ist the "energy-save-when-minimized"-thing all over again.

[phiter]

This is still happening. If I minimize the app, the taskbar progress indicator doesn't update.

This also happens even if the current song changes. The title in the taskbar will change to the new song, but the progressbar will stay frozen with the timing of when you last minimized the app.

[n00levoy]

Yeah, looks like this problem is totally back again here (on Windows 10 machine, GPMDP 4.5.0). Can confirm that when the app window is minimized (or minimized to tray) the WebSocket server stops sending messages, the app icon in the taskbar doesn't update its state and the scrobbler starts working unstable (or stops working at all).

I got used to it already though and just never minimize the GMPDP window, but it's a clearly bad and inconvenient option.