new emms-streams.el

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

new emms-streams.el

Yoni Rabkin-2

It is after a release, and therefore it is time to break stuff:

As promised, emms-streams.el has been re-written. The new implementation
is drastically simplified and straightforward. One might even call it
"streamlined".

The rewrite removes the original Yet Another Specialized Mode, and
replaces it with a simple Emms playlist.

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.)

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.

The manual has been updated as well.

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

Reply | Threaded
Open this post in threaded view
|

Re: new emms-streams.el

Mike Kazantsev-2
On Wed, 06 Nov 2019 14:47:37 -0500
Yoni Rabkin <[hidden email]> 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).


> 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 :)


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: new emms-streams.el

Yoni Rabkin-2
Mike Kazantsev <[hidden email]> writes:

> On Wed, 06 Nov 2019 14:47:37 -0500
> Yoni Rabkin <[hidden email]> 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"

Reply | Threaded
Open this post in threaded view
|

Re: new emms-streams.el

Mike Kazantsev-2
On Sun, 01 Dec 2019 13:12:52 -0500
Yoni Rabkin <[hidden email]> wrote:

> Mike Kazantsev <[hidden email]> writes:
>
> > Guess for players without extensive APIs or stream metadata processing
> > it can be implemented via timer with http request.
>
> 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.

Note that it's not inevitable these days - emacs has fully async
sockets, where as far as I know (and was able to test with mpv),
neither connection nor reception should block, only cpu-bound
processing, which should be pretty liteweight in this case.

So I think it should be possible to do fully in elisp, and don't think
there are different standards for these tags - everything uses icy,
and did for more than a decade now, though haven't looked too closely,
and might be wrong.


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: new emms-streams.el

Yoni Rabkin-2
Mike Kazantsev <[hidden email]> writes:

> On Sun, 01 Dec 2019 13:12:52 -0500
> Yoni Rabkin <[hidden email]> wrote:
>
>> Mike Kazantsev <[hidden email]> writes:
>>
>> > Guess for players without extensive APIs or stream metadata processing
>> > it can be implemented via timer with http request.
>>
>> 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.
>
> Note that it's not inevitable these days - emacs has fully async
> sockets, where as far as I know (and was able to test with mpv),
> neither connection nor reception should block, only cpu-bound
> processing, which should be pretty liteweight in this case.
>
> So I think it should be possible to do fully in elisp, and don't think
> there are different standards for these tags - everything uses icy,
> and did for more than a decade now, though haven't looked too closely,
> and might be wrong.

Icy metadata spliced into the stream was, and still is, an ugly and
unstructured kludge. I would want to avoid it if possible, and fall back
to it if needed.

"Modern" icecast servers provide the information in a standard,
structured way: http://icecast.org/docs/icecast-2.4.1/server-stats.html

For instance,

$ curl -H "Icy-MetaData: 1" -v "http://audio-mp3.ibiblio.org:8000/status-json.xsl"

Reports an Icecast 2.4.4 server along with a host of structured data at
that address.

...while

$ curl -H "Icy-MetaData: 1" -v "http://stream0.wfmu.org/freeform-high.mp3" >/dev/null
 
Reports an Icecast 2.3.3 server and exposes nothing at "/status-json.xsl"

We need to re-write emms-stream-info.el in any case.

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