[xhamster] all videos show :"No video formats found"

[jasonstewardjn]

Checklist

• I'm reporting a broken site support
• I've verified that I'm running youtube-dl version 2020.07.28
• I've checked that all provided URLs are alive and playable in a browser
• I've checked that all URLs and arguments with special characters are properly quoted or escaped
• I've searched the bugtracker for similar issues including closed ones

Verbose log

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://xhamster.com/videos/mommy-helps-on-stepson-s-stubborn-erection-11722647']
[debug] Encodings: locale cp1252, fs mbcs, out cp437, pref cp1252
[debug] youtube-dl version 2020.07.28
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.18362
[debug] exe versions: none
[debug] Proxy map: {}
[XHamster] 11722647: Downloading webpage
ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpq2whuxta\build\youtube_dl\YoutubeDL.py", line 797, in extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpq2whuxta\build\youtube_dl\extractor\common.py", line 530, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpq2whuxta\build\youtube_dl\extractor\xhamster.py", line 242, in _real_extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpq2whuxta\build\youtube_dl\extractor\common.py", line 1350, in _sort_formats
youtube_dl.utils.ExtractorError: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Description

was working fine last week and after the update the xhamster extractor seems bugged

[thichpv]

I also encountered a similar problem as you with linkin

[TheRealDude2]

I suppose it is the same problem I have described here.

#26157

Unfortunately the extractor has 2 other patches pending in the last version, without which this change will not work yet.

[EnPaulius]

Same problem.

[msilletti]

Unfortunately the extractor has 2 other patches pending in the last version, without which this change will not work yet.

I see 3 open PRs:
https://github.com/ytdl-org/youtube-dl/pulls?q=is%3Apr+is%3Aopen+xhamster

I applied #25804 #25927 but am still getting the error. Are you saying yours works with these two applied?

youtube-dl --verbose https://xhamster.com/videos/j-30yo-doggy-style-house-wife-6439469
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', 'https://xhamster.com/videos/j-30yo-doggy-style-house-wife-6439469']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2020.07.28
[debug] Python version 3.8.5 (CPython) - Linux-5.7.12-1-ARCH-x86_64-with-glibc2.2.5
[debug] exe versions: ffmpeg 4.3.1, ffprobe 4.3.1
[debug] Proxy map: {}
[XHamster] 6439469: Downloading webpage
ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/youtube_dl/YoutubeDL.py", line 797, in extract_info
    ie_result = ie.extract(url)
  File "/usr/lib/python3.8/site-packages/youtube_dl/extractor/common.py", line 530, in extract
    ie_result = self._real_extract(url)
  File "/usr/lib/python3.8/site-packages/youtube_dl/extractor/xhamster.py", line 245, in _real_extract
    self._sort_formats(formats)
  File "/usr/lib/python3.8/site-packages/youtube_dl/extractor/common.py", line 1350, in _sort_formats
    raise ExtractorError('No video formats found')
youtube_dl.utils.ExtractorError: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

[TheRealDude2]

Yes, but these two fix other problems, with newer videos. But for the 'No video formats found' problem, i changed the line in the extractor, that i mentioned her #26157.

[jasonstewardjn]

Yes, but these two fix other problems, with newer videos. But for the 'No video formats found' problem, i changed the line in the extractor, that i mentioned her #26157.

thanks alot man that finally solved it

[msilletti]

Yes, but these two fix other problems, with newer videos. But for the 'No video formats found' problem, i changed the line in the extractor, that i mentioned her #26157.

Applying that worked, thank you

[bendover22]

The "ERROR: No video formats found" isn't closed for me. The same day (w/in hours) of jasonstewardjn saying the "ERROR: No video formats found;" problem was fixed, I was getting the same error on some files on the same site.
And continued to get that message on other files (same site).
Truthfully, I didn't try 100 or even dozens of files the last few days on XH or youtube or anywhere (never have nor will).

HOWEVER, for years, I've seen ytdl log show that error & several others, when the D/L fails within 5 seconds of starting the D/L.

Here's the interesting & very real issue.
The same vids that ytdl log gives errors that appear WON'T self resolve - often DO D/L. In MANY cases, without changing anything in the browser or ytdl, waiting 10, 30+ minutes or more, I retry the failed URL in ytdl & many files download just fine. I suspect these types of cases - if reported, are answered "works for me" & immediately closed.

I would guess the server is too busy (if later they D/L fine). In those cases, seems the log errors are bogus. No idea why it gives several different false errors instead of saying the server is busy or didn't respond / timed out.

It's happened so many times over yrs, it's not a fluke or just 1 or 2 special files.
Sometimes as a test, I intentionally don't change anything in my browser or ytdl.
I always update ytdl before I use it, so that's not it.
I won't clear cache, cookies or change anything else after a D/L failed - just to see. Quite often after waiting, the same files download fine.

[TheRealDude2]

The bug is not yet fixed in the released version and there is no pull request yet. Since I still have to deal with the git basics here, I don't know if I'll be able to fix it at all.

I'm pretty sure that the error "No video formats found" that you get from time to time has another reason. As you wrote, like an overload of the site. That is probably because the error is also displayed when the page is accessible, but not all information could be loaded, if I observe it correctly.

In the case described here it is unfortunately different. The error always occurs because the page structure has changed slightly and the extractor does not recognize the necessary information at all.

I think everyone who writes here that he could bypass the error has his own custom extractor running.

[bendover22]

Thanks for all the work maintaining ytdl. I'm a bit confused. Normally, bug reports aren't closed until it's fixed. It doesn't appear fixed.
Are we saying that users may have to live w/ "No video formats found" errors, unless they can write their own extractor?

Clarifying, aside from the error in this reported issue, numerous times I've seen probably most of ytdl's canned errors - at one point (basically, "this seems like a legitimate bug - report it," and later it D/L'd fine.
And other files may not D/L - at least in the short time I retry problem files.

So, I don't report them because there are so many false negatives. I don't know how to tell when the error is real. Seems like ytdl could report if the server is busy / didn't respond, or similar causes. That would help a lot.
If that's possible, users would have more confidence that a file may D/L later. And when they got other bug-type errors, they'd be more confident the errors were accurate (maybe file a report that doesn't waste maintainers' time).

A few times, I took the most promising looking URL for files, cleaned up back slashes & other minor problems, then pasted it in ytdl & they D/L'd fine. Too much trouble unless a really special file. The point is, if I was able to do pretty simple, manual steps, seems like ytdl should be able to, because I'm no guru at this.