Pandora radio via Firefly to Roku?

[eagledart]

Ron,

Have you played with Pandora radio yet? I’ve heard about people doing horribly convoluted hacks to get Pandora to stream to their Roku. Is this not something that could be made much easier via Firefly?

It would be very, very nice.

I’m still in the process of rebuilding my media server (starting from scratch, doing it “properly” this time… you know how it goes…). When I’ve got that done and Firefly working properly, I’ll attempt this myself. If I’m successful I’ll post the hack here, but I don’t hold out much hope (being a rank amateur in sooo many ways 🙂

cheers,
eagledart

[rpedde]

@eagledart wrote:

Ron,

Have you played with Pandora radio yet? I’ve heard about people doing horribly convoluted hacks to get Pandora to stream to their Roku. Is this not something that could be made much easier via Firefly?

It would be very, very nice.

I’m still in the process of rebuilding my media server (starting from scratch, doing it “properly” this time… you know how it goes…). When I’ve got that done and Firefly working properly, I’ll attempt this myself. If I’m successful I’ll post the hack here, but I don’t hold out much hope (being a rank amateur in sooo many ways 🙂

cheers,
eagledart

I haven’t seen pandora radio, and I know there are people that want to do streaming radio transcoding through mt-daapd.

I remain convinced that that isn’t the place for it, but it’s something I was going to add a scripting interface for anyway, just to make people happy. 🙂

[eagledart]

rpedde wrote:

I remain convinced that that isn’t the place for it, but it’s something I was going to add a scripting interface for anyway, just to make people happy. 🙂

Well I’m glad to hear you’re considering the interface (when and what will that be?), but I’m curious as to why you think mt-daapd is the “wrong” place. Is that a technical, political or other objection?

By the way, I rebuilt my machine (after throwing it on the floor), was careful about setting up the network interfaces and now have mt-daapd running under ubuntu with no problem what so ever. I think part of my original problem was that I was using a wireless broadband router, a wireless bridge and a wireless roku. I now have the server hard-wired to the bridge, wireless from bridge to roku.

I’m grateful you went to the trouble of creating mt-daapd, I’ll be even more gratefull if you create an interface for streaming radio, and I’ll happily test it out for you 🙂

If you ever have time to kill, take a look at http://www.pandora.com It’s based on the music genome project and is free. Does require you to provide a US zip code (not hard), it allows you to create your own radio station and attempts to “learn” what you like.

cheers,
eagledart

[rpedde]

@eagledart wrote:

Well I’m glad to hear you’re considering the interface (when and what will that be?), but I’m curious as to why you think mt-daapd is the “wrong” place. Is that a technical, political or other objection?

Just that it’s a job for another tool… just like reading email or burning cds. It really isn’t in the scope of what this does. I don’t disagree that a transcoding web streamer wouldn’t be a good project, but it’s a project that isn’t this.

Well, that and it would just be an exersize in re-inventing vlc anyway, since that’s *exactly* what vlc does, but that’s another story.

If you ever have time to kill, take a look at http://www.pandora.com It’s based on the music genome project and is free. Does require you to provide a US zip code (not hard), it allows you to create your own radio station and attempts to “learn” what you like.

now that I look at it, I realize that I had indeed played with it before. It decided all I wanted to listen to was morrissey, and that’s really not *too* far off the mark. 🙂

[sansp00]

I vote for a api so that people with more free time can use it and develop their own plugin, just to keep Ron working on the important stuff ( the FF core ) and leave the outside enhancements to others to play with.

I don’t see online radio as a that off the mark. Just to be the devils advocate, Slim has it, so why could we ?

The other stuff, is mail reader which could use the roku display for other purposes should be put be kept out ( more for technical reasons, I don’t want to it to be binded to Roku ). But even outside FF, I would keep in streamlined with FF like a product suite of some sort.

My 2 cents
Patrick S.

[rpedde]

@sansp00 wrote:

I vote for a api so that people with more free time can use it and develop their own plugin, just to keep Ron working on the important stuff ( the FF core ) and leave the outside enhancements to others to play with.

Working on it. I have output plugins already, I’ll have db plugins soon, and that’s where this would go.

I don’t see online radio as a that off the mark. Just to be the devils advocate, Slim has it, so why could we ?

Because that’s what slim *does*. It’s single-stream sever-side pushed content. It’s a different idea alltogether. It has one output stream that you manage centrally. You decided what it plays, and it has a single firehose output that clients can hook up to. Smart server, dumb clients.

The daap concept is exactly opposite. Dumb server that just gives clients the location of media files, and a rock stupid web server to allow the clients to fetch them.

The “right” way to do with mt-daapd is to have those streams point to another program that does stream transocoding. That’s the unix way. Do one thing well.

Stream transcoding is another thing. And vlc already does it well.

The other stuff, is mail reader which could use the roku display for other purposes should be put be kept out ( more for technical reasons, I don’t want to it to be binded to Roku ). But even outside FF, I would keep in streamlined with FF like a product suite of some sort.

That was more along the lines of joke on Zawinski’s law, but there’s more proof.

— Ron

[sansp00]

Working on it. I have output plugins already, I’ll have db plugins soon, and that’s where this would go.

Great, Im anxious to get my hands dirty 🙂

The “right” way to do with mt-daapd is to have those streams point to another program that does stream transocoding. That’s the unix way. Do one thing well.

Stream transcoding is another thing. And vlc already does it well.

Im ‘new’ to the vlc stuff and to be honest, never did much research on this to nderstand the inner workings of it …
I do understand your point on the design and fully agree … But since and did not do a lot of ‘homework’ on the vlc and related stuff, I don’t quite understand all the inner working. Do you have urls that I could read up on so I can understand better how the plug ins will work, the vlc stuff and the prefered design of the implementation ? I would really like to write code for this. It will do a change from the *nix system programming I do all day lately.
Patrick S.

[rpedde]

@sansp00 wrote:

Great, Im anxious to get my hands dirty 🙂

Before I do that, I may add a scripting plugin using c-lang so stuff can be scripted rather than plugin’ed.

I’m thinking of moving that up, since there seems to be a lot of things I keep seeing that might be easy to implement that way.

Im ‘new’ to the vlc stuff and to be honest, never did much research on this to nderstand the inner workings of it …

VLC does *lots* of stuff that nobody knows about. It’s a complete client-server transcoding system among other things, including a http server, and wizards for setting up transcoding. Nobody knows that it does anything other than play .vobs, though. 🙂

Canonical docs are here:

http://www.videolan.org/doc/streaming-howto/en/

I would really like to write code for this. It will do a change from the *nix system programming I do all day lately.

Cool… maybe the c-lang interface is the place to start. Then it can be more insulated from the plugin format, plus it would make stuff that people could easily add or remove from their setup should they choose.

— Ron

[Author]

Posts