There needs to be a deeper discussion about what "live" YouTube videos really mean.

Forthrightly acknowledging the differences between "actually live" YouTube videos and "formerly live" YouTube videos (and the dramatically different end-user consequences of downloading both kinds) will move this design process forward, with sincere respect for all people involved.

Please help articulate what's really needed in the design discussion here:

• Formerly live videos fail to download: "failed to download [download] ... does not pass filter (live_status=?not_live); skipping" #188 (comment)

Looks good!

Please test with all 3+ kinds of "ostensibly live" YouTube videos: (and please explain what happens in each case)

1. Not Yet Live
2. Actually Live
3. Formerly Live

Actual test cases are posted here, to help with testing:

• Formerly live videos fail to download: "failed to download [download] ... does not pass filter (live_status=?not_live); skipping" #188 (comment)

Please test with all 3+ kinds of "ostensibly live" YouTube videos: (and please explain what happens in each case)

1. Not Yet Live
2. Actually Live
3. Formerly Live

RECAP: To help push this PR forward, please take very seriously all 3 kinds of test cases outlined at...

• Formerly live videos fail to download: "failed to download [download] ... does not pass filter (live_status=?not_live); skipping" #188 (comment)

1. Not Yet Live: https://www.youtube.com/watch?v=oxBc0e-bKOk
   

2. Actually Live: https://www.youtube.com/watch?v=5kw8ywYmVz4
   

3. Formerly live: https://www.youtube.com/watch?v=vpBqz11OhR4
   

"Not yet live" and "Actually live" videos do not have a duration yet. This is the reason they are reported as "not available" in Calibre-Web.

xklb-metadata.db live_status values for:
Not yet live: is_upcoming
Actually live: is_live
Formerly live: was_live

Regression / Known issue (introduced by this PR):

"Upcoming live" and "Actually live" videos are caught in subsequent downloads as requested videos. They will remain as such until they are available, that means having a duration value.

The PR can be merged though. A new PR should addressed this regression by automatically deleting these videos records from xklb-metadata.db

"Upcoming live" and "Actually live" videos are caught in subsequent downloads as requested videos. They will remain as such until they are available, that means having a duration value.

Thanks @deldesir for explaining, alongside:

• Vital screenshots above, making clear our 3 primary cases
• xklb-metadata.db's corresponding live_status values {is_upcoming, is_live, was_live}

Follow-up PR will clean up and clarify very soon, as outlined here:

• "Upcoming live" and "Actually live" videos are caught in subsequent downloads [need to clearly explain errors, e.g. in "Tasks" view] #202