MMM-Spotify

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.

mmmmh

@Sean I hacked together a simple bash script (dnssaver.sh) that fetches IPs and stores them in the hosts file. If I call it with ‘api.spotify.com’ as argument and put it in my crontab it should take a load of the dns server. I’ll keep an eye on it.

Cr4z33

@Bugsounet either I am doing something wrong or there’s a bug.

I added onStart: null, in the module config, but the big Spotify logo keeps displaying all the time.