Playlist download fails after a few items with repeating the last file for every next download
Downloading playlists results in the first 2-5 items downloaded and then for every further down entry of the playlist the last successful video is copied/downloaded again. Easily detectable by the speed, the download bar jumps from 0 to 100% instantly, and with the filesizes being all the same.
All inside the red is the same video when opened
Installed via https://community-scripts.github.io/ProxmoxVE/scripts?id=metube
Version: I don't see a metube version, but it seems to use yt-dlp version: 2025.03.27
Check if you have set in YTDL_OPTIONS={} to trim filenames, if so, remove it.
I believe that this is version 2025.07.31.
In /opt/metube/.env, I find:
DOWNLOAD_DIR=/opt/metube_downloads
STATE_DIR=/opt/metube_downloads/.metube
TEMP_DIR=/opt/metube_downloads
YTDL_OPTIONS={"trim_file_name":10}
I also installed via the community script. I tried importing a playlist and found that while the anchor text for the list was representative of the members of the original playlist, all of the entries resulting from the import shared a common file size and following any of the links yielded the same common content.
I believe that this is version 2025.07.31.
But the issue was Apr 1. ^_^
@SoCalLongboard To solve this issue, you can try:
Check if you have set in YTDL_OPTIONS={} to trim filenames, if so, remove it.
This is because getting the file size is based on the name of the file. If there is a restriction on file names, it may cause different videos to have the same file name. Is this parameter set by the script? maybe you can report it to the script provider.
I'm reporting the issue on the date where I experienced the same (or very similar) problem with the release that was available on the date I'd installed (which happened to also be the day I reported).
I did find that commenting this bit of the configuration did help. The bit I commented was part of the default installation -- I wasn't aware of the configuration file at all until I'd read this report. Thus, I would say that the default upon installation should be reconsidered.
The notion of the file size being based on the filename somehow sounds like a design flaw. Also, the file size is not the issue -- having a plurality of unique links with unique names which yield the same piece of content (whether they're locally saved with a common name or unique names) is the primary issue.
Here's my workflow:
- Within Proxmox, I perform the Metube installation via the community script -- this is a vanilla installation with no configuration changes
- Within Metube, I attempt to download a YouTube playlist's content. The original playlist has no duplicates -- each member has a unique title, a unique URL, and the content at each URL is unique.
- At the completion of the download process, on the Metube side, I have unique links with unique anchor text pointing to the artifacts downloaded by Metube
- Clicking any of these links yields the same content.
Prior to removing my Metube installation, I didn't observe whether the links pointed to a common Metube URL but I was able to get the proper "unique anchors/link to unique pieces of content" relationship by commenting/removing that default configuration row mentioned above.
The notion of the file size being based on the filename somehow sounds like a design flaw. Also, the file size is not the issue -- having a plurality of unique links with unique names which yield the same piece of content (whether they're locally saved with a common name or unique names) is the primary issue.
@SoCalLongboard The issue is actually caused by improper filename configuration:
1. The default file name for MeTube is set to %(playlist_title)s/%(title)s.%(ext)s that starts with the video title.
2. The installation script limits the filename length.
When the first few words of different video titles are the same, they have the same file name. This means that they point to the same file.
Of course, adding an option to let the user decide whether to overwrite files with the same file name is also possible.
Yes, I still question the design here. If I was interviewing a candidate to join my dev team and I gave them a design/coding problem along these lines, I don't doubt that I would press them on this point.
Yes, the filename must be unique. There's no getting around that.
If I'm importing someone else's playlist, I have no control over how they may have named it. In the current design, I'll run into a problem anytime I encounter a playlist with a long name as that aspect will consume most/all of the available filename space.
What might be less problematic would be to have some sort of mapping structure(s) which can relate various naming alternatives (of arbitrary length) to a filename that is intentionally set to a unique string of a fixed length + extension. That string could be some hashed value or an UUID or something else entirely just so long as you avoid name collisions. The structures supporting these relationships can/should provide all of the information needed for presentation purposes.
Yes, naming files with unique identifiers solves the problem of playlists pointing to the same file
In my opinion, however, MeTube functions more as a download tool than as a traditional website.
This introduces another issue: Users often access files directly from their disk. If the file names are too short or consist of meaningless characters, it becomes difficult for them to distinguish between different files.
This ultimately depends on the user and whether they want a meaningful filename. If they prefer not to, they can modify the OUTPUT_TEMPLATE(use the video ID or other parameters, file name shorter and not duplicate). I believe Metube simply sets a default naming convention that meets the needs of most users.