No usable temporary directory found

[abdullahamin665]

Checklist

• I'm reporting a bug unrelated to a specific site.
• I've verified that I'm running the latest version of yt-dlp.
• I've verified that I'm running the latest stable version of Seal or any later preview versions.
• I've read the Contributing guidelines and Code Of Conduct.
• I've checked that the site i'm trying to download from is in the Supported Sites list from yt-dlp
• I understand that the issue will be (ignored/closed) if I intentionally remove or skip any mandatory field.

Describe the bug

No response

To Reproduce

No response

Error reports

App version: 1.10.0 (11000)
Device information: Android 12 (API 31)
Supported ABIs: [arm64-v8a, armeabi-v7a, armeabi]
Yt-dlp version: 2023.10.13

URL: https://youtu.be/Cgx46Wnrusc?si=r4tGMXkLSuOut3KY
ERROR: Unable to download video subtitles for 'en-ehkg1hFWq8A': [Errno 2] No usable temporary directory found in ['/data/data/com.termux/files/usr/tmp', '/']

Screenshots & Screen Records

No response

Additional context

No response

[FoxTrotte]

Same issue here, using latest stable version of Seal with latest version of yt-dlp, trying to download this video: https://youtu.be/yDp3cB5fHXQ?si=K9Qgv43k6Xk7Amgc

[GfEW]

Exact same error message here, see below. I remember seeing it once before, about 6 weeks ago. As it occurs so infrequently, I find it hard to track it down, and so far, cannot attribute it to any particular triggers or circumstances. The only additional context I'm currently able to provide is the following log entries:

12-20 06:57:07.655 W/System.err( 3927): at androidx.fragment.app.Fragment$4.run(SourceFile:14)
12-20 06:57:07.655 W/System.err( 3927): at kotlinx.coroutines.DispatchedTask.run(Unknown Source:96)
12-20 06:57:07.655 W/System.err( 3927): at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(Unknown Source:8)
12-20 06:57:07.655 W/System.err( 3927): at com.junkfood.seal.ui.page.download.DownloadViewModel$startDownloadVideo$2.invokeSuspend(SourceFile:177)
12-20 06:57:07.655 W/System.err( 3927): at com.yausername.youtubedl_android.YoutubeDL.execute$default(Unknown Source:11)
12-20 06:57:07.655 W/System.err( 3927): at com.yausername.youtubedl_android.YoutubeDL.execute(SourceFile:3)
12-20 06:57:07.655 W/System.err( 3927): com.yausername.youtubedl_android.YoutubeDLException: ERROR: [Errno 2] No usable temporary directory found in ['/data/data/com.termux/files/usr/tmp', '/']
12-20 06:56:47.781 W/System.err( 4404): at android.os.HandlerThread.run(HandlerThread.java:65)

Please note that most of these entries share the same timestamp, hence may have actually occurred in any order. I wouldn't rely on the order they are displayed.

[unforgettablerose]

Just now experienced this problem after having updated the app to v1.11.2

[JunkFood02]

We couldn't find a stable way to reproduce this issue yet, but I guess this is because the filesystem of the device is temporarily mounted as read-only, at least in our python runtime environment, which should be considered as a system bug. A workaround should work is to reboot your device. We'll continue to investigate this further

[unforgettablerose]

I don't know what happened, but it seems to have resolved on its own. But it was an issue during the time of the update, like in the immediate time after the update.

[GfEW]

Of the roughly six youtube videos I've encountered this error with last month, exactly one "self-healed" when I rebooted the phone. The other ones still threw the error - go figure.

However, I've finally found something that might hint at the underlying problem:
The error correlates to the available formats the video is provided in.

In my today's test series of 8 different download attempts,

• each of the 4 videos that were available in webm format (along with mp4) didn't throw the error.
• each of the 4 videos that were only avialable as mp4, did throw the error.

If in Seal Settings --> Format"" --> "Preferred video format", I switched from "Quality" (my default) to "Legacy", the video download succeeded regardless of webm being available or not. In other words, the error only occured to me while Seal's option"Preferred video format" was set to "Quality"!

I've also tried to test it the other way around (i. e. "Legacy" setting with webm-only videos), but couldn't find any webm video that didn't also offer a few mp4 options.

Given this new insight, the curious "self-healing" mentioned above could simply result from the video being transcoded and made available as webm that very moment.

[JunkFood02]

