Webradio search woes

[macmpi]

It seems Web radio search/parsing changed sometimes back around last December (maybe linked to dirble vs shoutcast changes ?). Since then I've noticed some search issues, like duplicated results (with some failing), missing ones, etc...

Here is an example with easy steps to replicate:

• search webradio for "audiophile"
• result lists several radios, including Audiophile Jazz twice (first one failing to play)
• saved those two in Webradio Favorites
• cat the radio-favourites file

here it is:

volumio@volumio:~$ cat /data/favourites/radio-favourites
[{"service":"webradio","uri":"http://8.38.78.173:8276/\n","title":"Audiophile Jazz","icon":"fa-microphone"},{"service":"webradio","uri":"http://8.38.78.173:8210/stream","title":"Audiophile Jazz","icon":"fa-microphone"}]

note the suspect \n character in the first URL, which is not playing. Second one is fine.

[xipmix]

I can confirm the behaviour. The \n characters are coming from the URIs in the webradio database. I traced through the resolution of the 'Audiophile Jazz' station. In plugins/music_service/webradio/index.js, ControllerWebradio.prototype.listTop500Radios does roughly this:

• a query to http://api.shoutcast.com/legacy/Top500 returns an xml file
• with a <station> element that has the id=1459011
• constructs a uri pointing to that id on http://yp.shoutcast.com

Somehow later that uri is visited. Doing that manually returns this m3u file

#EXTM3U
#EXTINF:-1,(#1 - 282/1000) Audiophile Jazz
http://8.38.78.173:8210/stream

The last line has a \n at the end. Whatever is parsing that file to extract the uri isn't dealing with that. I haven't figured out where that happens.

[xipmix]

I found that I'd misunderstood some things here. When searching as above, ControllerWebradio.prototype.search queries the dirble service. It asks for json to be returned, which should cause no issues with parsing. However the json that comes back has the bogus uri embedded in the 'streams' array:

{ id: 9471,
  name: 'Audiophile Jazz',
  country: 'GR',
  image: {
    url: 'https://img.dirble.com/station/9471/audiophile.jpg',
    thumb: {
      url: 'https://img.dirble.com/station/9471/thumb_audiophile.jpg'
    }
  },
  slug: 'audiophile-jazz',
  website: 'http://stream.psychomed.gr',
  twitter: '',
  facebook: '',
  total_listeners: 0,
  categories:
   [
     { id: 12,
       title: 'Jazz',
       description: 'The classical music - Jazz.',
       slug: 'jazz',
       ancestry: null
     }
   ],
  streams:
    [
      {
        stream: 'http://8.38.78.173:8276/\n',
        bitrate: 320,
        content_type: 'audio/mpeg',
        status: 1,
        listeners: 0
      }
    ],
  created_at: '2014-03-04T15:25:32+01:00',
  updated_at: '2017-07-18T14:31:25+02:00'
}

But things may be more complicated still. The uri with the \n appears not to be a valid source.

$ wget -O - 'http://8.38.78.173:8276/'
--2018-02-28 14:14:11--  http://8.38.78.173:8276/
Connecting to 8.38.78.173:8276... failed: Connection refused.

note it is missing the /stream element of the uri, which the other (working) source has. Try it...

$ wget -O - 'http://8.38.78.173:8276/stream'
--2018-02-28 14:16:32--  http://8.38.78.173:8276/stream
Connecting to 8.38.78.173:8276... failed: Connection refused.

If I patch things to get rid of the \n and add the webradio to the queue, then try to play it, I get a red toastpopup showing a 'connection refused' error.

This is probably where we have to leave it; dirble isn't keeping on top of what uris are valid. At least if we clean up the stream uri users will get useful feedback when the stream turns out to be unplayable.

[macmpi]

Thanks a lot for diagnosing this! Seems previous directory had cleaner entries though...