Re: new emms-streams.el

[Yoni Rabkin]

Mike Kazantsev <address@hidden> writes:

> On Wed, 06 Nov 2019 14:47:37 -0500
> Yoni Rabkin <address@hidden> wrote:
>
>> The next step will be to make the proper stream names display as the
>> track names, instead of simply the url of the playlist. After that,
>> re-visiting getting real-time info on the track being played on the
>> stream (a moving target, to be sure.)
>
> I think it's done already with mpv.
> I.e. when mpv gets icy-* tags update from remote stream (incl. when
> starting playback), it updates playlist metadata, replacing URL or old
> track title with the new one.
>
> Guess for players without extensive APIs or stream metadata processing
> it can be implemented via timer with http request.
>
> Did implement parsing of such metadata from stream in the past, it was
> surprisingly easy (python2):
> https://github.com/mk-fg/fgtk/blob/master/desktop/media/icy_record#L22-L43
>
> Where you basically split stream by icy-metaint value, grab first chunk
> or two, locate \xff in there and read StreamTitle= from there, closing
> connection afterwards (if all you need is title).

In fact, I implemented it for Emms many (too many) years ago completely
in elisp. It actually worked, and was a fun hack, but of course locked
up Emacs as it did so.

However, I think that the best result would be to use a user-specified
backend to get that information (not necessarily the same backend used
to play the audio stream.)

Of course for some streams the information simply isn't there, or
doesn't pertain to any particular track being played. For instance, a
live DJ playing vinyl.

Unfortunately, the code in emms-stream-info.el is a decade old and the
backends have changed their command-line interfaces and options in the
meantime. Fixing emms-stream-info.el would be a very welcomed patch,
with the understanding that in a few years it will likely break again as
those backend change.

>> As for the built-in list of stations, streams that didn't play with
>> mplayer, vlc, or mpv where removed, as well as one stream which
>> played a commercial every time I loaded it.
>
> Actually one reason I was looking into these tags earlier is to remove
> or mute these commercials, as surprisingly every single online radio
> station I tried seem to tag these properly as such.
>
> So if tag detection is responsive enough, e.g. comes from played
> stream directly (with vlc or mpv), it should be relatively easy to
> also have emms send mute/unmute signals to these via regexp matching
> commercial for that radio.
>
> Though maintaining such adblock-lists is maybe a bit more work than
> emms project is expected to do :)

I don't listen to any stations that run commercials. I listen to ones
which are community supported. So that feature wouldn't be essential for
me.

I agree that such an adblock-sync-list should be an independent project
that Emms could use, as opposed to something within Emms.

-- 
   "Cut your own wood and it will warm you twice"