Will check this out.

I'm still working on this but it's a complicated fix.

As an alternative to storing remote URLs in local playlist files, I would recommend you try the MyPicks plugin.  It lets you create local links to radio stations and uses the same code as Slim Devices Picks, which handles remote playlists without problems.

That's a good suggestion, thanks it works well.

FWIW, I tend to avoid 3rd-party plugins because inevitably I don't keep them updated enough and the functionality goes away and I don't notice until I need it.  For the same reason I don't use favorites because when I reinstall SlimServer the favorites go away.  Playlist folder has been the most reliable persistent source.  This situation is updated though because MyPicks does store the OPML file external to the db/etc.

I've fixed part of this bug in change 9657.  Playlists that contain a *single* remote URL will now work properly.  Playlists with multiple URLs are a more difficult problem to solve, and so I recommend not doing this, and using MyPicks.

Changing target to 7.0 to see if we can find a better solution post-6.5.

I'm OK with that fix.  One thing I realized after my last post was that I do still need the playlists (I think) in order to wake up to RadioParadise using the Alarm  At least with the fix I can input that one URL and have the station work.

Or is there a way to have the Alarm start up using either a ShoutCast or MyPicks selection?

Being able to put additional items into the alarm list is a good enhancement.  If there isn't already a bug filed for that, can you file one?  We can look at it after 6.5.

I tested the fix and it works well, thanks.  

I'm satisfied with the fix overall as at least it normalizes the behavior when compared to supplying a URL to the 'tune in' plugin.  As far as I'm concerned there is no need to leave this open 7.0 just for multiple URL's which I was showing more as a diagnostic.  

I understand that this might impact a large number of existing legacy users who have their playlists from before there was any sort of special internet radio browsing like shoutcast or OPML.  It was standard practice then to 'save as' a playlist link into our playlist folder, which usually does result in files with several URL's.

I'll look for an alarm enhancement and file a new enhancement if I don't find it.

Dan I'm cc'ing you on this bug since it looks like it could be the same as the one you pointed out to me the other day

Subject: Re:  Some Internet Radio URL's only work from Tune-in at
 first

I just created bug 4099 detailing the playlist bug I'm seeing

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

(In reply to comment #7)
> I tested the fix and it works well, thanks.  
> 
> I'm satisfied with the fix overall as at least it normalizes the behavior when
> compared to supplying a URL to the 'tune in' plugin.  As far as I'm concerned
> there is no need to leave this open 7.0 just for multiple URL's which I was
> showing more as a diagnostic.  
> 
> I understand that this might impact a large number of existing legacy users who
> have their playlists from before there was any sort of special internet radio
> browsing like shoutcast or OPML.  It was standard practice then to 'save as' a
> playlist link into our playlist folder, which usually does result in files with
> several URL's.
> 
> I'll look for an alarm enhancement and file a new enhancement if I don't find
> it.
> 

Does this mean that the old itunes playlists containing multiple radio stations will not ever be fixed?
It seems strange to regress the functionality when it is still the most obvious itunes-centric usage model.
(tune in a station, drag into your radio playlist).  Or is it still on for v7?  Hope so.

We will try to fix the multiple-radio-station-in-a-single-playlist bug for 7.0.

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

Chris: Why?  7.0 includes MyPicks and uses this for Favorites as the right way to store a bunch of favorite radio stations.  Keeping them in a playlist is the wrong way to do it.

(In reply to comment #14)
> Chris: Why?  7.0 includes MyPicks and uses this for Favorites as the right way
> to store a bunch of favorite radio stations.  Keeping them in a playlist is the
> wrong way to do it.
> 
It is not necessarily "wrong".  It is the natural and most convenient way of doing it on iTunes,
and many/most iTunes users already use and have such "playlists" of radio stations.

To me a 'playlist' is a list of tracks to be played in sequence.  Radio stations don't fit this model, so they are better stored another way, such as an OPML file that can be structured into a menu tree of radio stations, like Slim Picks.  This is how 7.0 handles things.  I don't know what we can do about playlists of radio stations from iTunes.

Perhaps something like a radio-station-playlist-to-opml import plugin, then

Punting.

To reinforce this requirement, a playlist with multiple radio stations is useful for (at least) two uses:

1. Use in an Alarm playlist; allows failover to another station if one is not available.
2. Convenient for skipping between the small set of station that one habitually listens to. Up/Down followed by Play is much simpler than navigating to Favourites or any other part of the menu structure.

Between them, these two use-cases account for at least 90% of the listening in our house. It is clear from other bug reports and forum posts that this is a common pattern.

All that said, it all works fine for me. I do not understand the cases where it is reported not to work.

Alan: I believe the problem comes from the fact that when a playlist is loaded (via Playlists menu), it is sent through the 'loadtracks' command code instead of the 'play' code.  The load code does not perform any scanning of a playlist and so they content-type may be wrong, etc.  i.e. it might try to play in mp3 mode for a wma stream, stuff like that.  I put in a hack in Commands.pm around line 1344 to redirect single-item radio playlists to play/add instead.

Fixed in 7.0.1 change 18498.  Multiple radio stations in a playlist should now work properly.  They will be loaded into the playlist and scanned by Scanner right before playback, so playlists will get expanded into the right streams, etc.

This will be even better in 7.1 after bug 7520 is fixed.

Verified to be fixed 7.0.1 - 19325

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html

Reduce number of active targets for SC