“Playlist rotation” can mean either replaying one YouTube playlist from its beginning or switching between different playlists at chosen times. A Raspberry Pi can display an embedded playlist in kiosk mode; timed changes between playlists need a separate scheduling layer on the Pi.
The distinction matters because YouTube’s player parameters can select a playlist and repeat it, but they do not set a timetable. Raspberry Pi’s official kiosk tutorial shows how to start Chromium and switch browser tabs; it does not verify a recipe for changing playlist URLs at particular times.
Decide what “rotation” means
If you have one playlist that should keep playing, the simplest approach is an embedded YouTube player configured to play the playlist and repeat it. When the final item ends, the playlist returns to its first video. This is repeat-one-playlist behaviour: it does not select a different playlist at breakfast, midday or evening.
Timed switching is a different job. Imagine a devotional channel that wants morning bhajans, a daytime playlist and evening aarti. The player can load and repeat each playlist, but something else must decide when to replace the current playlist URL. On a Pi kiosk, that “something else” is a local scheduling layer, such as a script or a page designed to change the embed. The mechanics depend on the installed operating system and desktop session.
| Need | What the player does | What the Pi must do |
|---|---|---|
| Keep one playlist repeating | Loads the playlist and repeats it when it finishes | Open the player at startup and keep the display running |
| Change playlists at set times | Plays the playlist currently specified in the URL | Select and load the appropriate playlist URL on a timetable |
| Show different pages in rotation | Plays each embedded playlist when its page is open | Switch browser tabs or pages; this is not the same as changing a playlist inside one player |
For a fixed devotional or ambience display, repeating one carefully arranged playlist may be enough. If programme changes need to follow a clock, plan and test the scheduler as a separate component rather than assuming that loop=1 covers it. For a broader comparison of approaches to playlist rotation in a live broadcast, see OBS and FFmpeg scheduling options. That is a different kind of setup from displaying an embedded player in a browser kiosk, so use it for context rather than as a Pi timer recipe.
Find the YouTube playlist ID
Open the playlist on YouTube and inspect its URL. A playlist URL commonly contains a list parameter; the value after list= is the playlist ID. Copy the ID for the playlist you actually want to show, not the ID of one video within it. Google for Developers’ YouTube player parameter reference uses an example playlist ID beginning with PL and explains how the embedded player accepts a playlist.
For instance, if the playlist page URL ends with list=PLexample123, the value to use in the embed is PLexample123. That is only an illustration of where the ID goes, not a real playlist. Keep the ID intact when copying it: do not include the list= label, an ampersand after it, or unrelated URL parameters.
Check that the playlist is accessible in the context where the kiosk will use it. A playlist or video with access restrictions may not behave as expected on a public display. Test the playlist in an ordinary browser before relying on the Pi, and check YouTube’s current guidance if you are uncertain about its visibility or embedding settings.
If you plan to change playlists by schedule, make a clear mapping outside the player URL: for example, “morning” corresponds to one playlist ID and “evening” to another. Give the labels and IDs an owner and a review process. A mistyped ID can leave the display on the wrong material or show an error, while a correct ID loaded at the wrong time points to a scheduling problem, not a player parameter problem.
Build the embedded player URL
The basic playlist embed URL is:
https://www.youtube.com/embed?listType=playlist&list=PLAYLIST_ID&autoplay=1&loop=1
Replace PLAYLIST_ID with the copied ID. The listType=playlist parameter tells the player that the list value is a playlist. Google’s documentation says a video ID is unnecessary when both playlist parameters are specified. The player can therefore load the playlist directly without first naming an individual video.
You can put this URL in a browser for a quick check, or use it as the source for an iframe in a simple HTML page. A direct URL keeps the test small: if the playlist does not load, you have fewer surrounding page elements to investigate. A custom page takes more preparation but gives you a place to add a label, a background, or other display layout. The player itself still follows the URL parameters in either case.
If you wrap the player in a page, leave enough room for it. Google states that an embedded player must have a viewport of at least 200 by 200 pixels and recommends a 16:9 player at least 480 pixels wide and 270 pixels tall. Those are player viewport recommendations, not a guarantee that every monitor or layout will make the video look right. Check the actual kiosk screen, including whether browser chrome or page margins reduce the visible area.
A simple page should do little more than present the player reliably. Extra controls or layout elements can be useful, but they also create more points to check when the kiosk starts. If you need the display to fit a particular screen, test the page at the Pi’s chosen resolution rather than judging it on a development computer.
Set the parameters and test playback
The two parameters that define the basic behaviour are loop=1 and autoplay=1. For a playlist player, the documented loop behaviour is to play the entire playlist and then return to its first video. It does not restart only the current video, and it does not move to a separate playlist at a specified hour. autoplay=1 asks the player to start the initial video when it loads.
Test the URL before putting it into startup. Confirm that the intended playlist opens, that it advances through the content, and that the end of the playlist returns to its beginning. Then reload the page and check whether autoplay starts as expected in the browser you plan to use. Browser behaviour and playback conditions can differ, so a successful test on another machine is not enough evidence that the Pi kiosk will behave identically.
There is an important public-display caveat. Google says that autoplay causes playback data collection and sharing when the page loads. YouTube Help also says that views of embedded videos that autoplay do not increment views. Do not use an unattended autoplay display as a way to generate view counts; review YouTube Help on embedded autoplay and the current player documentation when deciding how the display should operate.
If autoplay is not suitable for your display or viewing context, you can omit it and test what a visitor sees before interaction. That changes the start behaviour, not the playlist’s repeat logic. Keep the distinction explicit in your notes: loop=1 controls what happens after the playlist ends, while autoplay=1 concerns how playback begins after the player loads.
Run the player in a Pi kiosk setup
Raspberry Pi’s official kiosk tutorial describes a graphical kiosk on Raspberry Pi OS 64-bit. It uses the desktop’s .config/labwc/autostart file to open Chromium in kiosk mode when the desktop starts. Its example opens two URLs as tabs and runs a script that switches tabs periodically. That gives you a documented pattern for launching a browser display at startup, but it is not a tutorial for changing a YouTube playlist according to a daily timetable.
The tutorial’s stated baseline is a Raspberry Pi 3 or newer with at least 1 GB of RAM for a graphical browser kiosk. It also lists a Pi, suitable power supply, microSD card, display cable and monitor as supplies. Treat those as the tutorial’s setup baseline, not a promise of smooth playback for every resolution, playlist or video. A Raspberry Pi setup guide to a YouTube stream over Airtel Xstream may help if your wider project involves network connectivity, but a browser kiosk and a live-streaming broadcast are not the same use case.
To adapt the kiosk pattern, first get the desktop to open Chromium at the intended player page after a clean restart. Confirm the display goes into kiosk mode, the page fits, and the player behaves as expected after a network interruption or browser restart. These tests matter because a URL that works when entered manually may not be reached in the same way at startup.
A microSD card is a reasonable item to consider when assembling a Pi kiosk from scratch, but do not choose capacity or speed by guesswork. Raspberry Pi’s getting-started documentation says most models use microSD as boot media, while some models support other storage. Check your own Pi model and workload. The display connection and power supply likewise need to match the particular board and monitor.
Add the separate scheduling layer carefully
For clock-based changes, the Pi needs a process that knows the desired playlist at a given time and causes Chromium to load that playlist’s URL. There are two broad implementation shapes: a local timer or script that selects a URL and reloads the browser, or a browser page that changes the embedded player’s URL itself. These are design alternatives, not approaches ranked by the official sources cited here.
The reviewed Raspberry Pi tutorial demonstrates periodic tab switching, not time-of-day playlist replacement. Do not treat its tab-switching example as evidence for a cron or systemd timer configuration. A calendar-based scheduler must match the Pi OS release, graphical session, browser launch method and the way the page is opened. Those details can change between installations, which is why an untested command copied from elsewhere is a poor foundation for an always-on screen.
Before implementing a schedule, write down the expected transitions in plain language. For example: “At the start of the evening programme, replace the daytime playlist with the evening playlist; after that, repeat the evening playlist until the next planned change.” This exposes decisions that a timer alone cannot make: what should happen after a reboot, whether a missed transition should be applied immediately, and what playlist should be used if the schedule cannot be read.
Then test each transition on the actual Pi and session that will run the display. Check both the normal change and recovery cases, such as restarting the desktop near a transition or briefly losing network access. Keep a manual way to return to a known URL. Record which playlist IDs correspond to each programme, and revise that record when playlist contents or IDs change.
If maintaining a local desktop, browser startup, playback checks and clock-based switching is more work than the display warrants, simplify the requirement where possible: a single playlist on repeat removes the schedule altogether. For a different use case—turning an uploaded file into a 24/7 YouTube live broadcast rather than displaying an embedded player on a Pi—StreamNeo removes the need to keep your own computer switched on to maintain that broadcast. It does not turn the embedded-player parameters into a timetable, and it is YouTube-only.
Keep the Pi reliable overnight
A kiosk that looks correct at setup time still needs a practical recovery plan. Decide what you will inspect if the screen is blank in the morning: power, network, desktop session, Chromium, the page, or the player. A visible fault is easier to diagnose when you can check each layer separately rather than treating “the playlist stopped” as one undifferentiated problem.
Give the Pi a stable location and a power supply suitable for the board. Check that the network connection reaches the screen reliably; a playlist player depends on YouTube being reachable and on the content being available. If your project is a public devotional or music broadcast rather than a browser display, this guide to looping a video on YouTube Live with FFmpeg covers a different broadcast workflow. Do not confuse keeping a kiosk page open with sending a live stream to a YouTube channel.
A scheduled change also needs a fallback. Choose what the display should do when a new playlist cannot load: remain on the current page, show a simple notice, or return to a known playlist. Whatever you choose, test it. Avoid relying on an operator being present at the exact transition unless that is genuinely part of the plan.
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 loop=1 switch playlists at a set time?
No. With a playlist embed, loop=1 repeats the entire playlist after it finishes. A separate mechanism must select and load another playlist URL when you want a clock-based change.
Can I use the Pi kiosk tutorial as a scheduler guide?
Use it for the documented desktop-startup and Chromium kiosk pattern, and note that its sample switches browser tabs. It does not verify a cron or systemd recipe for time-of-day playlist changes, so test any scheduling implementation against your own Pi OS release and graphical session.
Is a playlist ID the same as a video ID?
No. The playlist ID is the value associated with list on the playlist URL. In the documented embed, listType=playlist and list=PLAYLIST_ID identify the playlist, so a video ID is not required when both playlist parameters are present.
Will autoplayed embedded videos count as views?
YouTube Help says autoplayed embedded videos do not increment views. Google also notes that autoplay involves playback data collection and sharing on page load, so check the current official guidance before using autoplay on a public or unattended display.