MMM-Spotify

[A Former User]

i correct it with last update :)

1.3.2 (2020-05-15)
Modified: onStart script (Now launched if Spotify initialized)
Added: "Cast" Icons
1.3.1 (2020-05-14)
Modified: 'progress bar'
Fixed: number of request on idle (depend now of updateInterval config)

[A Former User]

@mmmmh :

sorry, I take over the project … and its bugs!
I correct little by little :)

note: after … I understand why my mirror crashed with this module!
now it’s better :)

thinking to @eouia who love when I fixed bugs

[mmmmh]

@Bugsounet, thanks for fixing it. From the changelog, should I expect that many requests again when not on idle?

[A Former User]

I will try to improve it…
actually i’m working arround another bug …
multi account and connected / disconnected notification …

with one account it’s works correctly but not with multi :(

bouah !

it’s horrible, in multi-account mode, MMM-Spotify tries to connect to all accounts to send news live

I really wonder if the multi-account mode is really a good feature

and of course … wow it spam like it can not connect to the account that we do not use

humm, how to manage this mess !?
i will impect …

Note:

• with multi account, I think It can crash the RPI … (so so so so … more loop)
• in my dev platform (desktop with debian linux):
  • in idle: CPU 3%
  • with buggy playing multi-account : CPU 36%

It’s very very high !!!

[A Former User]

So…

I propose this (and i have already coded a part of it in other dev) :

• a single account checking and displaying (default account in config)
• Changing account is by vocal (like Jarvis ... Spotify account name)

name is the USERNAME defined in the spotify.config.json file
Of course, i will add this function in AMk2 Spotify recipe

Result:
Less CPU time, Less DNS request, Less Loop for Checking … More Free Memory and RPI will be better

what do you think about this ?

[A Former User]

v1.4.0 (2020-05-16)

• Added & Modified: Multi-account management by notification SPOTIFY_ACCOUNT
• Fixed: Loop CONNECTED/DISCONNECTED on multi-account
• Fixed: Less CPU time, Less DNS request
• Fixed: Maybe RPI crashed when using multi-account (memory leaks)

[mmmmh]

Regrettably, DNS requests are still too many. I see 1000 in 10 minutes (purple is a fresh install of MagicMirror with just the clock and the Spotify module):

[A Former User]

I think the best solution is Don’t use it
(like my other modules)

[A Former User]

Sorry for bothering you guys with my kinky ex-module.

The problem is; There is no server-pushed way to get current playback in RPI with spotify api.
So to get current playing data, frequent api callings are needed.

Possible solution under current condition is; removing some features - like progress bar, displaying playtime… So then too many requests are not needed.

In other platforms like desktop PC, Google Chrome has widevine/DRM so we can use “web playback api”, it can make direct playing spotify on browser level, and get playback data directly. But not possible in rpi natively.

Some hacks for widevine exist for RPI chromium, but our MM’s electron still miss that feature.

But! I’ve heard newest Electron(9.0) has a new Chromium(80? 83?) and it might have widevine supported (I haven’t tested yet, or never…)
I’m not sure it would be supported in rpi or not but if who has interest, worthy to try. If supported, you can build a new module which can play spotify directly without raspotify instead this poor module.

[mmmmh]

@Sean Thank you for chiming in and for providing a more elaborate response. I thought that the constant polling might be the reason. If I may comment, for other users it may be helpful to put it in the documentation that using the module leads to increased network traffic.

I for one would be happy with a display of the static per-title information and the controls, I will observe what happens when I crank the refresh rate up to 30000 milliseconds.