@GfEW Could you switch Format selection to Custom, and try to reproduce this error for a specific format code? It would be better if there is a video link related to this issue

[GfEW]

Re video link
Sorry about that miss, I'm totally aware of it. I just need to find a vid neutral/meaningless enough to be shared here.

Re Custom
I'm not sure what exactly you're referring to. The slider Format selection in Seal settings --> Format --> section "Advanced" is enabled already, and has been so all the time.(*) For each video link, after

1. pasting it (into the text entry box) and confirming it with the down-arrow button, then
2. pressing the "Download" button (in the preconfiguration popup) to fetch the list of available formats, and
3. waiting for that fetching process to finish (already in the third view where also a thumbnail of the video is loaded/displayed),
   I check and possibly adjust the suggested audio/video format code selection I'm presented with.

This error, however, occurs at the start of step 3, preventing Seal from fetching that list of available audio/video formats, and me from checking and possibly adjusting any selection.

Does this answer your question?

Should you rather want me to specify a format via custom command, please provide me with the particular custom command line that I may then enter. I'm unfortunately not familiar enough with the bells and whistles of yt-dlp, would need far more time and practice than I have ATM.

(*) Off topic:
I think that collaborative bug hunting and finding reproducible triggers could be easier if Seal allowed to "view the actual yt-dlp command, including all employed options and arguments, that is used internally by Seal". Being able to copy&paste it here would be really handy.

[JunkFood02]

Quality or Legacy in format preference only affects the order of the formats. The Suggested format in the format selection page is just the first format in the list, so if you suspected specific format causes this issue, just remember the format code of it and verify if it can be reproduced

[GfEW]

Sorry, while editing my previous comment to make it clearer, I didn't notice yours. Please see above.

[JunkFood02]

This error, however, occurs at the start of step 3, preventing Seal from fetching that list of available audio/video formats, and me from checking and possibly adjusting any selection.

The app runs yt-dlp commands for twice for a download:

• Fetch the video information and all of its available formats
• Actually download the selected format of the video

Based on your description, the No usable temporary directory error occurred in the first request which does not download any files, thus it's unrelated to your "Format preference", whatever it's Legacy or Quality

[GfEW]

I can see your point. I don't mean to claim any reasoning but mainly describe my observations regarding correlations of the No usable temporary directory found error that I hadn't been aware of before.

It turns out the error does not necessarily relate to the set of available formats as such, since all failing videos in my yesterday's sample are also from a single, very small yt video channel that happens to contain mp4-only videos, only. I've been able to "extend" the problem by six additional videos from that specific channel, all of which also fail.

Unfortunately, such mp4-only channels are hard to find by their nature - I guess they are numerous, but each of them so unpopular that google doesn't even want to spend cpu cycles on transcoding them.

I can only speculate what's the crux of the matter with this example of a problematic channel. Some ideas:

• Could there be a glitch with that channel in Seal's internal database? I refrain from deleting Seal's data and starting over, because I don't know of a way to export and later import Seal's settings (and history), and manually restoring them would be a nightmare (or impossible, respectively).
• Could it be due to a caching issue? Emptying Seal's own cache via Android Settings --> App Management doesn't help, though.
• Somewhat unreal idea, but is there any chance the problem could be related to yt content moderation or even demonetization?

[JunkFood02]

@GfEW

I'll just download the video on my own every time when I notice a user posting report of this issue with related video URL attached. But none of them could be reproduced on my device.

Reinstalling won't work for this issue, either, according to a few feedbacks

[GfEW]

After further systematic testing, the correlation looks like more than accidental statistics. For the first time, it allows me to reproduce occurrence/non-occurrence of the error, although so far, only in a tiny confined space of two binary parameters:

1. video URL (can be "OK" or "problematic")
2. preferred video format (can be "Quality" or "Legacy").

So far, "problematic" videos can be identified by the following two properties:

• they are from that specific channel, and
• their format selection view (when fetched with format pref "Legacy") lists only mp4 formats.

(Lacking video examples that have only one of these properties, it is still unclear which property causes the problem.)

Even with video links that I've never tested before:

If

1. the video is
   "problematic" (see above), and
2. Seal's preferred video format is set to "Quality", and
3. I attempt to fetch the list of available formats,

then
the No usable temporary directory found error occurs.

As of now, the following little results table holds, without a single exception in 26 tests:

| vid OK | vid probl
quality | S | E
legacy | S | S
where
S success
E error.

