This is the dump of $item from a Pandora genre station. The touchToPlay sub in XMLBrowser doesn't see this as a touch-to-play item, but this begs the question: why does this item start the station playing when you select it?

 {
  items => [],
  name  => "Trip Hop",
  type  => "link",
  url   => "http://www.test.squeezenetwork.com/api/pandora/v1/opml/create?stationToken=184653528981422995",
  value => "http://www.test.squeezenetwork.com/api/pandora/v1/opml/create?stationToken=184653528981422995",
}

a quick audit of things in XMLBrowse land that I think should be touch-to-play:

Pandora Genre Stations (fail)
Pandora Saved Stations (fail)
Last.FM stations (pass)
MP3Tunes tracks (pass)
Napster tracks (fail)
Podcast Player individual podcast (pass)
RadioTime station listings (pass)
Rhapsody track listings (fail)
Slacker station listings (fail)


assigning to Andy for comment. Pass back my way after that...

failure debug-- these all did not come back true from the touchToPlay() check in XMLBrowser. Pandora saved station auto-plays, others drill in

$item dump from Pandora saved station

{
  items => [],
  name  => "The National Radio",
  play  => "pandora://12250187369256230.mp3",
  type  => "link",
  url   => "http://www.test.squeezenetwork.com/api/pandora/v1/opml/station?stationId=12250187369256230",
  value => "http://www.test.squeezenetwork.com/api/pandora/v1/opml/station?stationId=12250187369256230",
}
$item dump from napster track listing

 {
  _slim_id => 5,
  duration => 307,
  items    => [],
  name     => "This Is Goodbye by Blue Foundation from Dead People's Choice",
  play     => "napster://track:17352973.wma",
  type     => "link",
  url      => "http://www.test.squeezenetwork.com/api/napster/v1/opml/trackInfo?track=track%3A17352973&inLibrary=1",
  value    => "http://www.test.squeezenetwork.com/api/napster/v1/opml/trackInfo?track=track%3A17352973&inLibrary=1",
}
$item dump from Rhapsody Track listing

[09-09-03 23:42:20.2334] Data::Dump::dump (100) Warning: {
  _slim_id => 7,
  duration => 293,
  items    => [],
  name     => "8. Black S by Blue Foundation from Blue Foundation",
  play     => "rhapd://Tra.12419462.mp3",
  playall  => 1,
  type     => "link",
  url      => "http://www.test.squeezenetwork.com/api/rhapsody/v1/opml/metadata/getTrack?trackId=Tra.12419462&inLibrary=1",
  value    => "http://www.test.squeezenetwork.com/api/rhapsody/v1/opml/metadata/getTrack?trackId=Tra.12419462&inLibrary=1",
}

$item dump from Slacker station listing
 {
  items => [],
  name  => "'90s Alternative",
  play  => "slacker://stations/1603507/53.mp3",
  type  => "link",
  url   => "http://www.test.squeezenetwork.com/api/slacker/v1/opml/station_menu?sid=stations/1603507/53",
  value => "http://www.test.squeezenetwork.com/api/slacker/v1/opml/station_menu?sid=stations/1603507/53",
}

The genre stations are tricky, because to play them you have to first copy them to your list of stations, and then play them.  So a bit of (ugly) magic happens behind the scenes when you access one, and then they automatically start playing.  I'm afraid there is no good solution to this problem.  Maybe we need yet another custom attribute...

*** Bug 13685 has been marked as a duplicate of this bug. ***

