Calling RunVideoDataFetch often returns Nothing in the URL.

[Videstra]

I am using VB.Net and Windows 10. I recently updated to 1.1.1 of YoutubeDLSharp. I also updated yt-dlp.exe to the latest using
yt-dlp -U
When fetching data for the NASA live stream URL: [https://www.youtube.com/watch?v=xRPjKQtRXR8] and the current stable release of yt-dlp.exe (following yt-dlp.exe -U) the URL element of RunResult is often Nothing.
My code looks like this:

Dim YTUrl as String = "https://www.youtube.com/watch?v=xRPjKQtRXR8"
Dim Info As YoutubeDLSharp.RunResult(Of YoutubeDLSharp.Metadata.VideoData)
Info = Await ytdl.RunVideoDataFetch(YTUrl)
If IsNothing(Info.Data.Url) then
    'break here <<< - it breaks here a lot
End if 

Other elements within Info are just fine including description, islive, etc. But the actual url payload is unreliable. With older versions of yt-dlp.exe it seems much more reliable.
I've noticed that yt-dlp.exe returns JSON that includes both URL and manifest_url (which is shorter). I'm not sure what the difference is, but the shorter manifest_url appears to work just as well when fetching the NASA url above.
When I use the yt-dlp.exe natively using the command line

yt-dlp -J -vU https://www.youtube.com/watch?v=xRPjKQtRXR8>yt.txt

the return never leaves the JSON Url tag (or the manifext_url tag) empty - so I don't know what may be happening inside of YoutubeDL.Sharp so I thought I should post this to issues.

There's a new comment below from me - but I will copy it here as of this morning (9 Oct 2024)

---

The YouTubeDL.Sharp is continuing to return Nothing much of the time in the URL element of the JSON when calling RunVideoDataFetch. If I run yt-dl.exe manually at the same time like this:
yt-dlp -J https://www.youtube.com/watch?v=xRPjKQtRXR8>yt.txt
then the dump CLEARLY contains the URL (along with manifest_url) - so there is no good reason the output from RunVideoDataFetch is empty. I assume YouTubeDL.Sharp is looking at the same dump I am from the direct yt-dl.exe.
At this point I think I need to give up on YouTubeDL.Sharp - getting a URL is possibly the most basic function people want from this abstraction - but it's proving highly unreliable.
If I am doing something wrong (see my code sample in my original post) please let me know - but this seems like a pretty egregious bug.

[tleylan]

I used to use the reference the Url property up until (about) a month or two ago when it started to return no data. Now I use WebpageUrl and that works reliably. I suspect something changed on YouTube but it could have been a change to yt-dlp.

[Videstra]

I used to use the reference the Url property up until (about) a month or two ago when it started to return no data. Now I use WebpageUrl and that works reliably. I suspect something changed on YouTube but it could have been a change to yt-dlp.

That only returns the youtube link you passed in to get the URL of the originating video - WebpageUrl is not helpful.

[tleylan]

Ah, you're right of course. I got faked out (it seems) by only inspecting the url returned from YoutubeDLSharp. Thanks.

[Videstra]

The YouTubeDL.Sharp is continuing to return Nothing much of the time in the URL element of the JSON when calling RunVideoDataFetch. If I run yt-dl.exe manually at the same time like this:
yt-dlp -J https://www.youtube.com/watch?v=xRPjKQtRXR8>yt.txt
then the dump CLEARLY contains the URL (along with manifest_url) - so there is no good reason the output from RunVideoDataFetch is empty. I assume YouTubeDL.Sharp is looking at the same dump I am from the direct yt-dl.exe.
At this point I think I need to give up on YouTubeDL.Sharp - getting a URL is possibly the most basic function people want from this abstraction - but it's proving highly unreliable.
If I am doing something wrong (see my code sample in my original post) please let me know - but this seems like a pretty egregious bug.

[tleylan]

I noticed the url failure perhaps 2 months ago or so when YT videos stopped playing. I inspected the return value from my API and noticed that url was empty. While there was a value in WebpageUrl that one can actually be constructed and does not reflect the direct url to the video.

Interestingly this solved my problem but only because the app could process the url with the YT VideoId on it's own. This however placed the burden of resolving the url onto each client rather than having my service handle it once.

I hope this can be fixed soon. It seems like it should be simple enough. It used to work...