FoxTrotte
commented
11 months ago 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
Open abdullahamin665 opened 1 year ago
FoxTrotte
commented
11 months ago 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
commented
11 months ago 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
commented
10 months ago Just now experienced this problem after having updated the app to v1.11.2
JunkFood02
commented
10 months ago 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
commented
10 months ago 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
commented
9 months ago 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,
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
commented
9 months ago @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
commented
9 months ago 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
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
commented
9 months ago 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
commented
9 months ago Sorry, while editing my previous comment to make it clearer, I didn't notice yours. Please see above.
JunkFood02
commented
9 months ago 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:
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
commented
9 months ago 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:
Android Settings --> App Management doesn't help, though. JunkFood02
commented
9 months ago @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
commented
9 months ago 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:
So far, "problematic" videos can be identified by the following two properties:
(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
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
commented
9 months ago @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:
(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
commented
9 months ago 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.
Here's my understanding gathered so far, including a few side notes:
dkambersky
commented
9 months ago 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
commented
9 months ago 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:
ImportGfEW
commented
9 months ago 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 failsvcodec:av1,res:360,acodec:opus,abr~64 failsvcodec,res:360,acodec:opus,abr~64 failsres:360,acodec:opus,abr~64 worksvcodec:,res:360,acodec:opus,abr~64 worksvcodec:avc,res:360,acodec:opus,abr~64 worksvcodec:avc1,res:360,acodec:opus,abr~64 worksvcodec: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
commented
9 months ago @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:
- Many yt users upload their videos as mp4, still using legacy codecs.
- 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.
- But once the video gains popularity, transcoding is done.
- 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
commented
7 months ago @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
commented
6 months ago 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
commented
6 months ago @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
commented
6 months ago 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
commented
6 months ago @JunkFood02 Re stacktrace: Would it help if I provided more log excerpts like the one in https://github.com/JunkFood02/Seal/issues/1161#issuecomment-1863945038 ?
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
commented
6 months ago Would it help if I provided more log excerpts like the one in https://github.com/JunkFood02/Seal/issues/1161#issuecomment-1863945038?
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
commented
6 months ago 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
commented
6 months ago 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
commented
6 months ago 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
commented
5 months ago Having the same error here with most links, like https://youtu.be/U_LlX4t0A9I.
GfEW
commented
5 months ago @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
commented
5 months ago 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
commented
4 months ago 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', '/']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 impactsubtitles setting has no impactsponsorblock increases the wait-time before the error and adds a second error above: WARNING: [youtube] Unable to download webpage: [Errno 103] Software caused connection abortpatterns i can see:
Checklist
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