(In reply to comment #0)

> 3. notice when selecting Some Station it does play immediately but does not
> properly push to the Now Playing screen

I just filed bug 13854, seeing something similar from My Music > Music Folder.  Is it related or a dupe of this bug?

Surely this isn't CAT2, as it's Fab4-specific right?

It is not Fab4 specific. "Touch to play" for Baby = "Press Knob to Play". This is basically working perfectly to design spec for local music, but not at all on XML Browse lists. What I'm lacking is a fundamental understanding of whether we can consistently determine that yes, this a "touch/press to play" item.

The failures listed in the earlier comment failed because touchToPlay() returned undef, even though they were all items that should have been touch/press to play. I was dumping $item when the sub failed with the debug below

sub touchToPlay {
        my $item = shift;

        if ( $item->{'type'} && $item->{'type'} =~ /^(?:audio)$/ ) {
$log->error('yes, item has type and type is audio');
                return $item->{'url'} || scalar @{ $item->{outline} || [] };
        }
        elsif ( $item->{'type'} && $item->{'type'} =~ /^(?:playlist)$/ && $item->{'parser'} ) {
$log->error('yes, item has type and type is playlist and item is parser');
                return $item->{'url'};
        }
        elsif ( $item->{'enclosure'} && ( $item->{'enclosure'}->{'type'} =~ /audio/ ) ) {
$log->error('yes, item has enclosure and enclosure type is audio');
                return $item->{'enclosure'}->{'url'};
        }
        else {
$log->error('no, it is not.');
Data::Dump::dump($item);
                return undef;
        }
}

Hmm, where's the design spec for what should be a touch to play item?

I can't point you to a document, but the gist of it is that if its a playable item at the lowest level of a tree structure (i.e., local track, rhapsody track, individual podcast, pandora station, etc.), it should be touch/press to play. 

I believe the design is also that it loads the rest of the tracks in the current list to the playlist. Obviously that part of the model doesn't hold up well for podcasts and pandora stations, where you don't want to load the rest of the menu to the playlist. I think we need to handle those cases with some kind of flag to say not to playall in the list.

Well that's the thing, most or all of these examples are not at the "lowest level" really.  For example a Rhapsody track has a huge menu underneath it.

But that was true of local tracks too...now that stuff comes up in the trackinfo menu...

want to strip CAT2 and defer this to Weldon? I really think were going to get hammered for inconsistent behavior though...

 == Auto-comment from SVN commit #7330 to the network repo by andy ==
 == https://svn.slimdevices.com/network?view=revision&revision=7330 ==

Bug 13462, Define on_select => play for Rhapsody

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

Bug 13462, flag on_select => play items as touch-to-play

 == Auto-comment from SVN commit #7331 to the network repo by andy ==
 == https://svn.slimdevices.com/network?view=revision&revision=7331 ==

Fixed bug 13462, define on_select => play for other services

issues:
- press to play on rhapsody/napster/mp3tunes/LMA track does not load the rest of the window's playlist (also, if track N > 1 is pressed, entire playlist should be added and then jump to track N)
- pandora genre stations plays immediately but does not push to NP screen (in contrast, pandora "your stations" items work perfectly)
- IMO, "play all" items should go away entirely

works:
- podcast items work as I think they should currently (immediate play of podcast item without adding other from list), but this might break if the first issue above is addressed?
- pandora "your stations"
- last.fm (although last.fm streams themselves are down)

added data point-- slacker works perfectly now

Doh, S::C::XMLBrowser doesn't support the playall attribute... will have to add this.

*** Bug 14105 has been marked as a duplicate of this bug. ***

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

Bug 13462, support playall attribute in S::C::XMLBrowser

I think this is mostly fixed now, back to Ben.

Everything works except the behavior when selecting a Pandora Genre station, which I think may be able to be pushed off as a P1. Will open a bug on that one.

Nice work Andy.

This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Created attachment 6417 [details]
don't make playall do addall too

Andy/Ben - as this is about _playing_ on touch, why should we change the add behaviour?

I'd suggest to revert the add behaviour, to fix some of the issues seen in bug 14848.

reopening

J�rg - how are you creating the "Add/Play all" item when browsing eg. a Rhapsody album? If I fix xmlbrowser to respect the playtrackalbum pref, then the "Add/Play all" would not handle all, but only one item.

You mean the one at the top of the iPeng album view?
That's take from the app/play command of the menu one level above.
So if you've got an album, as, say item 1 and the tracks are items 1.0 to 1.13 then iPeng would use the play command for item 1.

Note: iPeng is NOT creating it's own command based on the IDs but is using the one from the higher level menu, that command is saved to the new menus's context before descending.

If this doesn't work with your fix, could you give me an example on how the "albums" menu looks like, I remember I'm doing some aggregation here, I think what I use is the processed action (that is: the action and base action are already merged) and I do remember there was some case where I thought this might cause trouble but it didn't when trying, would have to check.

Created attachment 6420 [details]
apply playtrackalbum to menu items, not when a playlist command is sent

Andy/Ben - I think we've been handling the playtrackalbum in the wrong place. We shouldn't be sending playall/addall if the user has disable this preference. IMHO this patch should fix this behaviour.

Except for iPeng... J�rg - please see my comment in bug 14848: for whatever reason the play action from iPeng is sending a different item_id than add when trying to play/add a single item from eg. a Rhapsody album. It's always sending the album's item_id for the play action, while add is using the track's id.

This is probably OK, see my comment on the other bug.
Please check whether iPeng acts like SP if you enable "Play Single Tracks" in the iPeng settings.

> Please check whether iPeng acts like SP if you enable "Play Single  
> Tracks" in the iPeng settings.

Even with that option enabled iPeng is still requesting the album instead  
of the track

Michael- I'm willing to concede that playalbum pref checking was done in the wrong place, however:

XMLBrowser as you know is spaghetti code. It's nearly impossible to understand which parts of that module are going to be hit for a given menu. When I'm tasked with things that involve working on code in this module, my procedure is typically trial-and-error. 

I'm fairly certain I added the $playalbum code in XMLBrowser, and its placement is probably due to the fact that when I placed it there, the bug I was working on was no longer a bug.

My preference would be to also understand how pieces of XMLBrowser are being called, but in the absence of that I adopt trial-and-error.

A rewrite of XMLBrowser to make it more modular and easier (or even possible) to understand would be the right thing to do. Unfortunately, that's an unlikely possibility.

Actually this looks like a bug in iPeng. Seems to ignore that setting for SqueezePlay based albums.
Also found what the "limitation" was I mentioned earlier: support for "xxxAction = ..." (only in Albums, the other menus handle this correctly.
Will send you an updated iPEng later today.

Funny, didn't get any complaints about that one. You were looking for sensible defaults for TinySC: "Play Other Tracks in Album" seems to be one...

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

Fixed Bug: 14848
Fixed Bug: 13462
Description: don't send playall/addall unless user has playtrackalbum pref set. I wish us all good luck!

This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!