- This topic has 18 replies, 2 voices, and was last updated 14 years, 5 months ago by
.
-
Posts
-
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)
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?
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)?
@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
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)
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)
@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.
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)
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? 😯
@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.
The various behaviors, unless my test environment is tainted:
A) iTunes Client talking to iTunes Server: All extra metadata in Playlist URL entries saved in iTunes Playlists are hidden in normal “eyeball button” library Browse and the “search” box. (This is the exact same behavior when using iTunes locally.) The Playlist URL entries never appear outside of the Playlist itself; the “Library” doesn’t see it.
B) iTunes Client talking to Firefly svn-1301: All extra metadata in Playlist URL entries are visible in normal “eyeball button” browse and the “search” box. Genre entries are the biggest offender, since the other fields are normally blank unless you’ve set them yourself. The Playlist URL entries appear in the normal library.
C) SoundBridge to iTunes Server: Equivalent of B.
D) SoundBridge to Firefly svn-1301 (thanks to your hack fix): Equivalent of A.
Make sense? “B” is the concern.
@grommet wrote:
B) iTunes Client talking to Firefly svn-1301: All extra metadata in Playlist URL entries are visible in normal “eyeball button” browse and the “search” box. Genre entries are the biggest offender, since the other fields are normally blank unless you’ve set them yourself. The Playlist URL entries appear in the normal library.
Ooooh… now I get you. The eyeball thing. I never use that.
No wonder I didn’t realize what you were saying.
Slight update to “D)” behavior with your hack… the Playlist URLs still appear in “Browse Songs” on the SoundBridge, so it’s not exactly like an iTunes client “A)” If one attempts to play all tracks randomly (Browse Songs… Play… Shuffle Button) , a Radio link can still be caught in the shuffle. Well, it would fail via RSP currently… but ignore that. 🙂
@grommet wrote:
Well, it would fail via RSP currently… but ignore that. 🙂
Yowch! Don’t forget to twist once you got that in!
Feel the love.
🙂
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.