To schedule a different playlist for each day in FFmpeg, create a separate concat manifest for each schedule variant and use an external scheduler or wrapper to choose the right one. FFmpeg sequences the files listed in a manifest; the calendar decision belongs outside FFmpeg.
That separation matters when you need a daily file or a broadcast that changes at midnight. The examples below are illustrative patterns, not tested commands, and they do not establish compatibility for your media or the ingest requirements of any streaming platform.
Separate the playlist from the calendar
Think of the setup as two jobs. First, define the order of media files for each day. Then decide when and how a process will use the matching list. FFmpeg’s concat demuxer handles the first job: it reads a text manifest and presents the listed files in sequence. A scheduler such as Linux cron can trigger the second job. The official FFmpeg concat demuxer documentation describes the input-list workflow; it does not describe a built-in calendar-based playlist selector.
This distinction keeps a weekday change from becoming a tangle of media logic and timing logic. If Monday has a morning prayer recording, a set of bhajans and an evening reflection, put that sequence in Monday’s manifest. Tuesday can have a different sequence in its own manifest. The wrapper needs only to decide which file to pass to FFmpeg.
There is also a process-design question: do you want to render a file for later use, start a new live output each day, or replace an FFmpeg process already broadcasting? These are different designs. A command that writes output.mp4 does not become a live stream just because a scheduler runs it every day. For a live destination, you must supply suitable output options and a destination URL, and verify that destination’s current ingest requirements separately.
If the purpose is a continuous YouTube channel rather than a batch export, decide how the day boundary should appear to viewers. You might end one broadcast and start another, or use a wrapper or supervisor designed to replace the running process. A cron entry that starts a process at midnight does not, by itself, stop yesterday’s process cleanly or ensure the new one takes over.
Make one manifest for each schedule variant
A concat manifest is a plain-text list of files in the order they should be read. You can create one per weekday, or one per distinct schedule if several days share the same order. Keeping names predictable makes both manual review and automation easier. For example, /srv/playlists/monday.ffconcat and /srv/playlists/tuesday.ffconcat make the intent visible without opening the files.
An illustrative manifest might look like this:
ffconcat version 1.0
file /srv/media/intro.mp4
file /srv/media/morning-prayer.mp4
file /srv/media/bhajans.mp4
file /srv/media/evening-reflection.mp4
The ffconcat version 1.0 marker must be exactly on the first line, without leading whitespace or a byte-order mark, for FFmpeg to recognise the format automatically. The FFmpeg demuxer documentation explains the concat script syntax, including handling paths and the safe option. A path with spaces or special characters needs the escaping or quoting specified there; do not assume that shell quoting rules can simply be copied into a manifest.
The concat demuxer’s safe option defaults to 1, which rejects paths it considers unsafe. Setting it to 0 permits any filename, but that changes the trust boundary: only use it when the manifest is controlled and its entries are trusted. For a fixed library under a directory you manage, prefer simple, predictable paths where possible rather than loosening path checks as a first response to an error.
Keep the manifest files and media paths stable. Use absolute paths for a scheduled job, and make sure the account that runs the scheduler can read every file. A manifest that works from your interactive terminal can still fail when cron runs it as a different user or with a different working directory. Test permissions as the scheduled account, not only as your own login.
The manifest is also a useful review point. Read each one in order and confirm that it contains the intended files, no stale paths and no accidental duplicate. If you maintain a devotional channel, a short spoken introduction before a longer music block may be deliberate; an unintended second introduction usually is not. Keep a source copy under version control or another backup method if schedule edits are important to your operation.
Map weekdays to manifests in a wrapper
A wrapper is a small script that asks the system for the current weekday, maps that value to a manifest, and invokes FFmpeg with that input. Keeping the mapping in one place is easier to audit than hiding it in multiple long scheduler lines. The following is an illustrative shell pattern only; it has not been tested, and it does not establish that the listed media files can be concatenated or streamed to a destination:
#./bin/sh
set -eu
case "$(date +%u)" in
1) manifest=/srv/playlists/monday.ffconcat ;;
2) manifest=/srv/playlists/tuesday.ffconcat ;;
3) manifest=/srv/playlists/wednesday.ffconcat ;;
4) manifest=/srv/playlists/thursday.ffconcat ;;
5) manifest=/srv/playlists/friday.ffconcat ;;
6) manifest=/srv/playlists/saturday.ffconcat ;;
7) manifest=/srv/playlists/sunday.ffconcat ;;
*) echo "Could not determine weekday" >&2; exit 1 ;;
esac
exec /usr/bin/ffmpeg -f concat -i "$manifest" -c copy /srv/output/today.mp4
The command uses -c copy only as an example. It performs no calendar selection; the wrapper passes one chosen manifest to FFmpeg. A command in the same general shape is:
ffmpeg -f concat -i /srv/playlists/monday.ffconcat -c copy output.mp4
Treat this as illustrative, not as a tested recipe. In particular, do not rely on stream copy until you have checked that every input meets the concat demuxer’s stream requirements. For a live output, replace the file destination with the appropriate platform-specific output options only after checking that platform’s official guidance.
Use a defined time zone for both the scheduler and the wrapper’s weekday calculation. If cron triggers just after midnight in one time zone while date reads another, the selected manifest may not match the day you intended. The wrapper should also fail visibly if it cannot determine the day or if the chosen manifest is missing; silently falling back to Monday can turn a configuration error into a full day of incorrect programming.
For a simple daily batch job, a single daily wrapper keeps the weekday map together. Separate cron entries for each day make the calendar visible in the crontab, but repeat the invocation details and can be easier to misalign when paths or options change. Choose whichever makes the schedule easiest for you to inspect and maintain.
Trigger the wrapper with cron on Linux
Cron is one way to run a wrapper on Linux. A daily trigger at midnight can be written as an illustrative crontab line:
0 0 * * * /usr/local/bin/run-daily-playlist >> /var/log/daily-playlist.log 2>&1
This line starts the wrapper; it does not supervise a process that is already running. The crontab manual documents the job environment and time-zone handling, including CRON_TZ in implementations that support it. Check the manual for the system on which you are deploying, and set the time zone deliberately when local midnight matters.
Cron does not necessarily inherit the environment of your interactive shell. Set needed variables explicitly, call FFmpeg by its absolute path, use absolute paths in the wrapper and manifests, and send both standard output and error to a log you can inspect. Confirm that the scheduled account has the necessary permissions. Avoid depending on a shell alias, a login profile or a mounted drive that is only available in your own session.
The line above can be appropriate for a one-shot task that generates a daily file. It is not a complete plan for an always-on broadcast: the old process may still be running when the new job starts, or the new invocation may exit without replacing it. For continuous output, use a process supervisor or a long-running wrapper whose replacement and restart behaviour is understood. It must handle stopping the prior process, starting the new one, and reporting failures rather than allowing duplicate broadcasts to accumulate.
If you use cron, write down the schedule’s time zone as an operational choice. Daylight-saving changes can make local times behave differently from ordinary days. Test how the system treats the transition and decide whether the priority is a fixed local clock time or a fixed interval. Do not assume a line that appears to mean “midnight” is enough to settle process replacement or time-zone behaviour.
For channel-level setup and the parts that happen in YouTube rather than in FFmpeg, see the guide to using YouTube Live Control Room for a 24/7 Indian music stream. Keep the scheduler’s responsibility narrow: select and launch the media process, while you verify the separate live destination and channel settings.
Check media compatibility before using the concat demuxer
The main constraint on this design is compatibility. The FFmpeg Project states that concat demuxer inputs must have the same streams, codecs and time base. Matching file extensions is not enough. Two MP4 files may contain different video or audio codecs, stream layouts, dimensions or timing characteristics; a playlist that mixes them can fail or produce timestamp and playback problems.
Inspect every file in every manifest, not just the first pair. Check which audio and video streams exist, their codecs and time bases, and whether the files are consistent with the output you intend to make. Files with different stream layouts may need to be normalised before they are placed in the same concat-demuxer playlist. If your clips come from multiple cameras or editing tools, do not assume that exporting them all as MP4 made them equivalent.
Duration is another practical concern. The demuxer uses file durations to adjust timestamps. If a duration is missing or inaccurate, the transition to the next file can be affected. The concat script supports a duration directive to override an unavailable or inaccurate duration, but that is a value you need to verify rather than guess. Check the resulting sequence around each boundary, especially where a short intro precedes a long recording or where one file was edited with unusual timing.
For more on symptoms viewers notice when a playlist is poorly behaved, the guide to fixing stuttering in a 4K 60fps YouTube live playlist is a useful adjacent reference. It does not replace compatibility checks on your own files. A source file can appear smooth on its own and still expose a discontinuity or timestamp problem when concatenated with another one.
Treat a successful command exit as only one check. Review the output or watch a test broadcast at each file transition. Listen for gaps, abrupt changes in loudness, missing audio, or a sudden change in picture timing. For an always-on devotional or ambience channel, a transition that happens during the night may be the one your viewers notice first because nobody is there to correct it immediately.
Choose stream copy or re-encoding appropriately
With stream copy, FFmpeg passes compatible compressed streams through rather than decoding and encoding them again. That can avoid a new encoding step, but it places more weight on the input files already matching the concat demuxer’s requirements and the output’s requirements. The -c copy example above is not a universal solution and is not a compatibility fix.
Re-encoding is appropriate when the files do not fit a consistent output, or when you need a filter or transformation. It lets you produce a common set of streams and settings, but it uses processing time and can change picture or sound quality depending on the choices you make. If you run it on a small computer, test the workload rather than assuming it will keep up with a continuous output. For a low-end machine, the guide on configuring OBS for a 24/7 YouTube stream on a low-end PC in India offers context on the broader trade-offs of running a sustained stream locally.
A practical decision is to test a representative pair first, then the full schedule. If all files are demonstrably compatible and your intended output accepts them, stream copy may be suitable. If you have mixed formats or need consistent output properties, normalise the assets in advance or use an appropriate re-encoding workflow. Do not discover which route you need at midnight, when the schedule has already moved on.
Keep preparation separate from daily playback. You can convert or inspect media ahead of time, then use the same known-good set in your weekday manifests. That also makes updates safer: replace a source file only after checking it against the expected stream layout and testing the transition. If the channel mixes speech and music, review levels and silence at boundaries as well as the codec details; technical compatibility does not guarantee a comfortable listening transition.
If the recurring operational burden is keeping a local computer running and recovering a dropped broadcast, StreamNeo addresses that specific burden by turning an uploaded file into a YouTube stream that can continue with your computer switched off and be monitored and restarted if it drops. It is YouTube-only, and it does not remove the need to prepare a suitable file, choose the right daily content or check your channel and broadcast settings.
Test the schedule and recovery behaviour
Run the wrapper manually under the same account and environment that cron will use. Confirm that it selects the expected manifest for each weekday, that the selected file exists, and that FFmpeg receives the paths you intended. Test the output in a controlled setting before depending on it for a public channel. The exact output test differs between making a file and sending a live broadcast, so keep those cases distinct.
Check the points where failures are likely to occur: unreadable media, a missing manifest, an invalid path, a process that exits early, and a new daily launch while an old process is still active. Decide what the wrapper should do in each case. A sensible failure should leave a useful log and an alert or other prompt for you to investigate, not quietly play the wrong day’s list.
For a continuous channel, test the day change while you can observe it. Verify that the old invocation stops as intended, the selected new list starts, and the destination behaves as expected. A setup that makes a correct file once is not yet a recovery plan for a broadcast that runs unattended. The guide on restarting a YouTube bhajan live stream automatically after disconnecting covers a related recovery concern; apply the same habit of testing failure and restart behaviour rather than relying on a successful first launch.
Keep a record of the schedule time zone, the manifest mapping, the command or wrapper version, and the last successful test. When you change a playlist, test the changed manifest and its transitions, not only the unchanged days. If a day’s programme is time-sensitive, decide what should happen when the job cannot start on time: wait for a manual restart, use a defined fallback or alert you. The right answer depends on whether an uninterrupted stream or the correct day’s content matters more in that moment.
If your requirement is simply a daily render, a cron job can be a reasonable trigger. If the requirement is that a live stream always has exactly one active process and switches playlists at a boundary, plan for supervision and process replacement explicitly. These are separate operating requirements, and the scheduler alone does not meet both.
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 choose a different playlist for each weekday by itself?
No. FFmpeg’s concat demuxer sequences the files named in a manifest, while an external scheduler or wrapper chooses which manifest to use. The official documentation reviewed for this workflow describes the concat demuxer, not a built-in calendar-based playlist selector.
Can I use -c copy for every playlist?
No. Stream copy depends on compatible input streams and on the output requirements. Check the streams, codecs and time bases across the files first; when they do not match, prepare compatible media or use a suitable re-encoding workflow.
Is one daily cron entry enough for a 24/7 live stream?
Not necessarily. A daily entry can trigger a wrapper, but it does not automatically stop an existing process, replace it cleanly or recover a failed broadcast. Continuous output needs a deliberate process supervision or wrapper design, plus tests of the day change and failure behaviour.
How do I avoid choosing the wrong manifest around midnight?
Use an explicit time zone for both the scheduler and the wrapper’s weekday calculation, and use absolute paths. Test the scheduled account’s environment and how the system handles daylight-saving transitions; cron’s exact behaviour should be checked against the manual for your Linux system.