Re: Adding a description text property for a track

[Yoni Rabkin]

Yuchen Pei <hi@ypei.me> writes:

> On Tue, Mar 15 2022, Yoni Rabkin wrote:
>
>> Yuchen Pei <hi@ypei.me> writes:
>>
>>> On Sun, Feb 27 2022, Grant Shangreaux wrote:
>>>
>>>>> Mike Kazantsev <mk.fraggod@gmail.com> writes:
>>>>>
>>>>> And if a fixed one-liner description with some custom meaning is
>>>>> needed, I'd think it'd make sense to have a custom info function to
>>>>> interpret it somehow.
>>>>
>>>> Agreed, I think url track types could have their own info function.
>>>
>>> I added a info function for url track types using youtube-dl / yt-dlp:
>>>
>>> <https://git.savannah.gnu.org/cgit/emms.git/commit/?h=info-ytdl&id=13a862a99c740f960dd74205f106760314e6faab>
>>> <https://git.savannah.gnu.org/cgit/emms.git/commit/?h=info-ytdl&id=6b3b9edc5a4b6b936b468b9d3bfd472570532335>
>>>
>>> It supports all urls supported by youtube-dl / yt-dlp, including
>>> mediagoblin (e.g.[1]), peertube (e.g.[2]), and popular video hosting
>>> platforms that shall not be named.
>>>
>>> [1] https://media.libreplanet.org/u/libreplanet/m/fs-awards-ceremony/
>>> [2] https://framatube.org/w/ptK47LvsEGYAqMDs9ktziX
>>>
>>> Let me know what you think.
>>
>> We can't add this as it is at the moment since it tries, as far as I can
>> tell, to run any "https" entry through ytdl.
>
> It only does so when you add an url, and leaves all existing playlist
> tracks alone.

Adding urls is a typical operation these days. I have lists of urls I
import. So we'd need to identify those urls which would go to
emms-info-streaming-video. This is tricky, because we don't want a list
of Websites installed in Emms; that's tantamount to endorsing them, and
Websites come and go. Even if a site is doing something OK today,
tomorrow it can be purchased by a mega-corp and change tomorrow. Someone
would have to maintain that list.

This is why we are careful with the streaming stations built in to Emms,
and why we removed last.fm support and replaced it with librefm.

One way of getting around this is to ask the user to install their own
regular expressions for the sites they use as part of the setup process.


>> I have plenty of https
>> streams that are simply internet radio stations and other such streams
>> that have nothing to do with the software ytdl supports.
>
> Well, you have the option not to add it to the emms-info-functions list.
> In general there are plenty of features in emms that are not included in
> the default config, like the many other info functions, where the user
> has to enable explicitly.
>
> Also note that nothing will happen if youtube-dl / yt-dlp does not
> support the url and the info function runs nothing will happen to the
> track.

But then we are making calls to a command-line function on each affected
track. This is exactly what emms-info-native finally liberated us from.

Opening a process call for each track is a kludge and should be avoided
when possible. emms-info-streaming-video should only run on tracks that
it knows it should be able to handle.

Maybe the right answer is to avoid a separate backend and write a native
method for getting this information from video streams.


>>
>> The other issue is that it shouldn't be specific to youtube or ytdl.
>
> It uses youtube-dl / yt-dlp, which supports many media hosting
> platforms, so it is not specific to youtube.  It is called
> emms-info-ytdl because that is the common name for youtube-dl, and kind
> of a common subsequence of the name of the two programs.
>
>> If
>> anything, it should promote mediagoblin.
>
> Would you like me add a comment in the info function "it supports
> mediagoblin, peertube, among other things"?

>> Better still, it should be
>> named something like emms-info-streaming-video, 
>
> At this moment each info function (e.g. emms-info-exiftool) is named by
> the program they call, so having an emms-info-ytdl is in line with the
> current design.

It's not the same as the other info backends: exiftool, ogginfo,
metaflac, etc. are not names of proprietary online services; youtube
is. We will avoid naming proprietary services in Emms to the extent
possible. Sometimes this is unavoidable, but we should endeavor for it.

This all makes sense when you consider that Emms is part of the GNU
project and shares the goals of the GNU project.


>> and have the mechanism
>> inside to support multiple backends, one of which would be ytdl.
>
> At this moment I only have time for this one - feel free to improve it
> to support more urls.

I hope this is a better explanation of the criteria I mentioned above.


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