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

[deldesir]

Regression / Known issue (introduced by PR #199)

"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.

Originally posted by @deldesir in #199 (comment)

[holta]

Regression / Known issue (introduced by PR #199)

"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.

According to #199 (comment) itself:

A new PR should [address] this regression by automatically deleting these videos records from xklb-metadata.db

Thanks! Can this PR be pulled together relatively quickly?

Somewhat related:

• "Download to IIAB" worked 5 out of 15 tries (trying to d/l individual YouTube videos) — "Tasks" view screenshots show the 10 failures [e.g. formerly live videos] #84
• Formerly live videos fail to download: "failed to download [download] ... does not pass filter (live_status=?not_live); skipping" #188
• PR Adjust message to warn about problematic videos [e.g. "live" videos, that might not really be live anymore, but still fail to download] #194

[deldesir]

I also think task messages should be adjusted according to #188 (comment)

[holta]

I also think task messages should be adjusted according to #188 (comment)

"Tasks" view definitely sounds like the right place for this now. Please go ahead: (keep things as simple as possible!)

• Tell people in plain English (1) what's really happening, (2) what they can do about it.
• The English explanation can always be clarified (or made more vivid) later.

[holta]

@deldesir is PR #194 fully adequate, as merged 9 days ago?

• PR Adjust message to warn about problematic videos [e.g. "live" videos, that might not really be live anymore, but still fail to download] #194

(Or does its code need to be slightly revised — if it too is somewhat related to explaining download mechanics of "ostensibly live" videos to users/operators ?)

[deldesir]

The status messages should be more explicit to let the user know about the type of video being processed, I mean the live_status of the video.