#vodbot

[notquiteapex]

[notquiteapex]

My stream group is celebrating 2 years of streaming today! it's been a wild ride, but our editor @alchana put together this awesome clip compilation of the past year's streams.

My boyfriend and I also put together the credits animation below, to thank all our followers for watching.

Happy 2 whole years everybody! (reblogs are appreciated!)

[notquiteapex]

VodBot, and taking off the training wheels.

Part 2 of a series on my own little command line application, VodBot. This one will be much longer than the first! You can read part one here. The images in this part were done in MS Paint because I'm currently stuck in an airport!

So last we left off, VodBot was in it's shelling out stage. It was able to process data from Twitch's servers and on the local disk and figure out what videos were missing, but it left the biggest function of actually obtaining that footage to the more mature programs. In addition, VodBot didn't help all that much with actually slicing up videos in prep for archival on YouTube, and lastly actually uploading to the archive channel on YouTube. These two things needed to change, for the sake of maintaining the project into the future, and also for me to keep my sanity.

Fun fact, Twitch uses the same API that's exposed to developers to build the entire website, and it's pretty well documented what OAuth Secret and ID they use, since you can easily find it in the HTML of any Twitch page. In case you don't know, an OAuth Secret and ID is essentially a password and username of a "user". No this does not mean you can easily access anyone's info, channel, etc. because this ID and Secret have limited functions, used only for making the site function on a web browser. In fact, VodBot has its own ID and Secret which are not available, because they're meant to be a secret unless you properly manage its permissions, which I have not (yet). Anyways, the way this little faux-login is used is to access Twitch's database of video data and metadata. It uses a special system called GraphQL, you don't need the details on it for this though. Whenever you pull up a video on your browser on Twitch's site, the ID and Secret are used to log in to this GraphQL database, and pull the relevant data to have it display video on your screen.

Streams on Twitch, when being watched after the stream is over, are sent in 15 second chunks. This is how many video platforms send video dynamically to your browser, allowing video to load while you watch! It's not always 15 seconds, it varies between platforms like Netflix, YouTube, Twitch, Amazon, etc. The database returns two important bits, first up is all the info on the video segments that Twitch has for a specific video. The other bit, is just all the 15 second video files that Twitch sends to your browser. VodBot is now able to save all these by itself without an extra program, but still requires ffmpeg to stitch it all together as these 15 second video clips use a special protocol and its not as easy as simply opening a file and writing the contents of each 15 seconds one after another.

Once ffmpeg does it's job, VodBot moves the video out to a proper archival location and removes the old metadata and all the 15 second video clips it pulled from Twitch's database. A major issue with this whole implementation is that Twitch, at any moment, can easily change out the ID and Secret, meaning all the apps that rely on it can break. Although it's not currently implemented, it wouldn't be difficult to have VodBot's main configuration file contain the current values and allow them to be changed in case Twitch breaks something.

Next, since we already require VodBot to have ffmpeg, we can use the method I talked about last time to slice videos and prep them for upload. Problem is, we have a lot of functions we need to make accessible from a simple command line interface, so I had to begin thinking about how to organize VodBot's functions.

I kept it simple enough. Want to download videos? Run `vodbot pull` and VodBot will do all the hard work and download any videos you don't have. You can give it the keywords `vods` or `clips` and it'll pull what you need, and soon giving it a specific video ID will download it too. Want to prepare videos to be sliced or uploaded? Run `vodbot stage add` with the appropriate identifier and VodBot will ask a series of questions about what the video title, description, and relevant timestamps of the VOD or clip to prepare it for upload to YouTube. Running `vodbot stage list` will also list the current videos in queue to upload, along with `vodbot stage rm` to remove them from the stage. Vodbot can output these videos with the appropriate information with `vodbot slice` and the appropriate stage ID, or just `all` with a specific file or folder location respectively. Lastly, `vodbot upload all` uploads all of the stage queue to YouTube, provided you are logged in. You can also just give a specific ID in place of `all` to upload a specific video.

All of these commands have a purpose, or have sub-commands that do something related to each other. Pull and upload also have aliases named download and push respectively, in case you like having either style. Personally I like the git style, but download and upload are a bit more descriptive.

That's all for now, next time we'll actually get to how Google handles it's exposed API and how it's pretty messy.

For now though, if you'd like to support me, you can follow me on Twitter, Twitch, or buy me a ko-fi!

[notquiteapex]

VodBot, the bestest little helper I ever did make.

Part 1 of... a number of posts! Everyone say hi and be nice to VodBot on GitHub.

January of 2020 rolls around, everyone’s excited for the new year of perfect eyesight. And then, the funniest thing happened…

Because of the world’s state of affairs leading into March 2020 I decided I should get some new hobbies. I bought my first 3D printer, an Ender 3 Pro, on eBay for just under $200 and it’s been weirdly enough one of my better financial decisions. I also began streaming on Twitch.tv in earnest around this time, and I had a goal to reach Affiliate status in just a few months (Twitch Affiliates are able to earn money from their streams through ads, bits, subscriptions, etc). In less than a month, through asking my friends to advertise my stream and constantly trying to put myself out there (probably breaking some community rules in the process, oops) I became an Affiliate and streaming sort of became a part-time-job-hobby! It was a lot of fun, and I’ve been streaming pretty regularly ever since.