In order to allow you to also reproduce these findings, I'm still trying to find other affected videos or channels, hope I can provide you with working, sharable examples soon.
EDIT: See below

[GfEW]

@JunkFood02

I'll just download the video on my own every time when I notice a user posting report

Maybe we are interacting with some sort of transcoding automatism on the side of youtube here? Like:

1. Many yt users upload their videos as mp4, still using legacy codecs.
2. As long as a video has very few views (being very new or unpopular), transcoding is only in the pipeline, or youtube doesn't bother transcoding at all.
3. But once the video gains popularity, transcoding is done.
4. As soon as the list of available formats of that video also includes webm, the error vanishes.

(Both video URLs posted in this issue by @abdullahamin665 and @FoxTrotte were very new at that time.)

EDIT: This hypothesis still holds after extensive testing, and has brought about two procedures that reproduce the error, see core points and example videos below.

[GfEW]

2 h of binge testing various arcane youtube channels/videos has, instead of the hoped-for triggers, brought up one video that is neither transcoded nor "problematic". How confusing!

Also, some of my yesterday's failing examples have stopped failing. (Most videos in the same "problematic" channel still do fail.)

These news invalidate my proposal "problematic" videos could be identified by the following two properties:

• they are from that specific channel, and
• their format selection view (when fetched with format pref "Legacy") lists only mp4 formats.

Core Points

Here's my understanding gathered so far, including a few side notes:

1. The error occurs in the "fetching format list" stage, only with certain youtube videos and only if preferred video format is set to "Quality".
2. For any affected video, switching format pref to "Legacy" circumvents the error. (Switching back to "Quality" makes the error occur again.)
3. For any affected video, switching to "Audio" also circumvents the error. (Switching back to "Video" makes the error occur again.)
4. Video tracks of all affected videos are solely available as mp4, whilst most (but not all) non-affected videos also offer webm.
5. Affected videos tend to have low view counts (being very new, or unpopular).
6. Some of the errors resolve on their own, mostly in a matter of days (hours?). The video format list thereby becomes fetchable, and the formerly "problematic" video downloadable. No example of a change in the opposite direction (formerly "OK", now "problematic") is known.
7. Restarting the device, emptying Seal's app cache, deleting its data or reinstalling Seal - all these measures don't seem to help. (But mind point 6. above.)
8. Videos that are "problematic" to one instance of Seal are also "problematic" to another instance of Seal running at the same time in the same network on a separate device. (Based on random samples.)
9. EDIT: Aside from "Quality mode", the error can also be reproduced with certain "Format sorting" strings - see below.

[dkambersky]

Can at least confirm @GfEW's hypothesis about switching formats. Had a video that would consistently fail with the temporary directory error, not even getting to the'select formats' stage. Switching to 'Legacy' quality preference made it download as expected.

[JunkFood02]

Can at least confirm @GfEW's hypothesis about switching formats. Had a video that would consistently fail with the temporary directory error, not even getting to the'select formats' stage. Switching to 'Legacy' quality preference made it download as expected.

Thanks for the report! that's quite weird because this option should have nothing to do with any "directory".

If anyone is interested in the issue and has a link which can reproduce this. You can help test this bug by:

1. Enable "Format sorting" and tap Import
2. Try making some tweaks to the sorting fields to see which one might be the cause

[GfEW]

I'm sorry I haven't been able to give a particular failing video link before now. Due to the either obscure or transitory nature of affected videos, searching for sharable examples got too time consuming, I had to stop it for a while.

