Micheal: would this be yours to address or Andy's?

Connected to SN or SBS the same thing happens.  Using the knob to 'select' a category will play that category, not drill down and display the play list.

Same thing happens on Fab4 and Jive

Is this related to touch=play instead of touch=drill down?  Does it still work that way?

Ben/Tom - do you have any input on this one? Sounds rather like a UI issue than data.

Changed to P1 since this function is required prior to sending a unit to Mediafly for approval.

Tom - I'm assigning this to you lack of better knowledge. It's indeed the touch=play issue. MORE would bring up a context menu with all the various streams.

Punting to Andy. I think the issue here is that Mediafly list items are coming back as a "play" item rather than a type="playlist" item, which I believe is coming from SN code. The touchToPlay sub is coming back true on $item->{"play"}

[09-09-02 08:36:02.3700] Slim::Control::XMLBrowser::touchToPlay (1314) here
[09-09-02 08:36:02.3712] Data::Dump::dump (100) Warning: {
  items => [],
  name  => "Business And Finance",
  play  => "mediafly://channel/3f4c67bed8a64b04a3c3388479161400",
  type  => "link",
  url   => "http://www.test.squeezenetwork.com/api/mediafly/v1/opml/channel?slug=3f4c67bed8a64b04a3c3388479161400&name=Business%20And%20Finance",
  value => "http://www.test.squeezenetwork.com/api/mediafly/v1/opml/channel?slug=3f4c67bed8a64b04a3c3388479161400&name=Business%20And%20Finance",
}


However, this seems a bit like an odd case, because it looks like this might not quite be a playlist situation either = (that is, play the list of underlying tracks)

Users can do a CM here to get the specific item, but that seems like a very odd interaction. Maybe we need some distinction in our "touch to play" logic which allows for item->play to exist but still have it drill in on touch.

It seems like it's exceedingly tricky to be able to analyze an OPML item and know what it's behavior should be.

In this case, there is a 'play' key and a 'link' key. Can we consistently say that this is a drill-in not touch-to-play item?

related: bug 13462

This should not be touch-to-play.  I really disagree with the touch-to-play design.  The item should have a music note icon like on ip3k to indicate it can be played with the play button (but I don't expect we'll ever see this on SP). :(

I don't disagree with you Andy but that's not really the issue here. In this case I think the idea is that this item is not even supposed to be touch-to-play, and how do we identify it as such while doing the new behavior on others.

What I'm confused about is the inspection of XMLBrowse items and determining what their behavior should be based on that. It could be that the touchToPlay() function is not quite logically correct, or it could be that we have no way of consistently deciding what the behavior should be. I don't know the answer to that.

OK so then any item with a play attribute is probably not a touch-to-play, because the whole point of the play attribute is to allow 2 paths: one via play and one via drill down.

 == Auto-comment from SVN commit #28417 to the slim repo by tom ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28417 ==

Fixed Bug:13685
Description:
- item->play is now not considered "touch to play".

Note that then the MediaFly episodes then also don't touch to play, which may be considered a bug.

How do I identify the MediaFly episodes as touch to play then?

Are we fundamentally screwed on XMLBrowse items because we can't identify the correct behavior because item A might have identical play/link flags as item B but require a different logical behavior?

Yes I think we're screwed, touch-to-play is generally a bad idea.  We need the equivalent of the ip3k music note to indicate when you should press the play button.  On the Touch UI, we should have a separate play button on the right-hand side (from an old design concept).

Andy, now the episode item isn't touch to play, and context menu for an epsiode
doesn't work, which according to Ben, should be a touch to play item...

The only solution I can think of is what I posted above, but it conflicts with the design.

I'm not sure I follow. I think there might be a different bug about the visual indicator, but here the episode should be touch to play, but isn't.

So are you saying we have to go through every menu on a case-by-case basis and figure out what should be touch-to-play and what shouldn't??  That will lead to a massive amount of inconsistency.

*** This bug has been marked as a duplicate of bug 13462 ***