Around October of 2020, I realized I kind of wanted to archive my streams somewhere for safe keeping. The best place to store lots of video data for literally no cost? YouTube of course! You can check out our existing archive channel which also links to all our Twitch pages here! I got to work, once a week I went to Twitch’s video manager page and had it queue up a download of my latest stream for me. I would slice it into different parts based on the games I played, which I had to get timestamps for manually. As you can imagine, this is pretty time consuming and boring. Not only that, but my friends also began streaming and some became affiliates around the same time, and getting them to do this task too wasn’t gonna be easy. So how do I make this task easier? Well, for starters, snakes. Let’s tangent!

Python is a wonderful programming language, it’s often one of the first languages that absolute beginners use because it’s grammar and functions are super easy to understand and use. It doesn’t have any sort of compile time, and is dynamically typed, meaning you don’t need to worry about waiting for anything. It also has thousands of pre-made libraries to make whatever task you’re trying to do so much easier. Lastly, Python also has the ability to send commands to other programs on the same machine, with relative ease.

VodBot’s first version was rather simple, it was made with Python. Use existing Python libraries to send some data to some URLs hosted by Twitch.tv to get info on previous streams (called Video-On-Demand, or VODs for short) and clips (slices of video made by viewers of fun moments on streams). It would do this through the Representational State Transfer Application Programming Interface, or REST API for short. Then, do some basic combing of this data to make sure that these videos weren’t already on the host system, and then pass the URLs for these streams to other programs like youtube-dl or streamlink to download the videos to the host system. Oh, also make a small file containing relevant metadata for the stream such as the title, the game, when it was streamed, etc. VodBot “shelled-out” these commands quickly to the other programs and let them do all the heavy lifting, which was just fine. I still had to slice up the video’s by hand, but it wasn’t too bad now that I could pull the videos down faster and leave this little script running in the background while I worked on schoolwork. Heck, I even learned that the program that youtube-dl and streamlink shelled-out to itself was the very capable ffmpeg, which I began to use to slice my videos much quicker without the overhead of a full video editor program.

Of course, this got old pretty quick too. Why can’t I automate this any further? What prevented me from simply queuing up these long videos and sending the relevant slices up to YouTube directly for me? Well, it turns out, not a lot! I'll talk about this more in the next part...

[notquiteapex]

VodBot, and the mess that is Google (and their API, which is also a mess).

Part 3 is finally here. Took me a while to get to, and a while to actually put into words in a document, and also pen to tablet. You can check out the code on GitHub.

So last time we left off, VodBot was independent. The only requirement in terms of extra programs was ffmpeg, which is a good program to have anyway. Otherwise, Python's package manager pip handles everything necessary. This is wonderful for maintainability, if there's an issue with a package it's easy to find the issue page, and if there's a problem with ffmpeg then there's probably some major infrastructure failing elsewhere.

So VodBot could download videos, and store some useful metadata. A good start, but what to do with it? Having slicing, splicing, and uploading all done automatically would be ideal, just give it some parameters for each and its off to the races. Luckily, the staging and exporting system already exists, so it's just a matter of uploading from the temporary directory VodBot uses! In addition, Google provides an example of how to programmatically upload to their services here. It's almost as simple as copy paste! Well, not quite...

Google requires you to sign up for a developer account and register your app with specific permissions and services. This is pretty expected these days, not every app needs access to every service provided under a company's API, especially if said access gets compromised somehow. What the example fails to explain is that you need some specific info (fun fact, it's more OAuth credentials!), and how you're supposed to get it for specific use cases (in this case, a console application with no GUI or window environment). I got to spend two weeks trying to figure out why VodBot wasn't getting the proper permissions, because the files required just weren't on my system or being pointed to anywhere.

After that debacle was sorted, the uploading example worked without a hitch, and was integrated as its own command very easily. Now for the next problem: extending the code and making it my own. The example is incredibly detailed, and provides a lot of failsafes which is fantastic, but unfortunately the rest of the documentation is not documented anywhere on Google's main sites. What's worse, the library for Python does not contain data structures that are fully defined and fleshed out prior to runtime. In layman's terms, I don't know what a specific function will give back and that makes it difficult to add additional features on top of what the example provides.

My favorite interpretation of Google's attitude of how it handles it's API can be handled by this ex-employee's own artistic expression. (Credit to Goomics, #50)

Plenty of old examples existed online for how to handle this kind of stuff, and very very few modern examples existed for some help. I was lucky I didn't want to add more than an indication of upload progress to print outs. Heck, I don't know if the example for uploading to YouTube will still be up in a few years. I can hope.

Back to VodBot: Google allows users to upload videos completely for free, at the cost of a quota. Each method used to query and upload data to any of Google's services has this cost of quota, preventing any one person from just spamming services with garbage without any roadblocks. The main two quota costs that VodBot has are querying existing videos (which is required to be known to upload new videos because... reasons? It's useful, but there's no reason for VodBot to currently have that info, making the query feel wasteful but unavoidable because of API design) and uploading new videos. Getting existing videos costs practically nothing with the testing quota each new developer account is given, but uploads cost a lot. In addition, videos can only be uploaded and set to private when uploaded programmatically, and cannot be set to public.