However, as I keep testing occasional stray video links that could (momentarily) be unpopular enough to trigger the error, I've indeed found one today:
https://www.youtube.com/watch?v=PoesvM362bk
Beware, it is spam. Also, it might stop failing - or even existing - anytime.
(EDIT: it's gone.)

@JunkFood02
According your guidance, I've also examined "Format sorting" with that video link a bit, and found these differences:

• vcodec:vp9.2,res:360,acodec:opus,abr~64 fails (this is the original "import" line)
• vcodec:av01,res:360,acodec:opus,abr~64 fails
• vcodec:av1,res:360,acodec:opus,abr~64 fails
• vcodec,res:360,acodec:opus,abr~64 fails
• res:360,acodec:opus,abr~64 works
• vcodec:,res:360,acodec:opus,abr~64 works
• vcodec:avc,res:360,acodec:opus,abr~64 works
• vcodec:avc1,res:360,acodec:opus,abr~64 works
• vcodec:foobar,res:360,acodec:opus,abr~64 interestingly also works.

Whilst switching to "Audio" (cf. no. 3 in above "core points") still does fetch the list of formats (even with vcodec:vp9.2 etc.), "Legacy" (cf no. 2) doesn't help anymore once "Format sorting" is enabled, but fails just like "Quality" does. (Question: Does the non-greyed-out state of "Preferred video format" matter at all while it is greyed due to "Format sorting", or is it instead overruled by the latter?)

I'm not sure how vcodec:vp9.2 gets into the "imported" sorting string in the first place, but anyway, it appears to provide a second way to reproducing the same No usable temporary directory found error with this "problematic" video (which currently lacks any webm video track in its available formats list) that can also be triggered without "Format sorting" by attempting to fetch its available formats list in "Quality" mode.

[GfEW]

@JunkFood02

I'll just download the video on my own every time when I notice a user posting report

Maybe we are interacting with some sort of transcoding automatism on the side of youtube here? Like:

1. Many yt users upload their videos as mp4, still using legacy codecs.
2. As long as a video has very few views (being very new or unpopular), transcoding is only in the pipeline, or youtube doesn't bother transcoding at all.
3. But once the video gains popularity, transcoding is done.
4. As soon as the list of available formats of that video also includes webm, the error vanishes.

I think we can treat this explanation as a given, by now. Therefore, there's little use in providing you with ever new video link examples, most of them just stop failing too soon. (Usually, that's within less than a day, and the exceptions to this rule tend to be extremely "arcane" (like double digit view counts) - it wouldn't feel right for me to expose them here.)

However, I have finally found a "more robustly public" yt channel where you have a high chance of finding "problematic" videos by yourself anytime:
https://www.youtube.com/channel/UCmuTmpLY35O3csvhyA6vrkg

Just try the five most recent videos posted there, the newer the better. Should (rarely) none of them trigger the error, give it some hours for new videos to appear, then try again. At this very moment, three out of the newest five do trigger the error.

Hope that helps. :-)

[GfEW]

@JunkFood02
As this is still marked as "help wanted", is there any other than actual code level work left to be done that I could contribute for this persisting issue to progress?

(Not meant to urge, just asking for clearity.)

[rudelf]

Hello everyone!!! I decided to join the discussion and share my findings with you.
I should note that almost all users who had to come to this issue for help, this error is caused by an attempt to download content from YouTube.
I can assume that this error occurs when the link to the video looks like: https://youtu.be/AAAAAAAAAAA?si=BBBBBBBBBBBBBBBBB
where:
AAAAAAAAAAA - unique 11-characters ID of the video on YouTube platform;
?si=BBBBBBBBBBBBBBBBBBBBBBBBBBB - suffix added when copying link from YouTube app by "Share" button action
Let me explain why this aspect drew my attention to itself.
The thing is that PC-version of yt-dlp console utility behaves unpredictably when entering a link with suffix '?si=...'.
Even when attempting to fetch formats with such a link with this suffix appended, the utility immediately proceeds to the video downloading stage.
Thus, this behavior of Seal app (which also uses yt-dlp utility as its basis) requiring access to the temporary directory at the fetching process, becomes clear.
I suggest users to manually get rid of the suffix '?si=...' in the link to problematic video links for the time being.
And after reports on successful downloads using the method I suggested, it will be possible to find solutions for automatic shortening of links to the correct format.

[GfEW]

@rudelf
I'd really like this long standing issue to progress, but I cannot reproduce your findings on my devices.

Since I've developed a habit of stripping all unnecessary parts like the si=... (supposedly, session ID) from the URL long ago, all error reports provided to this issue by me were based on just the core video URL, e. g. https://www.youtube.com/watch?v=PoesvM362bk or, equivalently, https://youtu.be/PoesvM362bk .

You could try the same by copying the video link from wherever you find it, then quickly editing it e. g. in simple clipboard editor, then 'sharing' it with Seal.

So far, on my side, the only key difference that reliably allows to either trigger the error or to successfully fetch the list of available formats at will, is the one described here.
(Alas, the video channel mentioned there has stopped being a worthwhile source of problematic videos.)

[JunkFood02]

Thanks for all the efforts on this!

Though it's difficult to reproduce this issue and get a detailed stacktrace, we're working on updating the built-in python environment for Seal recently, which could possibly solve this issue.

[GfEW]

