On Linux, use the system yt-dlp if available instead of embedded

[ilikenwf]

I use Arch and use the -git builds of yt-dlp. As such, it's more up to date with fixes for cloudflare streams and the like. I suggest that you determine if yt-dlp exists within the system python, and if it does, use that instead of the one embedded with the plugin.

[ilikenwf]

...that or pull in the current yt-dlp master and test to see if you can get cloudflarestream URIs to playback?

It works in yt-dlp itself but not sendtokodi.

https://watch.cloudflarestream.com/2463f6d3e06fa29710a337f5f5389fd8/iframe/?autoplay\=true\&letterboxColor\=transparent

https://customer-aw5py76sw8wyqzmh.cloudflarestream.com/2463f6d3e06fa29710a337f5f5389fd8/iframe

[nullket]

The plugin is updated once day with the upstream yt_dlp master branch. If there were changes a new plugin version is released and should be automatically updated in your Kodi instance. So we might be even faster than arch ;)?

https://github.com/firsttris/plugin.video.sendtokodi/commits?author=github-actions%5Bbot%5D

I have no experience in that but I assume that it is not possible to import a system wide installed python module in an embedded python environment (I simply don’t know!)?

[anohren]

@nullket I have a working prototype of using external yt-dlp, which enables use of yt-dlp even on Kodi versions constrained to Python 2. I wanted to ask whether you think it's a good idea to expose a setting for users to specify the path manually?

This is not done by importing Python modules (which wouldn't work on Python 2 anyway), but by parsing command output from a working executable. Nevertheless, it was implemented in about three lines of code, so it's very easy on the eyes.

Just wanted a second opinion before adding the boring bits (e.g. addon settings).

[iBenMoore]

@nullket I have a working prototype of using external yt-dlp, which enables use of yt-dlp even on Kodi versions constrained to Python 2. I wanted to ask whether you think it's a good idea to expose a setting for users to specify the path manually?

This is not done by importing Python modules (which wouldn't work on Python 2 anyway), but by parsing command output from a working executable. Nevertheless, it was implemented in about three lines of code, so it's very easy on the eyes.

Just wanted a second opinion before adding the boring bits (e.g. addon settings).

I'd be interested in seeing how this works @anohren . This addon won't work with Kodi Windows builds as yt-dlp bumped it's minver of python to 3.9 and Kodi doesn't plan on upping from 3.8 any time soon, so being able to point to an external yt-dlp executable would be useful.

[anohren]

Sure, if I can find it then I can post a simple search/replace snippet here in a comment. That'd be the quickest way to get you up and running again without waiting for this addon to incorporate this (questionable) change.

After that you only have to make sure the addon isn't accidentally updated, either from within Kodi (maybe just disable the repo?) or in the OS.

[anohren]

Found it.

Near the end of the addon's service.py replace everything between with and except:

with ydl:
    progress = xbmcgui.DialogProgressBG()
    progress.create("Resolving " + url)
    try:
        ytDlpPath = "/absolute/path/to/yt-dlp"
        if ytDlpPath != None:
            import subprocess
            jsonString = subprocess.check_output([ytDlpPath, "-J", "--format=" + ydl_opts['format'], "--flat-playlist", url])
            result = json.loads(jsonString)
        else:
            result = ydl.extract_info(url, download=False)
    except:

Note that I don't know if the command line options look identical for yt-dlp on Windows, so customize as needed.

Haven't used this lately but at least troubleshooting should be easier when you can call the same yt-dlp command externally and see what it spits out.

[iBenMoore]

Thanks @anohren , I was able to get this working with your example. A few more lines of code needed to be updated/commented out to make sure no attempts are made to access the yt-dlp included python code, and I threw in something to hide the yt-dlp.exe console window from popping up in front of Kodi as well. Seems to work pretty well now. Here's my version of the section that needs commenting/updating:

# Use the chosen resolver while forcing to use youtube_dl on legacy python 2 systems (dlp is python 3.6+)
#if xbmcplugin.getSetting(int(sys.argv[1]),"resolver") == "0" or sys.version_info[0] == 2:
#    from lib.youtube_dl import YoutubeDL
#else:
#    from lib.yt_dlp import YoutubeDL
    
# patch broken strptime (see above)
patch_strptime()

# extract_flat:  Do not resolve URLs, return the immediate result.
#                Pass in 'in_playlist' to only show this behavior for
#                playlist items.
ydl_opts = {
    'format': 'best',
    'extract_flat': 'in_playlist'
}

params = getParams()
url = str(params['url'])
ydl_opts.update(params['ydlOpts'])
if xbmcplugin.getSetting(int(sys.argv[1]),"usemanifest") == 'true':
    ydl_opts['format'] = 'bestvideo*+bestaudio/best'
#ydl = YoutubeDL(ydl_opts)
#ydl.add_default_info_extractors()

#with ydl:
    #progress = xbmcgui.DialogProgressBG()
    #progress.create("Resolving " + url)
    #try:
    #    result = ydl.extract_info(url, download=False)
progress = xbmcgui.DialogProgressBG()
progress.create("Resolving " + url)
try:
    ytDlpPath = "D:\your\path\to\yt-dlp.exe"
    if ytDlpPath != None:
        import subprocess
        jsonString = subprocess.check_output([ytDlpPath, "-J", "--format=" + ydl_opts['format'], "--flat-playlist", url], creationflags = subprocess.CREATE_NO_WINDOW)
        result = json.loads(jsonString)
    #else:
    #    result = ydl.extract_info(url, download=False)
except:

[brevilo]

The plugin is updated once day with the upstream yt_dlp master branch. If there were changes a new plugin version is released and should be automatically updated in your Kodi instance. So we might be even faster than arch ;)?

No one has ever reacted to this very true statement so far. Given that, what's the point of the added complexity to use the system version? Also, keep in mind that we are developing and testing against the included version which ensures compatibility. I'd also argue that running a subprocess is less efficient than just calling a library. IOW, I fail to see the advantages but do see a number of disadvantages. Thus I won't consider this an enhancement.

[anohren]

The plugin is updated once day with the upstream yt_dlp master branch. If there were changes a new plugin version is released and should be automatically updated in your Kodi instance. So we might be even faster than arch ;)?