In order to get more quota and allow for public uploads, Google has to "audit" your program. Basically, you get to fill out a long form saying what your intent is and what your program does and how it is meant to be interfaced with. You have to upload a video of you using the program with voiceover. Gotta wonder what that Google employee thought of my mic quality and sound.

After the form, you'll be contacted by Google over email to answer any remaining questions. This ended up being the same questions that I answered in the form. I sent them my recording and voiceover again and answered use cases, etc. They didn't even watch them until I had pointed out that I had sent them the video multiple times. They repeated questions, contacted me for weeks and weeks threatening to close my audit and deny me access because they didn't read my responses. I get that I can write a lot, but jeez!

Once that finally got sorted, the VodBot project on my Google Dev account was given unrestricted access to YouTube and it's API. VodBot did not have to make any changes locally to upload with this new permission, it was all done on Google's side. Great! Just one problem...

Because VodBot is written in Python, and it's open source, there is no easy way to obfuscate the sensitive OAuth information VodBot needs to log in to YouTube and upload. Releasing these files is dangerous, and if the wrong hands get it, then people who want to use VodBot are stuck waiting until quota frees up to be able to upload. Plus, it has to be in a file, Google's API will not read it otherwise because... reasons. Even the amount of quota I got was not useable on a scale larger than one person uploading eight videos a day. I don't upload eight a day, but someone might! Google also displays a big red warning against using VodBot because it's not audited for use outside my personal "company". I've tried applying for it, but there's a bunch of info that's just a repeat of the first audit, and I don't want to bother right now.

If VodBot was compiled in, say, Rust or C++ this would not be as big of an issue. Executable files are obfuscation all on their own, because who wants to look through a bunch of unrecognizable symbols? Unfortunately, until I switch over, this problem is here to stay. Maybe some day there will be a proper solution, but right now VodBot's upload function is locked behind the requirement of being a person I can trust.

As always, you can support me in a bunch of ways if you enjoy what I do. My support links are always at the top of my website or you can just share my posts and projects with people you think might enjoy them. Thanks for all the reading!

[notquiteapex]

This weekend I came home to relax after a hellish week and to be with family for the holidays. Today I didn't have much to do so I spent the time upgrading my home server, and this is what the old parts are as well as the new parts.

All images in this post include alt text.

Above is my old GT 530, an Old Nvidia card from May 2011. I got this from a friend on the Nintendo Homebrew Discord when I was first beginning to build my first PC. This thing ran hot and loud because of its cooler design. It was extremely power inefficient, but does not have any external power plugs like most modern GPUs do. It is no longer in the server, as the server now has an integrated graphics processor from the new CPU. It has only 1GB of GDDR3, practically nothing compared to what modern GPU's have, but I only used it for the required display output (otherwise the server would not boot).

Above is the old CPU and motherboard (mobo). It's an MSI Z170A Gaming M3, it came bundled with the DEEP COOL CPU cooler for free off eBay back in 2019. The CPU itself is an Intel i7-6700, which a family member gave to me, having 4 cores 8 threads, 3.4 GHz, and 8 MB of cache. There was originallcy an old Intel Celeron in it, don't remember what though. The top PCIe 16x slot is broken off, I plan to attempt to remove the solder and pins on it, install a new PCIe bracket, and give the hardware to someone who needs it more than me rather than just throw it away.

Here is the mess of cables that is front half of the server. I 3D printed an open air bed for the motherboard back when I first built the machine. On the other side is the power supply, hard drive slots, and a network switch. There is currently only a 256GB NVME for the Ubuntu Server image, 6TB HDD for mass storage (two partitions, redundant) and a 1TB SSD (not in use) connected. This is what VodBot writes to, to archive VODs and Clips. I plan to get a bigger HDD and run ZFS on it with the 1TB SSD used as a caching layer. There is a fan to cool the drive, as spinning plates of iron can get hot. There is also a Raspberry Pi 4 2GB which acts as a PiKVM to interface with the server in case the network interface on the server breaks (which happens a lot more than it should). It uses a cheap $15 HDMI-USB capture card to allow me to see the main terminal remotely. The power supply (a cheap, old EVGA 500W 80+ PSU) also had some work done to it to provide a 2.1mm power jack for the 3.3V and 5V rails.

New specs of the new parts are as follows. CPU is a Ryzen 7 5700G, which is an AMD CPU + integrated Radeon GPU, 8 cores 16 threads, 3.8 GHz and 16 MB of cache (and a butt load of instructions per clock cycle improvements). Cooler is just the AMD Wraith Stealth. Mobo is a Gigabyte B450 Gaming X, my old board before I upgraded to X570. Ram is 4x8GB (total 32GB), running at 3200 MHz CL16, some variant of Ripjaws brand. You can easily see the PiKVM is connected to the board's power and reset switch pins, along with the LED pins.