When no format is available (downloadable) for a video [e.g. member-only videos, ETC] notify user & explain why ['NoneType' object is not subscriptable]

[deldesir]

Currently, we get a 'NoneType' object is not subscriptable whenever there is no path available for a video.

Originally posted by @holta in https://github.com/iiab/calibre-web/issues/113#issuecomment-1912850646

[holta]

I don't yet understand:

Anybody have an idea why there would be no video format available (downloadable) to IIAB, "three times in a row" i.e. with different YouTube URLs ?

I understand that "Live" shows on YouTube, and browser / DRM-encrypted movies (and a growing number of corner cases ;) may not have any video format available for download to IIAB.

But FWIW in the general case, the following format/codec selector (default for now!) is supposed to offer some/any video format in almost every case — even if the downloaded video file's viewing bit rate is (sometimes, regrettably!) not very close to the 1000 kbit/s target bit rate:

https://github.com/iiab/calibre-web/blob/d98f002e2f88214d806a9e127c36766e6e58b675/scripts/lb-wrapper#L14

Related:

• 85

• 89

[holta]

@deldesir is there also a new issue in @nzola's screenshot below, from LRN2.ORG ?

Can you open a new ticket to investigate this failed: no such column: error if so?

[deldesir]

When a video is downloaded successfully, it's moved to a new location. Its path in xklb-metadata.db has changed. When the same video URL is provided again, xklb reports it has already fetched metadata for it. The metadata are reused, but the path is incorrect. Updating this path after each download will get rid of this error.

[holta]

failed: no such column: error

Above "redownloading of a video" issue should hopefully soon be solved by:

• PR #118

ASIDE: Let's not lose @nzola's larger URL (containing many YouTube playlists) to help with ongoing testing...

https://www.youtube.com/@iogacademy/playlists

[deldesir]

Membership-only videos fail with the usual NoneType object is not subscriptable error. What should be displayed per the database error value from media table:

ERROR: [youtube] JufLGbcXXjY: No video formats found!
ERROR: [youtube] JufLGbcXXjY: No video formats found!
[youtube] Join this channel to get access to members-only content like this video, and other exclusive perks.
No video formats found!
Requested format is not available

[holta]

Membership-only videos fail with the usual NoneType object is not subscriptable error

A bit more about Member-only YouTube videos:

https://support.google.com/youtube/answer/7544492

[holta]

@deldesir thanks for solving some of these scenarios:

• PR #121

Please summarize what remains to close this issue #114 ?!

[deldesir]

One important question remains. What if a membership-only video is converted into a standard one? To ensure resubmitting the same URL succeeds, failed URLs needs to be rechecked. A force download pseudo-code could be: 1- if requested_url not found, a. delete the row containing current URL b. resubmit the same URL 2- if failed: a. log URL won't download

[holta]

What if a membership-only video is converted into a standard one?

YouTube-and-other videos can change after being published, in many different ways:

Member-only versus Public status... sounds like just one of many different ways... that any videos can (while retaining the same URL!) change after publication.

[holta]

@deldesir

There are so many different kinds of YouTube download failures:

• members-only videos, no available format, geographic region block, ETC Etc etc 📈
• can we make sure the 3-5 most common (or 10 most common?!) kinds of downloads are clearly explained to the educator/family?

And definitely close this original issue within coming weeks if possible!

[deldesir]

To achieve this, we need to redirect these messages directly from yt-dlp STDERR. Currently we filter these videos by matching their duration metadata (which are always 0 or NULL), and just display their titles in a list of "Unavailable videos".

[holta]

To achieve this, we need to redirect these messages directly from yt-dlp STDERR. Currently we filter these videos by matching their duration metadata (which are always 0 or NULL), and just display their titles in a list of "Unavailable videos".

Thanks much for explaining. Something like this needs to happen rather soon:

• yt-dlp tries hard but its glitchiness (due to YouTube's fragile downloading realities!) makes crystal clear messaging here very important for Q3 2024.

• Regardless: Users need crystal clear explanation(s) in "Tasks" view for all of the most common downloading failures — that means specific hint(s), e.g. if YouTube Format 22 lacks certain codecs, or if YouTube deprecates certain video formats entirely, ETC — wherever we can.

(Not that we can anticipate every yt-dlp <-> YouTube glitch of course, but the most common ones definitely need to be messaged ultra-clearly!)