No one has ever reacted to this very true statement so far. Given that, what's the point of the added complexity to use the system version?

Here's one advantage that's been mentioned:

enables use of yt-dlp even on Kodi versions constrained to Python 2

Whether there's an actual point to the added complexity would depend on how much you valued the benefits.

I can't see much value myself since I know first hand that even Kodi 21, and therefore bundled yt-dlp, can run on very low spec systems. Though someone who wants to watch something immediately will of course argue that a week is an eternity to wait for un-broken site support. That's understandable.

I'd also argue that running a subprocess is less efficient than just calling a library.

I don't see how a small efficiency difference matters for something called once.

That said, no one has moved on this issue nor has replied with clarification on concrete benefits. Do you propose to close it?

[brevilo]

Here's one advantage that's been mentioned:

enables use of yt-dlp even on Kodi versions constrained to Python 2

Thanks, I missed that one. That's arguably an advantage, yes, however @firsttris made it clear in other issues that he's doesn't want to put too much effort into supporting Kodi Leia and below (Python 2). Also, how big is that advantage in the first place, given that youtube-dl is being maintained again? IOW, how big is the issue of using the latest youtube-dl on Leia instead of yt-dlp? If there are only just a few edge cases on a legacy Kodi version used by a few then the cost/benefit ration simply becomes unfavorable.

Though someone who wants to watch something immediately will of course argue that a week is an eternity to wait for un-broken site support. That's understandable.

Why a "week"? It's a day at most. If that's still too slow then I'm sorry for that person 😉

I don't see how a small efficiency difference matters for something called once.

I don't disagree. I'm just listing disadvantages and spawning processes (incl. input/output redirecting, error handling/reporting) just sucks compared to using a library.

That said, no one has moved on this issue nor has replied with clarification on concrete benefits. Do you propose to close it?

I'm primarily voicing my opinion in an attempt to restart the discussion. First and foremost I'd like to make the OP aware about our daily updates. If that fulfills his needs, then fine. If not, I still don't see who is going to accept that chunk of code, add missing features (UI config support) and maintain it. I for one wouldn't.

Eventually, I argue we should either do it or close the issue, yes. There's no point in having it linger indefinitely if it doesn't really have a chance of ever being added, while its already small benefits diminish even further over time.

Cheers

[anohren]

Why a "week"? It's a day at most. If that's still too slow then I'm sorry for that person 😉

First and foremost I'd like to make the OP aware about our daily updates.

News to me too! I thought there was just a monotonous clock in the background ticking weekly 🙂

[brevilo]

Nope, each day at 17:00 (UTC) 🤓

Full disclosure: the legacy/leia branch is currently still updated manually. It's non-trivial to automate that as well due to conflict resolution. We might take a shot at that but it might just not be feasible. Another issue of supporting legacy systems.