MMM-Spotify

mmmmh

What would the best approach to hide other specific modules when this module is active, i.e. when music is being played?

It may be to early to ask this since @Bugsounet just volunteered a few minutes ago to take over this project so take your time with your feedback.

A Former User

leave me a few days … I have to inspect the entire API :)

sdetweil

@mmmmh i tried to use watchdog for another problem, but there were normal disconnects between the front and back ends, which WOULD have recovered, had watchdbog not restarted MM… I gave up

mmmmh

@Bugsounet Take your time.

Currently, the module already has awareness about playback activity. An API call to an endpoint of my choosing on state change would already solve it for me. The endpoint could also be MMM-Remote-Control’s API.

I guess I can sift through the module’s code and see if with my humble skills can insert a simple request at the proper place. We’ll see how it goes.

A Former User

don’t worry ;)
I was trained by @eouia!

A Former User

MMM-Spotify

new owner, new version, new change :)

v1.3.0 (2020-05-13)

Fixed: on lost internet connexion
Added: SPOTIFY_CONNECTED SPOTIFY_DISCONNECTED notification
Added: debug mode
Added: deviceDisplay feature
Added: handling for extra device icons
Added: debug mode for Hiding console logs (memory leaks)
Added: fade in transition on cover
Added: box shadow around cover to highlight from background

Again, not in the change log

Fixed : Spotify Free ads errors solved

mmmmh

@Bugsounet Cool additions and fixes. I need to find out more about the notifications to learn how to disable other modules when music is streaming.

A Former User

I make a developer tools module for displaying notification and payload Read there :)

I think it can help you

mmmmh

@Bugsounet Very interesting. This also looks promising. I’ll comment in the other topic.

mmmmh

@Bugsounet I noticed in my pihole logs that there were at least 10 DNS queries for Spotify per second, something is not right. The actual refresh rate for the module is set to 3000 ms. I had to disable the module.

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.