4 ms·

Playback of whatever media on a SBC (rpi etc) is not the problem. Of course, it's great to have more software doing this and I applaud the effort (personally I'

Playback of whatever media on a SBC (rpi etc) is not the problem. Of course, it's great to have more software doing this and I applaud the effort (personally I'd have leveraged gstreamer and saved a load of time since I've used it before). The real problem, quickly dismissed in this article, is support integrated into 1st party apps. Chromecast lets you use a streaming platform app 100% normally and then 2 clicks later it's playing on your big screen/speakers. You could implement some sort of bridge app (that you'd "share" the content to) but then you are switching between the streaming app for content discovery, and the bridge app for control. That's not the chromecast experience. The only way we can get that experience is with 1st class support built into the streaming app. Spotify/Google/soundcloud/Amazon have no reason at all to work on adding support for something new until it becomes popular, but that's obviously a chicken and egg situation. Chromecast support is already built in everywhere, but of course that's a non-starter since Google have locked everything down sufficiently to prevent implementation of a receiver. I don't know the answer to this.

hackkitten 7y ago
I do not feel that I dismissed support for 1st party apps in the article. In fact, I have considered doing so for Netflix and Spotify, among others. Some have a control API for the 1st party app, such as what is used on Android, for example. It's however a lot of work, with spotty documentation and questionable support. That's why for the first release I haven't really bothered with it too much and instead focused on the core functionality of streaming audio and video, and controlling the NymphCast server from the client. (I'm the NymphCast author)
- kingosticks 7y ago
  > In fact, I have considered doing so for Netflix and Spotify, among others I must not understand because my argument is that the support absolutely must be built into the netflix and Spotify apps themselves, that seemless integration is what makes chromecast so usable. The media discovery and control needs to be in their app, not split between two different apps. So what can you do, other than provide a library for Spotify and Netflix to then ignore?
  - hackkitten 7y ago
    My apologies, I thought you were talking about the server-side. On the client side having it integrated into the 1st-party client apps would be great, yes. Right now in the SoundCloud app I implemented a basic track/album/author search function that uses the server-side app to search through the SoundCloud database. Though barebones right now, it provides essentially the same functionality as using the SoundCloud website directly. I can imagine this approach working in a generic fashion, assuming some network-accessible API is available that provides this information.
    - kingosticks 7y ago
      The problem is that you end up trying to reimplement the functionality of multipe 1st-party apps. Each of these different providers has their own API with its own issues. You'll never do as good as job as the 1st party client, and that's assuming they even give you API access (tidal don't provide a public API, Spotify's API is a subset of the functionality, others impose rate limiting etc). The only scalable solution I can see is to have service providers integrate your tech. But how to get them interested? Don't get me wrong, I think this would be a great thing to have and I'd love to get involved. For audio playback there is Mopidy (I'm a maintainer) which provides something similar but it would be so much better if there was a open chromecast-like protocol we could hook into and integrate into 1st-party apps rather than requiring the use of our clients.
      - hackkitten 7y ago
        Maybe you misunderstood me. I have made available a client SDK that will allow anyone to create a NymphCast client with accompanying app on the server. I have intentionally made this the same as things work with ChromeCast.
        kingosticks 7y ago
        Apologies, maybe. I understood it that I can't use the actual soundcloud app with all its functionality that I'm used to. The same app I use when I'm playing music on my phone. I have to use your client app as that's the one which includes support for nymphcast. That's your client app where you've re-implemented some subset of the functionality I want. Soundcloud could integrate the nymphcast client sdk into their app and then I'd have the same experience I get now with chromecast, but why would they do that?

hackkitten 7y ago

I do not feel that I dismissed support for 1st party apps in the article. In fact, I have considered doing so for Netflix and Spotify, among others. Some have a control API for the 1st party app, such as what is used on Android, for example. It's however a lot of work, with spotty documentation and questionable support. That's why for the first release I haven't really bothered with it too much and instead focused on the core functionality of streaming audio and video, and controlling the NymphCast server from the client. (I'm the NymphCast author)

kingosticks 7y ago
> In fact, I have considered doing so for Netflix and Spotify, among others I must not understand because my argument is that the support absolutely must be built into the netflix and Spotify apps themselves, that seemless integration is what makes chromecast so usable. The media discovery and control needs to be in their app, not split between two different apps. So what can you do, other than provide a library for Spotify and Netflix to then ignore?
- hackkitten 7y ago
  My apologies, I thought you were talking about the server-side. On the client side having it integrated into the 1st-party client apps would be great, yes. Right now in the SoundCloud app I implemented a basic track/album/author search function that uses the server-side app to search through the SoundCloud database. Though barebones right now, it provides essentially the same functionality as using the SoundCloud website directly. I can imagine this approach working in a generic fashion, assuming some network-accessible API is available that provides this information.
  - kingosticks 7y ago
    The problem is that you end up trying to reimplement the functionality of multipe 1st-party apps. Each of these different providers has their own API with its own issues. You'll never do as good as job as the 1st party client, and that's assuming they even give you API access (tidal don't provide a public API, Spotify's API is a subset of the functionality, others impose rate limiting etc). The only scalable solution I can see is to have service providers integrate your tech. But how to get them interested? Don't get me wrong, I think this would be a great thing to have and I'd love to get involved. For audio playback there is Mopidy (I'm a maintainer) which provides something similar but it would be so much better if there was a open chromecast-like protocol we could hook into and integrate into 1st-party apps rather than requiring the use of our clients.
    - hackkitten 7y ago
      Maybe you misunderstood me. I have made available a client SDK that will allow anyone to create a NymphCast client with accompanying app on the server. I have intentionally made this the same as things work with ChromeCast.
      - kingosticks 7y ago
        Apologies, maybe. I understood it that I can't use the actual soundcloud app with all its functionality that I'm used to. The same app I use when I'm playing music on my phone. I have to use your client app as that's the one which includes support for nymphcast. That's your client app where you've re-implemented some subset of the functionality I want. Soundcloud could integrate the nymphcast client sdk into their app and then I'd have the same experience I get now with chromecast, but why would they do that?