[Feature Request] 'treat as playlist' for more URLs

[altadr]

First of all, thank you very much for the new and even better release.

And once more for the 'treat as playlist' feature, in the meantime it has proven extremely useful for so many URLs ending on '/videos'.

Sometimes this could be even more useful if also applicable to other channel-URLs like such ending on '/featured' and such only consisting of the 'Uploader URL' (without further suffix) or ending on '/channel/' + Channel-ID, maybe others more.

In few cases I found it even on a URL ending on '/videos' not working, e.g. https://www.youtube.com/@dalematthies/videos and had no idea, what the reason could be...

Maybe, and hopefully, just a little modification could make it work even more perfectly ...

Thank you very much and best wishes!

[ErrorFlynn]

Sometimes this could be even more useful if also applicable to other channel-URLs like such ending on '/featured' and such only consisting of the 'Uploader URL' (without further suffix) or ending on '/channel/' + Channel-ID

This is not possible because whole channels have multiple playlists. For example, for https://www.youtube.com/@pbsspacetime yt-dlp gives data that contains a playlist for the Videos tab, and a playlist for the Live tab. And for https://www.youtube.com/@pbsspacetime/featured, yt-dlp gives data that contains the three playlists that are featured. There's no command line option to tell yt-dlp which videos to download from multiple playlists.

In few cases I found it even on a URL ending on '/videos' not working, e.g. https://www.youtube.com/@dalematthies/videos and had no idea, what the reason could be...

That's strange, it works for me.

[ErrorFlynn]

In few cases I found it even on a URL ending on '/videos' not working, e.g. https://www.youtube.com/@dalematthies/videos and had no idea, what the reason could be...

There's an issue, that if you pop up the queue menu while the program waits for data from yt-dlp, then the Treat as playlist command is missing from the menu. But if you pop up the menu after the data has been received (when the media title is displayed instead of ...), then the command is there. Maybe that's what you experienced, leading you to believe the feature didn't work?

[altadr]

Thank you, now I understand how my misconception of this occurred.

Having experienced the seeming malfunction multiple times, I didn't recognize that it was only caused by too hasty clicking in instead of waiting a few seconds for completing the data when internet connection was slow.

Thank you for clarifying this.

'Clarifying' is the keyword leading to another item: The meaning of the attribute 'done'.

The use of the simple word 'done' for the status in the queueing list
doesn't differentiate between

• 'actually done now, exited after having completely downloaded and processed'

in contrast to

• 'seems not necessary to do, because of found the ID in the history list, so exited directly after detecting that, without further downloading',

in both cases simply the status 'done' is shown.

Doubtlessly it is a very good feature to prevent unnecessary double-downloads by searching the ID in the history.

Only, showing the status 'done', too,
when ID found and therefore not actually downloaded at this time,

can be a bit misleading for the user.

There may be several reasons for the wish to download the same video-ID a second time, e.g. damage of file, need of different resolution, different other poperties, lost file, ...

So it could be a good feature to show instead of 'done' something like 'ID found in history' in the cases when therefore downloading was actually not started.

This could clarify the situation for the user and be really helpful.

For best usability the check in the history list is done before the media title is displayed in the queue and from first appearing be highlighted in some way (e.g. bold red characters, ...).

Then the user knows at first glance, the video is not downloaded another time, and will not be without further special action.

So he is aware having to search and erase this ID from the history file to make the second download possible.

Maybe even this could be easily automatized, possibly connected with the question 'delete ID from history and repeat download Y/N ?' .

Sorry for drifting a bit off topic ...

Thank you again for developing this marvelous program!

[ErrorFlynn]

The program actually doesn't keep a history of what was downloaded, it just checks if the file already exists at the download location, and sets the done status if it does. This doesn't always work, because it's not always possible to predict what the file name will be. It has actually been consistently not working for me for some reason, and I think I'm just going to remove the feature altogether. It seems like it's more trouble than it's worth.

[altadr]

Please do not remove the 'download-archiv.txt' history feature.

It is very helpful in the existing form, though at the moment not yet being perfect ...

[ErrorFlynn]

Please do not remove the 'download-archiv.txt' history feature.

The program does not have that feature! I have no idea what you're talking about. Maybe you're using the argument --download-archive FILE for yt-dlp (maybe in a config file)? The program does not write nor read a download history file.