You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to refresh or restart a partial batch archive, the autonumber incrementation starts from zero, rendering this feature completely useless for such a purpose.
The archive function should be more robust saving a lot more metadata in the log file about the archive, the state of the videos among other things that would help resolve subsequent runs for better consistency (sync).
My situation is that I need the archive function proof to any kind of network issues or interruption and to keep the downloaded archive in perfect order and without any missing files, and doing that by only using youtube-dl would be perfect, without having to rely on any kind of 3rd-party or custom database managing software. I believe with a few more pieces this would work very good without the need of much of anything else, data duplication can easily be done with RAID or PAR or whatever on top or just having two zipped archive copies of the whole thing and testing their hash once in a while.
If I do not use the --abort-on-error or -abort-on-unavailable-fragment, and the downloading of some videos fail because of a temporary local network issue then I would have to restart it and fill those missing files with proper autonumbers manually costing time the software could have done it self easily, so I either have to completely avoid using autonumbers or try many standalone attempts and hope one goes through all the way in one single session, and even that wouldn't work for the subsequent uploads to the channel.
I'd be willing to contribute myself to expand the archive feature, however I'm nowhere near experienced with Python, ... or anytime soon.
There should also be more separation when dealing with the whole channel versus a specific playlist, at least on the outside and terminology so it is more clear when dealing with all the playlists, so that the autonumber is tied fixed to the sorting option used, for example in my case I would want to have it tied to the uploaded date from earliest to latest, first video in the channel gets 0001, the second one gets 0002 and so on and the archive function should force the autonumber to that even if there's a video with the wrong one (redownload or rename), but I guess this is already more suited for another feature request PR which I may do later.
The text was updated successfully, but these errors were encountered:
I've run into this as well. When downloading a playlist it's pretty common for the connection to drop, so the archive feature is nice in order to zip straight to whichever video it left off on. But then autonumber starts over, so I end up with filenames like:
001 video1.mp4
002 video2.mp4
001 video3.mp4
I thought it would be nice if we could use track_number or episode_number instead, but these all set NA for YouTube playlists. Some sort of playlist_seq would be great. I've tried some of the timestamp options, but release_date and timestamp also give NA, and some playlists are all uploaded on the same date, so upload_date isn't super useful.
Checklist
Verbose log
Description
When trying to refresh or restart a partial batch archive, the autonumber incrementation starts from zero, rendering this feature completely useless for such a purpose.
The archive function should be more robust saving a lot more metadata in the log file about the archive, the state of the videos among other things that would help resolve subsequent runs for better consistency (sync).
My situation is that I need the archive function proof to any kind of network issues or interruption and to keep the downloaded archive in perfect order and without any missing files, and doing that by only using youtube-dl would be perfect, without having to rely on any kind of 3rd-party or custom database managing software. I believe with a few more pieces this would work very good without the need of much of anything else, data duplication can easily be done with RAID or PAR or whatever on top or just having two zipped archive copies of the whole thing and testing their hash once in a while.
If I do not use the --abort-on-error or -abort-on-unavailable-fragment, and the downloading of some videos fail because of a temporary local network issue then I would have to restart it and fill those missing files with proper autonumbers manually costing time the software could have done it self easily, so I either have to completely avoid using autonumbers or try many standalone attempts and hope one goes through all the way in one single session, and even that wouldn't work for the subsequent uploads to the channel.
I'd be willing to contribute myself to expand the archive feature, however I'm nowhere near experienced with Python, ... or anytime soon.
There should also be more separation when dealing with the whole channel versus a specific playlist, at least on the outside and terminology so it is more clear when dealing with all the playlists, so that the autonumber is tied fixed to the sorting option used, for example in my case I would want to have it tied to the uploaded date from earliest to latest, first video in the channel gets 0001, the second one gets 0002 and so on and the archive function should force the autonumber to that even if there's a video with the wrong one (redownload or rename), but I guess this is already more suited for another feature request PR which I may do later.
The text was updated successfully, but these errors were encountered: