Re: Adding a description text property for a track

[Yuchen Pei]

On Wed 2022-03-16 09:27:31 -0400, Yoni Rabkin wrote:

> Yuchen Pei <hi@ypei.me> writes:
>
>> On Tue, Mar 15 2022, Yoni Rabkin wrote:
>>
>>>
>>> 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.

What do you mean?  My change is not adding any hardcoded list of websites
in emms code.

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

That's what emms-info-ytdl-regexp for.  I don't mind making it
defcustom, add it to the manual etc. to raise awareness of the users
that they may want to install their own regexp.

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

Only when the track is added, matches emms-info-ytdl-regexp and does not
match emms-info-exclude-regexp.  Did I mention that by default the my
new info function is not enabled?

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

I'm referring to youtube-dl and yt-dlp as ytdl in the following.  The
generic extractor of ytdl is surprisingly powerful that it can handle
many video hosting websites, but the only way to know whether a site is
supported is to run the command on the site, so it is impossible to
determine by looking at the url whether ytdl supports it without
running.

Do you have any suggestions how to implement emms-info-streaming-video
that has a better return-for-investment than ytdl?  Return as in
sites coverage, and investment as in lines of code.  I am skeptical.

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

See my question above.

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

Again, the info function in my change is not about youtube, but ytdl.
And ytdl are youtube are different.  ytdl is a tool that supports many
websites including youtube.

What do you mean by proprietary services[1]?  Youtube as a video hosting
service respects your freedom as much as any personal blogs or
mediaglobin instance.  That is, if you restrict your interaction with
youtube to reading (downloading / streaming) without executing nonfree
javascript, it gives you the same freedom as watching libreplanet talks
on media.libreaplanet.org.  This is because with such activities the
website is simply a publication service, rather than SaaSS which does
inherently the user's computations, see [2].  And AFAICT by using ytdl
you achieve this way of interaction with youtube so there's no freedom
issues.

[1]
https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html
[2] https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

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


Best,
Yuchen

-- 
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
          <https://ypei.org/assets/ypei-pubkey.txt>