[Fix]Skip trying to use TagLib to read tags from Shoutcasts

[DaveTBlake]

Stop trying to get TabLib to read metadata from Shoutcasts, but not excluding other internet streams.
An alternative to #11759

TabLib is not designed to cope with Shoutcasts, which while being an MPEG audio stream have a bespoke header and metadata format, and some streams cause TabLib to hang (or actually search indefinitely).

@fritsch @arnova @phate89 @wsnipex

I realise that a future refactoring wants to make TagLibVFSStream more controlled, and protect from unlimited reading. This is not an attempt at that, just a modest change that could be backported, that will avoid hangups caused by passing tagLib streams that we know do not contain tags it can read.

[wsnipex]

looks good to me

[fritsch]

If you wanted a timeout instead: fritsch@a847221

[DaveTBlake]

Thanks for the timeout approach @fritsch, a solution to the general problem of TagLibVFSStream running unlimited, but I would want do to lot more testing before applying an arbitrary time limit on all tag scanning. Here I'm looking for a fix to backport at this late stage in the cycle.

Now I believe that #11759 is a valid backport solution - even if it scans tag data from an internet stream Kodi does not display it, so no one will scream about lost features.

It is future work to add control of TagLibVFSStream, and if we want to implement the display of metadata from true mp3 internet streams that entails implementing accurate filtering that skips the Shoutcasts before calling TagLib.