Bug 15271 - Radiotime station which have aac with mp3 and/or wma stream fail on ip3k players on ReadyNAS
: Radiotime station which have aac with mp3 and/or wma stream fail on ip3k play...
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: 7.4.2
: All Other
: P1 normal (vote)
: 7.5.0
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-09 13:08 UTC by Bryan Alton
Modified: 2010-04-08 17:26 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bryan Alton 2009-12-09 13:08:47 UTC
When SBS only has native AAC and WMA (i.e. no transcoding support) which is normal for ReadyNAS - then if you try to play a RadioTime station which has AAC streams as well as other formats.  Radiotime can return an ASX playlist with AAC, MP3  and WMA stream URL - the stream will not play - SBS produces messages about unable to 

To show the problem on a non ReadyNAS SBS (this may also be applicable to some Linux) - must use a player which canot play AAC native.
1. Disable all transcoding for AAC and WMA formats.
2. Play using Tune-in http://opml.radiotime.com/Tune.ashx?id=s17525&formats=aac,mp3,wma,wmpro,wmvoice,wmvideo,ogg&partnerId=16

This URL should play as it has AAC, WMA and MP3 streams and IP3K player can play native WMA or MP3 - however without any transcoding enabled - the "unable to play file type for " message appears. 

I think this is a variant of the bug #13955 and also some of the RadioTime entries in bug #12112 are the result of this bug.
Comment 1 James Richardson 2009-12-09 15:21:24 UTC
Steven: can you verify this one please
Comment 2 Bryan Alton 2009-12-10 00:47:08 UTC
This is the forum thread resulted in the bug report
http://forums.slimdevices.com/showthread.php?t=71720

You can see how the AAC part breaks playing by testing different versions of the same URL but transcoding for AAC and WMA must be disabled. The variants drop the request for AAC and MP3 formats in turn.
http://opml.radiotime.com/Tune.ashx?id=s17525&formats=aac,mp3,wma,wmpro,wmvoice,wmvideo,ogg&partnerId=16
http://opml.radiotime.com/Tune.ashx?id=s17525&formats=mp3,wma,wmpro,wmvoice,wmvideo,ogg&partnerId=16
http://opml.radiotime.com/Tune.ashx?id=s17525&formats=wma,wmpro,wmvoice,wmvideo,ogg&partnerId=16

The URL is generated in Slim/Plugin/InternetRadio/Plugin.pm in the routine 
and AAC was added in rev 28199 so a quick fix is remove "aac," but this will prevent AAC only streams playing. I think the real problem is the handling of non WMA streams in ASX playlists.

I haven't tested but I think this bug should also show up if an IP3k player is using Touch as its local server.
Comment 3 Michael Herger 2009-12-22 05:53:00 UTC
Ok, we need to filter out formats which can't be played when querying radiotime.
Comment 4 SVN Bot 2009-12-22 07:59:42 UTC
 == Auto-comment from SVN commit #29671 to the slim repo by michael ==
 == https://svn.slimdevices.com/slim?view=revision&revision=29671 ==

Fixed Bug: 15271
Description: only fetch stations from radiotime which are in a supported format; remove hard coded AlienBBC condition
Comment 5 Bryan Alton 2009-12-22 16:13:09 UTC
This is a workaround to fix one symptom rather than a full fix to the real problem which is SBS cannot play non WMA URLs in an ASX playlist which is bug #13955.  Fix bug #12955 and it will clear some of the bug #12112 entries
Comment 6 Bryan Alton 2009-12-22 16:14:18 UTC
Typo in last line of previous comment I did not mean bug 12955 but bug #13955
Comment 7 Michael Herger 2009-12-23 00:22:03 UTC
I don't see this as a workaround. As we can tell RadioTime what it should return, we should use this correctly. In this case it shouldn't return any mixed playlists any more, but only with formats as supported by the player.

Sure, we can try to fix this later in the process, but I'd rather eliminate the problem at the source.
Comment 8 Bryan Alton 2009-12-23 03:16:41 UTC
I understand the issue in respect of RadioTime and I framed the bug report in that context so that it could be closed with a small code change.

However, hypothetically if another station has an ASX playlist with an AAC and WMA or MP3 URL - then the same problem in this report will arise until bug 13955 is fixed. Thankfully stations like SomaFM or Sky do not do this but I'm trying to highlight that if the underlying problem was fixed a number of bug reports would be closed.
Comment 9 kyl416 2010-01-20 11:41:31 UTC
(In reply to comment #7)
> I don't see this as a workaround. As we can tell RadioTime what it should
> return, we should use this correctly. In this case it shouldn't return any
> mixed playlists any more, but only with formats as supported by the player.
> 
> Sure, we can try to fix this later in the process, but I'd rather eliminate the
> problem at the source.

This is correct. If a user's player only supports mp3 this is what their player should use when fetching the streams:
http://opml.radiotime.com/Tune.ashx?id=s17525&formats=mp3&partnerId=16

The playlist we send are always in a generic m3u format and the streams contained in them is dynamic based on what the "&formats=xxx" call is.
Comment 10 kyl416 2010-01-20 12:21:35 UTC
(In reply to comment #8)
> I understand the issue in respect of RadioTime and I framed the bug report in
> that context so that it could be closed with a small code change.
> 
> However, hypothetically if another station has an ASX playlist with an AAC and
> WMA or MP3 URL - then the same problem in this report will arise until bug
> 13955 is fixed. Thankfully stations like SomaFM or Sky do not do this but I'm
> trying to highlight that if the underlying problem was fixed a number of bug
> reports would be closed.

If a station provides an asx playlist that contains a mp3 stream we (RadioTime) leave it as is since if a player supports windows media, the player will support mp3. Since most stations design their webplayers with the general idea that users will be accessing them with a computer and not a device, we urge our partners to make sure their windows media capable devices can at least handle asx URLs like Windows Media Player (i.e. on the fly detection if it's windows media or mp3, proper handling of streams that embed pledge info/ads/jingles before the actual audio, and not just simply skipping to the last entry in the playlist since many stations reserve the last entry for a pre-recorded "stream is currently down" message). We also add the root mp3 stream as a separate mp3 entry for compatibily with devices that don't support windows media. We keep the asx up since that's the URL the station has on their site, and generally it will be a stable URL, as opposed to the root mp3 stream in it where it can be a dynamic IP address server. In cases where stations provide multiple playlist formats (.asx, .m3u, .pls, .ram and .qtl) that all contain the same mp3 stream, we only add the .m3u

Websites should NEVER put a basic http:// aac url in an asx playlist. However those that use Orban's AAC plugin can put AAC in an icyx:// format in the asx playlist. Since this icyx:// url is only supported by Windows Media Player if you have the Orban plugin installed, we disable the asx URL and add the AAC stream in the proper http:// format, so users won't see the AAC stream unless their device passes "formats=aac" as part of the call to RadioTime. If any of the developers or tech savy users encounter an active .asx url that has one of these icyx: urls, feel free to go to that station's page on RadioTime.com and tell us about it via the feedback link so we can fix it.
Comment 11 Chris Owens 2010-04-08 17:26:12 UTC
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!