To save a YouTube playlist to an SSD attached to a Raspberry Pi, use yt-dlp to select the playlist items and write them to a directory on the mounted drive. FFmpeg does not enumerate or download the playlist; yt-dlp can call it when separate audio and video formats need merging, and you can also use it for other media processing.
The key to repeat runs is to keep yt-dlp’s download archive on persistent storage and use the same archive file each time. The examples below use placeholders: check your Pi’s actual mount path, replace the playlist URL, and verify current yt-dlp syntax before relying on a job overnight.
Separate playlist work from media processing
A playlist URL is input for yt-dlp, not a playlist that FFmpeg independently fetches from YouTube. yt-dlp reads the playlist, handles item selection and download destination, and records successful downloads when you ask it to maintain an archive. FFmpeg is a separate media tool; yt-dlp may use it to combine downloaded streams or you may use it for conversion.
This distinction matters because a command that names FFmpeg alone does not provide the playlist handling described here. If you want a set of videos saved to a directory, begin with yt-dlp. If a media file needs conversion or separate audio and video tracks must be combined, that is where FFmpeg becomes relevant.
YouTube extraction can depend on current site behaviour and access conditions. Some videos may require cookies, headers, or matching network conditions, and playlist availability can change. Do not assume every playlist item is accessible just because the playlist page opens in a browser. For rights and access, confirm you have permission to retain the material and check the applicable service terms and local law; this article does not determine whether a particular download is allowed.
If the end goal is to broadcast files rather than keep an offline library, that is a different workflow. For example, see how a Raspberry Pi can be used for a 24/7 bhajan stream; storing files locally is only one part of a live-channel setup.
Confirm the Pi and SSD mount
Before installing tools, connect the SSD using an interface supported by your Raspberry Pi model and operating system. The model, enclosure, cable, power arrangement and filesystem all affect whether the drive is usable; there is no universal device name or mount directory that can safely be assumed here. Check the documentation for your exact board and inspect your system’s storage tools or desktop file manager to identify where the drive is mounted.
A mount path is the directory through which the operating system exposes the drive. Use the path actually shown on your Pi, then create or select a folder on that drive for the video files. Do not substitute a familiar-looking path from someone else’s tutorial unless you have verified it exists and is on the SSD. A path typo can result in saving to a different filesystem, including the Pi’s boot storage.
Check that the account which will run yt-dlp can write to the chosen folder. A practical test is to create a small test file there and remove it, or use your file manager to create and delete a temporary item. If this fails, resolve the permissions or mount issue before downloading a large playlist.
For scheduled runs, also confirm the drive is mounted and writable at the time the job will run. A path that works while you are logged in does not prove the SSD will be available after a restart or at a later scheduled time. Raspberry Pi’s getting-started documentation describes boot media and model support; consult the relevant section for your board rather than assuming all Pi models connect or boot from storage in the same way.
Install or verify yt-dlp and FFmpeg
Use current installation guidance for the operating system installed on your Pi. The research for this workflow does not establish one installation command or version as suitable for every Raspberry Pi OS release, so do not copy a command blindly. Follow the yt-dlp project installation instructions and the FFmpeg documentation, choosing a supported method for your OS and keeping track of how you installed each tool.
Verify that each program can be invoked from the environment where you plan to run the download. If yt-dlp is installed for one user but a scheduled task runs as another, that task may not see the same executable or configuration. Likewise, the presence of an FFmpeg command in one shell does not establish that yt-dlp can find it when performing a merge. Check using the same account and environment that will run the job.
You do not necessarily need FFmpeg to fetch every playlist item. The yt-dlp FAQ explains that it is needed when separate audio and video formats must be merged, and the project’s format-selection examples describe merging separate formats. If the available media is already in a single suitable file, a merge may not be needed. Let yt-dlp’s current format documentation and the actual formats available for an item guide the choice rather than assuming every item has the same streams.
Choose a destination on the SSD
Pick a directory with a clear purpose, such as a videos folder under the SSD’s verified mount point. If your mount is /media/yourname/MediaDrive, for example, a possible destination could be /media/yourname/MediaDrive/videos—but that is an illustrative path, not a default. Create the directory if needed and confirm it is on the SSD and writable before using it in a command.
yt-dlp uses -P to set the download path and -o to control the output filename template. A template can include playlist order, title and video ID so that files are easier to identify. The video ID is useful when titles repeat or are later edited; playlist numbering makes it easier to compare the local sequence with the playlist. Keep names understandable and avoid designing a deeply nested folder structure until you know how the playlist is organised.
This schematic command demonstrates the parts working together. Replace both /path/on/ssd values with directories you checked, and replace PLAYLIST_URL with the actual URL:
yt-dlp --download-archive "/path/on/ssd/archive.txt" \
-P "/path/on/ssd/videos" \
-o "%(playlist_index)03d - %(title)s [%(id)s].%(ext)s" \
"PLAYLIST_URL"
The quotes around the URL matter when it contains shell-special characters such as &. The command delegates item selection and downloading to yt-dlp. Its filename template asks for a padded playlist index, title, and ID; output extensions are determined by the resulting media. This is a schematic example, not a tested command for every Pi or yt-dlp version. Check the yt-dlp FAQ on paths and output templates if current syntax differs from what you have installed.
If you are organising media for a live stream, keep the roles clear: a download directory is not itself a streaming playlist configuration. The distinctions are also relevant in a guide to adding a playlist file to an FFmpeg YouTube stream.
Download items and avoid repeating successful ones
The --download-archive option tells yt-dlp to use a record of downloaded video identifiers. Keep the archive file and pass the same path on later runs. According to the yt-dlp FAQ, subsequent runs skip identifiers already recorded, and only successful downloads are added. This is a practical way to request new playlist items without asking yt-dlp to fetch all previously successful items again.
The archive is not a substitute for your video files or a backup. If you delete a saved video but retain its identifier in the archive, a later run can skip that item. Conversely, if you delete or lose the archive, yt-dlp no longer has that record to consult and may attempt to download those items again. Store it somewhere persistent, ideally alongside the library or in another backed-up location, and do not casually replace it between runs.
There are two kinds of “already downloaded” that are easy to confuse. The archive tracks identifiers from successful yt-dlp downloads; it does not simply inspect every arbitrary file in the destination and infer its history. A file copied into the folder from elsewhere may not be recorded. A file removed after a successful download may still be represented in the archive. Keep the archive and files aligned with your own retention decisions.
Run the command once interactively before automating it. Read the output for errors, confirm a few expected files exist, and confirm a repeat run behaves as intended. YouTube access requirements can change, and an item that fails today is not counted as a successful download in the archive. If you need cookies or other access configuration for certain content, consult yt-dlp’s current documentation and avoid putting sensitive values in a shared script or log.
When you later turn local media into a continuous broadcast, a USB or SSD playback setup has its own operational considerations. See streaming files from a drive to YouTube on Raspberry Pi for that separate task; it does not replace the download workflow above.
Use FFmpeg only when the media task calls for it
When YouTube provides separate audio and video formats and you select both, yt-dlp can use FFmpeg to merge them into a playable output. The yt-dlp project documents a bestvideo+bestaudio example that depends on FFmpeg. This is a merge operation after fetching the components, not FFmpeg downloading a playlist. If you use yt-dlp’s defaults, it handles format selection according to its current behaviour; do not assume those defaults will produce a particular codec, resolution or file size for every item.
Conversion is a separate choice. You might convert a file to meet a player’s format requirements, but transcoding takes processing time and can change quality or increase storage use depending on settings. Avoid converting merely because FFmpeg is installed. First check what the source file contains and what the intended playback device accepts. If merging separate streams yields a usable file, extra transcoding may be unnecessary.
Use current FFmpeg documentation for options and inspect the output after processing. For a single-file conversion, work from a copy or keep the original until you have checked the result. This gives you a way back if the chosen codec, audio mapping or container is unsuitable. Do not add a bulk conversion step to a repeat download command until you have tested it on a representative file and understand where the converted output will be written.
Estimate space and check saved files
The amount of SSD space needed depends on playlist contents, chosen formats, duration, retention and any converted copies. The title alone does not provide enough information to recommend a capacity. Check the available space on the mounted SSD before starting, and leave room for the operating system or other files if the same drive serves more than one purpose. Do not treat a boot-media recommendation as an estimate for a video archive.
Raspberry Pi’s getting-started guidance recommends at least 32 GB for Raspberry Pi OS desktop and Full, and at least 8 GB for Raspberry Pi OS Lite. Those are boot-media starting recommendations, not guarantees of room for a playlist library. Your media requirement may be smaller or much larger, so size the SSD based on the files you intend to retain and the free space reported by your system. Support for USB mass-storage or NVMe boot also varies by model; check the exact board and the official Raspberry Pi storage and accessories documentation.
A useful comparison is not “which SSD is fastest” in the abstract, but which arrangement fits your board and job:
| Choice to check | What to establish before relying on it |
|---|---|
| Pi model and interface | Confirm the board supports the intended USB or other storage connection. |
| SSD capacity | Estimate the library you want to keep, then compare with usable free space. |
| Boot and media roles | Decide whether the SSD holds only downloads or also the operating system. |
| Enclosure, cable and power | Check compatibility with the board and the drive’s connection method. |
| Filesystem and mount behaviour | Confirm the OS can access the drive reliably at the path used by the command. |
| Retention and archive | Decide what is kept, what is deleted, and how the archive record stays consistent. |
After a run, check that expected files appear in the destination, that the archive file has been retained, and that the filesystem still has free space. Open a sample file with a suitable player or inspect its media details if you plan further processing. For a recurring job, log its output and review failures; make sure the mount is present before the job starts. Those are operational precautions, not a guarantee that every run will succeed.
Prepare for repeat or scheduled runs
If you intend to run the download again later, keep the command, destination and archive path stable. Test each change manually first: moving the SSD, renaming the archive, changing the output template, or running under a different account can affect where files go or which history is consulted. Use a log location that remains available and writable, and check the result rather than assuming that a scheduled task ran correctly.
Before scheduling, test what happens when the SSD is absent or not writable. Do not assume your operating system will mount it at the same path under every connection or login condition. Add a pre-run check appropriate to your environment, and arrange a way to notice failures if you will not be watching the Pi. The exact method depends on the OS and scheduling tool, which are not specified by the playlist command itself.
If the Pi is already serving a continuous YouTube channel, downloading and streaming are distinct workloads. They share storage but not the same purpose, and a change to one process should not be assumed safe for the other. You may find the Raspberry Pi 3 B+ streaming considerations useful for assessing a separate live-streaming setup, but it does not establish what every Pi can download or process.
If local command-line maintenance is not the task you want to operate, compare alternatives based on what they actually do. StreamNeo removes the need to leave a computer on to broadcast an uploaded video as a YouTube live stream, but it is not a playlist downloader and does not replace an SSD library workflow.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does FFmpeg download a YouTube playlist by itself?
No. In this workflow yt-dlp reads the playlist and downloads items to the destination you choose. FFmpeg is used for merging separate media formats or other processing when needed.
How do I download only new videos from a playlist?
Use yt-dlp’s --download-archive option and keep the same archive file between runs. It records identifiers for successful downloads so later runs can skip those items; check that the archive and retained files still match your own library.
Where should the archive file go?
Put it on storage that persists between runs, such as a verified directory on the SSD, and use that exact path consistently. If you lose the archive or point later runs to a different one, yt-dlp may no longer know which successful items were already recorded.
Can I use any Raspberry Pi SSD path from an online example?
No. Mount paths depend on your board, OS, connection and setup. Identify the SSD’s actual mounted directory, confirm it is writable, and use that path for both the destination and archive.