Python YouTube Auto-Uploader for Windows: Code Errors and OAuth Setup

The most important thing to know is that the script as printed in that tutorial will not run. Several of its names don't match each other. Treat the tutorial as a design outline rather than copy-and-paste code, and read the rest with that in mind.

What the tool is meant to do​

The design is simple. You drop a finished video into an input folder. The script then does the following:

• It checks the folder every 30 seconds.
• It waits until the file's size and modification time have been unchanged for two minutes, so it doesn't grab a file that is still being copied.
• It signs in to YouTube using permissions you granted earlier.
• It uploads the video in 16 MiB chunks as a private video, using the file name as the title.
• It moves successful files to an uploaded folder.
• It moves files YouTube rejects outright to a failed folder, with the reason in a log.

The tutorial is open about its limits. There are no descriptions, tags, thumbnails, playlists or email alerts. You finish those in YouTube Studio. It also notes that problems that only appear during YouTube's later processing won't show up in the script's log, so you still need to check Studio.

The code problems​

Going by the code as published, these are the defects:

• Mismatched names. Settings are defined as DONE_AFTER, BLOCK_SIZE and SHORT_TRIALS, but the code later uses READY_AFTER, CHUNKS and SHORT_ATTEMPTS.
• State variables. STATE and STATUS are mixed up, and state and status are used inconsistently.
• Function names. A function called get_status() is defined, but the code calls get_upload_status().
• Login command. The login branch calls log in() instead of the defined log_in().
• Exception names. TemporaryError and Temporary_Error are used, but the class is named Temporary.
• Folder names. The code creates input, uploaded and failed, yet the prose tells you to copy files into incoming. A video placed in the wrong folder will simply sit there. The Docker example expects input.

These would stop the script from working, so a corrected and tested version is a prerequisite. Don't assume the intended behaviour, such as restart-safe resumption through state.json, works in the published code.

What Google's documentation confirms​

The design is sound even if the listing isn't. Google's YouTube Data API documentation backs up the main building blocks.

• Authorization. Uploading needs OAuth 2.0 rather than an API key. A Google Cloud project with an External consent screen in "Testing" gets refresh tokens that expire in 7 days, unless the only scopes requested are basic name, email and profile scopes. The uploader requests youtube.upload, so the limit applies. Re-running python uploader.py login (once the code is fixed) re-authorizes it. Videos already uploaded are unaffected.
• Scope wording. Google describes the youtube.upload scope as "Manage your YouTube videos." The tutorial says the script can only upload and can't delete anything. That is narrower than the full account scopes, but check the consent screen yourself and protect the token regardless.
• Resumable uploads. The protocol lets a client save a session URI, check progress after an interruption and continue from the byte the server reports. Session URIs expire. After an expiry the server returns a 404 and the upload must start again from the beginning. Resumption is therefore likely, but not guaranteed.
• Limits. The videos.insert reference lists a 256 GB maximum file size. It also lists a quota cost of 1 unit in the Video Uploads bucket and "100 calls per day". Treat that as an API limit rather than a promise of 100 successful uploads.

Test mode or production mode​

The tutorial offers two paths. In test mode, you add your own account as a test user and re-authorize every week. In production mode, you publish the app, which on the current Google console means supplying a homepage and a privacy policy URL under Branding.

Third-party summaries agree on the tradeoff. Production tokens generally don't expire, unless they are revoked or go unused for a long time, typically six months. A Google developer page on its Health API describes this the same way. One GitHub write-up notes that tokens issued during Testing keep their 7-day clock after you switch, so you need to re-run consent once you're in production.

Three caveats:

• Google's help pages say apps in production may need verification for sensitive or restricted scopes. The tutorial's claim that a purely personal app usually doesn't need full verification is the author's experience, not something I could confirm in Google's documentation.
• The privacy policy and homepage requirements are console behaviour that can change. Check the live screens.
• The API reference says that videos uploaded from unverified API projects are not restricted to private viewing. The script sets the visibility to private itself, so the privacy of your uploads comes from its own settings.

Windows setup, as described​

The Windows steps are ordinary:

1. Show file extensions in File Explorer so you don't end up with uploader.py.txt.
2. Install Python using the Python Install Manager, from the Microsoft Store or python.org, then run py install default.
3. Create a project folder, for example C:\YouTube-Uploader, and a virtual environment with python -m venv .venv.
4. Install google-api-python-client and google-auth-oauthlib inside the virtual environment.
5. Put the downloaded client_secret…json file next to the script and run the login command once. This creates token.json.
6. Start the watcher, drop a short test clip into the correct folder, and wait out the two-minute stability window.
7. For autostart, create a .bat file that runs the script, make a shortcut to it, and place the shortcut in the shell:startup folder. Set the shortcut to run minimized.

Autostart is limited. The PC must be on, awake and signed in, because a Startup shortcut runs at user logon, not at boot. It is not a Windows service. The tutorial says Windows 10 still works for this but receives security updates only under certain conditions. Check your own edition's eligibility in Microsoft's current guidance.

Running it on a NAS​

For around-the-clock operation, the tutorial runs the script in a python:3.13-slim container on a Synology NAS using Container Manager. It mounts a shared folder containing uploader.py and token.json. You reuse the token created on your PC, so you don't repeat the Google setup. The UID/GID (1026:100) and the /volume1/... path in its example are examples only. Replace them with your own values, which you can find with the id command over SSH.

Securing the token​

The client secret file doesn't grant channel access on its own. token.json does. If you copy it to a NAS share, keep these points in mind:

• Restrict access to that share to your own account.
• Never put the token in a public repository or sync it to shared storage.
• If it leaks, revoke the app's access from your Google Account's permissions page.
• Don't run the PC and NAS copies at the same time on the same folder.

Verdict​

The idea is sound. Resumable chunked uploads, private-by-default publishing and a hands-off folder watcher all match how Google's API is documented. The weak point is the published code, which needs fixing and a test run with a small file before you rely on it. Use a corrected script, accept the weekly re-login if you stay in test mode, and guard token.json carefully.