Streaming Internet Radio items not working with RSP

FireFly Media Server Firefly Media Server Forums Firefly Media Server Nightlies Feedback Streaming Internet Radio items not working with RSP

Viewing 10 posts - 1 through 10 (of 19 total)
  • Author
    Posts
  • #374
    grommet
    Participant

    Streaming Internet Radio stations in iTunes Playlists, now supported as of svn-1249, do not work with SoundBridge 2.5.157 over RSP. πŸ™ SoundBridge displays an “X” in front of each item (meaning it can’t be played)… and, when attempting to play, you see “This music format is not supported.” It does, however, work fine over DAAP.

    It works fine from iTunes clients, too… obviously…. since it’s DAAP. πŸ˜€

    Firefly svn-1249 (Win32)

    #5145
    grommet
    Participant

    Also:

    2) The “Comment” metadata that can exist for the radio station stream entry (Playlist URL) does not get exposed by Firefly. (iTunes does expose it.)

    3) With iTunes as a client to Firefly, the Playlist URL entries parsed appear in “normal” music browsing & search… for example, the “Genre” metadata is littered with the Genres supplied for streaming radio station entries (which often, uh, suck). With iTunes as the server to an iTunes client, the Playlist URL entries are suppressed in normal music browsing… (no garbage Genres, etc.). They only appear when browsing a specific playlist. So, Firefly is doing something different here. πŸ˜• Missing a tag?

    #5146
    grommet
    Participant

    OK, #1 will be fixed (as mentioned in other thread; RSP related issue that Roku will address)… Cool.

    Any comment on #3 (and the less important #2)?

    #5147
    rpedde
    Participant

    @grommet wrote:

    OK, #1 will be fixed (as mentioned in other thread; RSP related issue that Roku will address)… Cool.

    Any comment on #3 (and the less important #2)?

    #2 is easy — I’m not picking up the comment from the iTunes xml.

    #3 isn’t, not sure what that’s about. I have a capture of a iTunes radio station dump, I’ll have to double check it and see what they are doing differently.

    — Ron

    #5148
    grommet
    Participant

    Re-posted from Roku forum, since it’s related directly to #1 & #3.

    Ron… when iTunes + RSP Playlist stuff is fixed and if you attempt to do M3U playlist multiple URL support, make sure you guys end up copying how iTunes clients work if at all possible… so the radio station links and metadata does not inject extra items into normal “song” browsing. No extra “songs”, “genres”, etc.

    Like iTunes to iTunes behavior, radio station links/metadata should somehow be suppressed outside of Playlists. Nobody wants to get stuck in a radio station stream while playing “All Songs” randomly or, say, a Smart Playlist for the Rock genre. Yuck. Ok, rant off… 8)

    #5149
    grommet
    Participant

    Ron,

    Can you add an option to toggle the iTunes XML Playlist parsing on and off? Off by default might be nice for now, especially until SoundBridge & RSP can handle it (#1)… and until the iTunes radio suppression works, too. (#3)

    Not only do I get library pollution… I can’t even play it on my beloved SoundBridge thanks to DAAP hiding. 8)

    #5150
    rpedde
    Participant

    @grommet wrote:

    2) The “Comment” metadata that can exist for the radio station stream entry (Playlist URL) does not get exposed by Firefly. (iTunes does expose it.)

    3) With iTunes as a client to Firefly, the Playlist URL entries parsed appear in “normal” music browsing & search… for example, the “Genre” metadata is littered with the Genres supplied for streaming radio station entries (which often, uh, suck). With iTunes as the server to an iTunes client, the Playlist URL entries are suppressed in normal music browsing… (no garbage Genres, etc.). They only appear when browsing a specific playlist. So, Firefly is doing something different here. πŸ˜• Missing a tag?

    Both of these are in svn.

    I’m not sure iTunes does suppress that stuff in browse. Against an iTunes server, I can browse for “Artist” on a stream. Don’t know about anything else, but at least some metadata is exposed in searches.

    It isn’t in firefly now. Not sure if that’s a misfeature or not. If anyone complains, then I guess it could be a config option.

    #5151
    grommet
    Participant

    Cool!

    Yeah, iTunes doesn’t suppress everything radio related… but enough to not make it painful. This probably has more to do with the client suppression logic, which SoundBridge might need to improve… (Or is it a deficiency in queries the protocol allows?) The biggest concern would just be getting radio URLs by mistake, as I mentioned. Just have Roku take it into account as they workout the RSP + Playlist stuff. Seeing junk Genres listed, for example, isn’t that big of a deal… just ugly.

    So, is your fix for #3 doing it the way iTunes does it (iTunes to iTunes)… or is this different? I guess I’ll find out if it hides more than iTunes with SoundBridge? 8)

    #5152
    grommet
    Participant

    Ok, returning to iTunes client with Firefly “playlist” behavior…

    I don’t think #3 is really fixed in this svn for iTunes clients.

    Something is still “different.” iTunes Playlist URL metadata continues to populate/taint the normal library browse with an iTunes client. When iTunes is used a server, the iTunes client nicely suppresses them. (Just like iTunes does with local Playlist URL metadata.) So, Firefly/DAAP must not be flagging the Playlist URLs the same way when the iTunes client sees it.

    (Note: SoundBridge doesn’t suppress most Playlist URL stuff. That’s either a SoundBridge bug/oversight… or it’s somehow not technically possible in the way Roku talks via iTunes DAAP. So, using SoundBridge as a “test” doesn’t count for #3.)

    Your fix attempt for #3 (in svn-1301) does fix the polution for SoundBridge, though. It looks like you are filtering the extra Playlist URL metadata at the Firefly search query level, so SoundBridge doesn’t even see the items returned. That’s a good hack fix, assuming Roku has no real way to do this on the client.

    So, I guess it’s “fixed” for SoundBridge… but Firefly still isn’t doing something correctly for iTunes. πŸ˜• Does this make sense? 😯

    #5153
    rpedde
    Participant

    @grommet wrote:

    Your fix attempt for #3 (in svn-1301) does fix the polution for SoundBridge, though. It looks like you are filtering the Playlist URL metadata entires at the Firefly search query level, so SoundBridge doesn’t even see the items returned. That’s a good hack fix, assuming Roku has no real way to do this on the client

    Explain to me what you perceive the problem to be, with examples, including what the behavior is on what clients. I’m apparently not understanding what it is you are saying. Compounding that is the fact that there are three different ways to retrieve data from the database, and I’m not sure which way we are talking about — rsp, query/browse over daap, or standard daap.

    Somehow I’m completely missing what it is you are saying.

Viewing 10 posts - 1 through 10 (of 19 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.