check-formats hang with NON-writable working directory

[alervd]

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

• I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

• I'm reporting that yt-dlp is broken on a supported site
• I've verified that I'm running yt-dlp version 2023.07.06 (update instructions) or later (specify commit)
• I've checked that all provided URLs are playable in a browser with the same IP and same login details
• I've checked that all URLs and arguments with special characters are properly quoted or escaped
• I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
• I've read the guidelines for opening an issue
• I've read about sharing account credentials and I'm willing to share it if required

Region

No response

Provide a description that is worded well enough to be understood

In case the working directory is NOT writable (IMPORTANT!), e.g. C:\Program Files, yt-dlp stuck when trying to just parse particular video URL (using -J parameter). Not all URLs are affected. It seems the ones with DRM.
Yt-dlp never finishes. Python process is stuck consuming 50MB of memory and 50% of CPU core.

Issue is NOT reproducible in the previous 2023.06.22 release.

Provide verbose output that clearly demonstrates the problem

• Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
• If using API, add 'verbose': True to YoutubeDL params instead
• Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output

[debug] Command-line config: ['-vU', '-J', 'https://www.youtube.com/watch?v=kkUIdK9eaIk']
[debug] Encodings: locale cp1251, fs utf-8, pref cp1251, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version stable@2023.07.06 [b532a3481] (source)
[debug] Lazy loading extractors is disabled
[debug] Git HEAD: 876b70c8e
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19043-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.14.1, brotli-1.0.9, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.2
[debug] Proxy map: {}
[debug] Loaded 1863 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version: stable@2023.07.06, Current version: stable@2023.07.06
yt-dlp is up to date (stable@2023.07.06)
[youtube] Extracting URL: https://www.youtube.com/watch?v=kkUIdK9eaIk
[youtube] kkUIdK9eaIk: Downloading webpage
[youtube] kkUIdK9eaIk: Downloading ios player API JSON
[youtube] kkUIdK9eaIk: Downloading android player API JSON
[youtube] kkUIdK9eaIk: Downloading m3u8 information
[debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec:vp9.2, channels, acodec, lang, proto
[debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec:vp9.2(10), channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id
[debug] Default format spec: bestvideo*+bestaudio/best
[info] Testing format 616

[pukkandan]

Testing format currently requires writing a temp file. I don't know why it gets stuck instead of throwing an error though. As workaround, ask yt-dlp to write temp files to different directory -P temp:C:\temp

[alervd]

Testing format currently requires writing a temp file. I don't know why it gets stuck instead of throwing an error though. As workaround, ask yt-dlp to write temp files to different directory -P temp:C:\temp

Can it be Python bug? I was using Process Explorer to see the stack trace - it was stuck inside of Py_gitversion. Weird....

[coletdjnz]

This is indeed likely a Python bug - an old one that is.

It's an issue with tempfile where it hangs if the directory is not writeable on Windows.

We have used tempfile for file --check-formats downloads into for a while, introduced by 21cd8fa

python/cpython#66305
https://stackoverflow.com/questions/55109076/python-tempfile-temporaryfile-hangs-on-windows-when-no-write-privilege

[Kadigan]

Would it be possible to work around this by finding out what the temp path is (what tempfile.TemporaryFile wants to open), check write permissions on that path, and throw up a warning + disable the check if write permissions don't exist?

Alternatively, could a different approach be used to achieve the same functionality? Assuming nobody else has resolved the issue in their solution, that is.

It may be a Python bug, but if it's been up on SO for nearly 5 years - perhaps we shouldn't expect an upstream resolution any time soon.

[TheRealQuantam]

I'll just leave this here, in case anybody needs a working workaround for this till it gets fixed. python/cpython#66305 (comment)