@JunkFood02 Re stacktrace:
Would it help if I provided more log excerpts like the one in #1161 (comment) ?

If I knew how to inspect the GUI-configured yt-dlp command line verbatim (for a generic suggestion, see #1337), I'd have started experimenting with it in termux months ago - including more vebose modes - and likely be able to provide a much more detailled picture of the error by now.

(I still don't manage to familiarize myself with the vast range of yt-dlp options to a degree that would allow me to reverse-engineer Seal's internally used yt-dlp commands from the GUI options alone.
In general, I'm comfortable at CLI, though. It's really the GUI/CLI barrier in Seal that prevents me from examining this issue via custom commands or on the command line.)

[JunkFood02]

Would it help if I provided more log excerpts like the one in #1161 (comment)?

I'm afraid not. The error itself does not have any relevant information reflected in the logs, any of them, so that we can only guess its cause based on some clumsy A/B testing. And these attempts are even not reproducible, like I've never met this error on my own when download from YouTube

[GfEW]

The error itself does not have any relevant information reflected in the logs, any of them

Do you actually think more useful information could be retrieved on the commandline with some of yt-dlp's verbosity options, or am I beating a dead horse there?

so that we can only guess its cause based on some clumsy A/B testing

EDIT: My original answer here was due to a misunderstanding. By reading more carefully, I realize you don't mean to refer to A/B testing on the side of youtube here, but instead, to say A/B testing on our side is all we're left with to guess the cause of the error. I'm afraid that's mostly true, although I hope there can be a setup that allows you to drill down to the root cause once you're able to reproduce the error by yourselves.

[JunkFood02]

Do you actually think more useful information could be retrieved on the commandline with some of yt-dlp's verbosity options

We've already enabled this with Detailed output on, and so far I think we haven't got any other information than the error No usable temporary directory found itself.

or am I beating a dead horse there?

Absolutely not! We've been tracking this error for months, receiving lots of error reporting regarding different videos and download configurations. The lesson we learnt is actually that, the issue is too complicated for us to get a minimal reproducible sample, find the root cause, and solve it by patching it in our code or yt-dlp.

Moreover, it's probably a combination from a corrupted python environment(the termux part) and a specific set of download configuations and/or a specific video. That said, this could more likely to be an indication of an bad build than a bug that needs to be fixed. What needs to be fixed is the build itself.

[GfEW]

Thanks a lot for this elaboration, @JunkFood02 . It provides several formerly missing pieces that allow to understand the problem with this issue, and your handling thereof, much better now.

If I find the time, I'll try to reproduce the error in an android emulator. That way, it should become reproducible for you guys, too.

[jetlagg3d]

Having the same error here with most links, like https://youtu.be/U_LlX4t0A9I.

[GfEW]

@jetlagg3d

Having the same error here with most links, like https://youtu.be/U_LlX4t0A9I.

At the time of your post, that video link was younger than 12 hours, which fits well into the pattern described here.
By now, it has gathered 34 million views. Based on my findings from extensive tests (see above), such popular videos are expected to "self heal" in less than a day. Indeed, I'm able to download it already, even with "Quality" format preference (which otherwise would trigger the error).

Have you tried to download it more recently again?

[jetlagg3d]

Have you tried to download it more recently again?
Actually, it works now. A few minutes after I posted this I kept retrying and it eventually worked. I didn't know it takes a while for new videos, thanks!

[Jan9103]

We've been tracking this error for months, receiving lots of error reporting regarding different videos and download configurations.

i did some testing to generate some data

App version: 1.12.1-(F-Droid) (11212)
Device information: Android 12 (API 31)
Supported ABIs: [arm64-v8a, armeabi-v7a, armeabi]
Yt-dlp version: 2024.06.30.232744

URL: https://m.youtube.com/watch?v=Y3dGKVyCqxs
ERROR: [Errno 2] No usable temporary directory found in ['/data/data/com.termux/files/usr/tmp', '/']

and also other videos uploaded by the same 9.5M-sub-channel (-> probably prio on yt servers) in the same hour (~7h before testing)

https://www.youtube.com/watch?v=NnoGHlSEiJM
https://www.youtube.com/watch?v=b8oKcBu_OYs
https://www.youtube.com/watch?v=Y3dGKVyCqxs
https://www.youtube.com/watch?v=SoKWfZF9tik
https://www.youtube.com/watch?v=n7ldLYSEiwk
https://www.youtube.com/watch?v=jS9zYYM7x40
https://www.youtube.com/watch?v=T9DJj6tKdM4
https://www.youtube.com/watch?v=kkfX1mpsMKk
https://www.youtube.com/watch?v=ufwK63Ovzjs
https://www.youtube.com/watch?v=i0QeW9iTHPA
https://www.youtube.com/watch?v=s698Ee33J7c
https://www.youtube.com/watch?v=xyhyOgDKiFs
https://www.youtube.com/watch?v=z3-Jc2fPjS8
https://www.youtube.com/watch?v=qcIHauGxOTU
https://www.youtube.com/watch?v=vZcQPZq8hkQ

• the videos are geoblocked in europe (france, netherlands, germany) (-> miami vpn works)
• newpipe can download them

Note: during testing i had ping 9.9.9.9 running in termux and had no connection issues -> errors are app (or app-specific-dns) caused

tested settings (with the Y3dGKVyCqxs, quality format, best quality):

• aria2c setting has no impact
• subtitles setting has no impact
• sponsorblock increases the wait-time before the error and adds a second error above: WARNING: [youtube] Unable to download webpage: [Errno 103] Software caused connection abort

tested formats (in order of tests -> if server changed itd be reflected)

• BROKEN: (multiple attempts) quality format, best quality
• WORKING: legacy format, 137 - 1920x1080 (1080p) + 140 - audio only (medium) MP4 (AVC1 MP4A)
• BROKEN: quality format, video: 2160p, audio: opus 192Kbps -- extra error line: WARNING: [youtube] Unable to download webpage: [Errno 7] No address associated with hostname
• DIFFERENT ERROR: (attempt 1) quality format, video: 360p, audio: m4a 32kbps -- only error: WARNING: [youtube] Unable to download webpage: [Errno 7] No address associated with hostname
• WORKING: (attempt 2) quality format, video: 360p, audio: m4a 32kbps
• DIFFERENT ERROR: (attempt 1) quality format, video: 360p, audio: opus 32kbps -- only error: WARNING: [youtube] Y3dGKVyCqxs: The uploader has not made this video available in your country (note: my vpn did not report any outage and should completely black out in case of failure)
• DIFFERENT ERROR in 2nd window: (attempt 2) quality format, video: 360p, audio: opus 32kbps -- only error: [...] yt_dlp.networking.exceptions.HTTPError: HTTP Error 403: Forbidden
• VPN SWITCHED TO NewYork due to probably unrelated networking errors, which were fixed by this
• WORKING: (attempt 3) quality format, video: 360p, audio: opus 32kbps
• WORKING: quality format, video: 360p, audio: opus 192kbps
• BROKEN: quality format, video: 2160p, audio: opus 192kbps
• BROKEN: (attempt 1) quality format, video: 1440p, audio: opus 192kbps -- additional error: no address associated with hostname (only 1 retry)
• BROKEN: (attempt 2) quality format, video: 1440p, audio: opus 192kbps
• BROKEN: quality format, video: 1080p, audio: opus 192kbps
• WORKING: quality format, video: 720p, audio: opus 192kbps
• WORKING: quality format, video: 480p, audio: opus 192kbps
• WORKING: legacy format, video: 2160p, audio: opus 192kbps
• WORKING: (sanity retry) quality format, video: 2160p, audio: opus 192kbps -- note: the metadata fetching took minutes
• BROKEN: (sanity retry 2) quality format, video: 2160p, audio: opus 192kbps -- additional error: WARNING: [youtube] Unable to download webpage: timed out
• BROKEN: (sanity retry 3) quality format, video: 2160p, audio: opus 192kbps -- additional error: WARNING: [youtube] Unable to download webpage: timed out
• BROKEN: quality format, video: 2160p, audio: opus 32kbps -- additional error: [...] Software caused disconnect
• DIFFERENT ERROR: (attempt 1) quality format, video: 1080p, audio: opus 32kbps -- only error: [...] No address associated with hostname
• BROKEN: (attempt 2) quality format, video: 1080p, audio: opus 32kbps -- additional error: timeout (2/3 retries)
• WORKING: (sanity retry) quality format, video: 720p, audio: opus 32kbps
• WORKING: (sanity retry) legacy format, video: 2160p, audio: opus 192kbps

patterns i can see:

• quality format always works at 720p or less independent of audio quality (and sometimes randomly at higher settings)
• legacy format always works