Thank you for your donation!


Isolate external engines and refactor AirPlay
#1
Hi Tim,

In my never-ending quest to integrate Spotify into Moode, I did yesterday some reverse engineering into the AirPlay service and may have found some issues.

The AirPlay rendering of the UI uses a recurrent Ajax request that gets fulfilled only when it reaches a certain level of completion. This can be even a couple of minutes of playing the same song. But how it accomplishes this may be the source of why metadata through AirPlay is mostly hit or miss.

I did a test with sockets instead of this archaic approach of non-fulfilling-requests and it gets certainly more stable and reliable. Maybe it's worth looking into that approach?

Also, the airplayactv variable is not centralized correctly, it is used here and there, so adding another service like Spotify or maintaining the AirPlay becomes really cumbersome.

I think that isolating the Player to a state of 'external engine' and then having each engine just pass the required variables to the player would be much easier than going on and adding more "and"s and "or"s everywhere.

What do you think? I could invest some time on achieving this if you think is something that could be useful and create a pull request.

Hope this helps,
Rafa.
Reply
#2
Hi Rafa,

I actually dropped the Airplay metadata feature from upcoming moOde 4.1 due its unreliability, but if you have a reliable solution or approach then I'll be happy to have a look at it :-)

moOde 4.1 also includes a central mechanism that detects when Airplay, Bluetooth or Squeezelite renderers are active and then alters the UI to reflect this. Its also used to enable "Resume MPD after Bluetooth" feature :-)

-Tim
Enjoy the Music!
moodeaudio.org | Twitter Feed | Git Repo
Reply


Forum Jump: