Category: Technology

Posts that are tech related

Reusing a Desktop as a Home Console

With my move away from my older budget desktop build to my more recent Macbook Pro. I installed a fresh copy of Linux to keep it alive and spun up some local servers for the house; a couple of the servers I spun up are Home Assistant, and combined with some smart outlets, I could set up automation to control the outdoor lights.

Another server I host on my “new” Linux desktop is Plex, which hosts a local private “Netflix” you upload to create a personal library of movies, shows, and audiobooks. This was especially useful when I had dozens of DVDs that I could rip and upload to the MP4. Which I was able to automate using a cool tool called ARM (Automatic Ripping Machine)

Gaming on Linux

However, one utilization that I wanted to attempt was gaming. Notoriously, Linux does not support gaming, but with the Steam Deck being released a couple of years ago (essentially a Linux Nintendo Switch). Steam has forced many developers to port over to or allow virtualization on Linux.

One way on top of the games that natively support Linux is Proton. Proton is a “translation” layer that works with many games to patch the gap between Windows games and Linux. While not perfect, it is surprisingly well-compatible with most games. There’s a site called ProtonDB that checks specific games with community feedback and its ranking of how well they play on Linux, using Proton’s “translation.”

With Proton, I could play almost every game I own on Steam flawlessly, even though the game’s developers may not have explicitly outlined Linux support.

Splitscreen gaming

A big part of setting up this computer is its location. I placed it next to the living room TV console in hopes of somehow replacing the aging Xbox 360. But to fully replace the Xbox’s function, I need split-screen support with more than one player at once.

Already getting further than I thought I would, with most of my game library working flawlessly, is a lot, especially for Linux, which I’m not the most familiar with when it comes to “fixing” problems. But after some googling, I found a couple of options for the games I had.

Game 1 – Stardew Valley

One game that works out of the box is Stardew Valley, combined with a controller from 8BitDo and one from the Xbox 360 using an adapter. I could host a game and have both controllers work separately efficiently with the screen split side by side.

Game 2 – Halo

Halo Reach was by far the biggest game for our Xbox 360, making it a great game to try to replace the Xbox with. I got the Master Chief Collection, which includes all Halo Games released besides the latest (free) Halo Infinite.

One problem, however, with the Halo series on PC is the lack of multiplayer. Or instead, local multiplayer or split screen. I looked at several options and tried some Linux apps that enabled split screen, which was, in the end, not fruitful. I found an open-source mod on GitHub that installs fairly simply by dropping files next to the Halo game’s executable. This plugin enables an added menu to which you can open and add up to 8 players. Surprisingly, it performs smoothly out of the box, with each controller assigned to its respective players.

AlphaRing

Game 3 – Minecraft

I’m working through getting Minecraft running split-screen, which will be slightly tricky as there isn’t (to my knowledge) a way to get around having to run multiple instances of Minecraft. In contrast to the other games, it didn’t have to run the whole game for each person playing; instead, it was able to integrate additional tools to emulate another player to get around that.

Another way of making Minecraft more open for multiple other players at once is running a docker container that hosts a standard Minecraft server with the addition of “Geyser,” which, before I get into how that works, I need to explain a bit of the difference between Java Edition Minecraft and Bedrock.

Bedrock vs Java

Essentially, Minecraft has two flavors with completely different backends. The way Mojang (Minecraft’s owner) originally had it split is that all consoles and mobile devices run Bedrock edition, while Java Edition was first developed for Windows or Mac. It has changed since Minecraft’s early development but has continued mainly with that model, except for Bedrock on PC.

With the significant backend difference, there’s always been a barrier between Java and Bedrock players. There’s no easy way to connect to a Java server from Bedrock Minecraft and vice versa.

Bedrock + Java?

That’s where Geyser comes in, which, to my knowledge of how it functions, translates every “request” from the bedrock player to the Java Server in real time to allow connection between both players.

With an easy setup Docker image and Portainer, I was able to get the Java server running, to connect to it all I have to do is connect to the local IP 192.168.1.104:25565, and on the phone or console, I connect to the same IP but with the Bedrock Server port 192.168.1.104:19132.

I was not able to fully get this to work on bedrock, but there’s some troubleshooting I still need to figure out that may fix my problems. Overall a cool server plugin that I didn’t think would be possible, and shows how far the Minecraft community has come over the years. You can find the docker image here.

January 3, 2025
Creating Documentation for Projects
With taking on more projects that involve more than just myself, I’ve been working on writing documentation to share the knowledge around a project and store information with relevant tips to the project I’m working on.

While searching for a somewhat easy-to-configure, preferably free solution to documentation hosting, I came across Read the Docs. Read the Docs is a helpful ¹free hosting service that works with Github’s version control to create expansive documentation for projects.

To get started, you create a copy of their template on GitHub. Then, I used VSCode to clone the repo I just created from the template. Then, on the Read-the-Docs site, you add the repo to start the site building and set it! Read the Docs’ pages, which are written entirely in reStructuredText and similar to Markdown’s formatting. Coming from no experience, I found it relatively easy to learn, referencing the examples and documentation.

A cool feature is using the branching in Github to create versions of documentation and being able to use Githubs strong suit of version control to make sure if I make mistakes or edits I don’t like, I can quickly narrow down where its source is with the notes I added to each version change in Github.
1. The free tier is only available for community projects and is Ad-supported. Read more ↩︎
December 29, 2024
Learning through Self Implementation of Features
I recently covered FreeShow, a software made for presentations in Churches. One of the features that I liked and talked about was the open-source nature of the App. In this case, open-source means having the app’s code publicly available on GitHub, with any changes made, issues, or additions to its Codebase available to read / post.

Ditching Google for an Open Alternative

Blog post covering FreeShow

I noticed while poking around the GitHub page for FreeShow, is a large percentage of the code’s language is written in TypeScript.5

Typescript is similar to Javascript in that it adds to the existing framework of JS with additional checks like types, which ensures the data of a variable is the correct “type” it’s been told it is, making it easier to catch errors. I’ve been learning Javascript through Coursera’s Front-end Web Development course, and even though not explicitly teaching TypeScript, Typescript contains everything Javascript has, just with additional features, making it a more straightforward matter of learning those additional features rather than a whole new language.

With the knowledge of FreeShow’s codebase being primarily of a language I could understand, I decided to fork the repository (forking creates a copy of the repository, which is separated from the main code). I started looking through the code to see how it’s constructed and if I could implement my features into the app, that would be useful.

I also later found this page, which contains all the info they give to devs willing to contribute, like where they need help with apps and how their code is typically structured.

I started with one implementation I would find helpful: a way for the application to track when a song gets “used” and then, with that information, have it pull from the oldest used songs from the current date. The primary use case for this feature would be picking songs for Sunday’s service. The current way we do it with Google Slides is to attach an ID to each slideshow, and as the year goes by, eventually, it adds up to #100. In which case, we start over with Sunday #001’s songs. Making it impossible to select a song we sang last week.

Luckily, FreeShow already has a similar variable implemented to track when a song has been last used, called “used.” With that, I made a simple helper script that attaches to the existing “used” variable, “Chronicle.” Chronicle compares the used date with a reference date like Jan 01, 2024, and returns the day value of that comparison.
```
export function chronicleShow(timestamp: number) {
    const usedDate: number = new Date(timestamp).getTime();
    const chronicleRef: number = new Date('2024-01-01').getTime();

    const daysDifference = Math.floor((usedDate - chronicleRef) / (1000 * 60 * 60 * 24));

    //output example "044" (44th day from chronicleRef)
    return daysDifference.toString().padStart(3, '0');
}
```
In reality, this is a super simple script and hardly took any time, mostly being “inspired” by this post by Javatpoint. The more interesting part of adding a simple feature like this is digging through a full app’s code and figuring out what function is used for what. For example, finding where the “used” cache was getting updated was initially difficult. Still, eventually, I found it in a function called “update” because of a message that gets logged when opening a “show” item, and that message linked to the start of the trial to find the “used” cache update line.
December 21, 2024
Ditching Google for an Open Alternative
In the event of researching software for my church to help streamline the streaming process and slideshows. Initially utilizing less ideal software for A/V, I’ve found some fascinating tools that directly target my problems with the software we were using; whether directly targeting churches or not, I’ve come across many solutions.

The “it works” problem:

The existing setup we used before FreeShow was Google Slides, which was not the most glamorous software. It was the best free “software” for our use case and worked about 90% of the time. But it also had downsides, which made it more of a “workaround” than a proper solution.

One such problem was editing slides and keeping track of lyric edits. We generally follow this process for the order of Sunday slides:

Each song is imported from another Google Slides file. For example, if we were to sing “God Rest Ye Merry Gentlemen.” It would be pulled from another Google Slides file containing just that song and copied to Sunday’s Presentation.

The problem with this is whenever we edit a slideshow, i.e., the band plays it with one extra Chorus, a word is misspelled, a verse is missing, etc. That edit wouldn’t make it to the original song’s slide file. Then, the next time it’s used in a Sunday Presentation, it will not have the edits applied. While a minor problem, it still has an impact in the event of editing it last minute before service starts.

Another problem I had was with basic slide control. Arrow keys had to be used with the Google Slides window being selected, which I worked around with a hotkey that, when pressed, would switch windows to Chrome and hit the > arrow button. But that hotkey contained issues in the event of a second Chrome window being open, and the program couldn’t figure out which one to choose.

The Solution:

I first went to ProPresenter, probably the most popular presentation software on the market. With many organizations using Propresenter, like Bethel, Delta Airlines, NASA, and The White House, they have almost every integration one would ever need. With even support for SongSelect, which is what we have used in the past for getting song licenses/lyrics.

One problem, however, is cost. With the surplus of features comes the price of the program itself. Starting at ~290/yr, it isn’t exactly friendly for smaller churches. Also, considering Google Slides is free, it is hard to argue with something that has been working “fine” for the past few years. A couple of inconveniences don’t justify additional bills for the church.

That’s when I came across FreeShow, which, as the name implies, is a free slideshow software developed by the folks at ChurchApps. It is one type of software designed specifically for churches and contains features for everyday presentations. What makes the FreeShow free is partially due to its “crowdfunding” nature. Its code is open-sourced on Github, making it easier for other developers to contribute, make feature requests, and create bug reports.

What are the Features?

The features I’ve come to like about FreeShow, to name a few, are:
- Each song keeps its edits made previously
- Custom templates
- Quickly drag and drop the songs for Sunday from your database
- Browser connections, including remote control, highlighting tool, and virtually the whole show editor GUI, are accessible over the local network in any browser.
- Integration with Companion (another super cool software for Stream Deck)
- Cloud backup with syncing across computers
- A quickly accessible Media tab with free images/videos
Features that FreeShow advertises

Another big plus for me is how often the app gets updated. While that means frequent updating can be annoying, new features and bug fixes are pushed more often. The developers are active in the Issues tab, responding to my submitted issue within a day or so.

Lurking issues:

But that brings up the topic of issues; being an open-source donation-funded program, it comes with bugs. Most of the things I’ve come across are slight lags, editing not working at times, performance problems, and media 404’ng, which causes blank backgrounds. Some are acceptable, and a software restart will usually amend it, while others are (from what I can tell) compatibility problems with MacOS/Windows, as I don’t usually have the same issues occurring on both computers.

One such issue I recently encountered is that the media is not loading. Looking at the console, it ends up reporting a “cannot reach” error to the image URL. This error appears especially when syncing across computers; it’s only recently and has not been reported.

I’m excited to see where it goes, as the updates are relatively frequent. A benefit of the open-source nature is I can fork it, download it, and mess with any part of the application, and it’s written in 50% TSX, which I’ve been working through with Coursera’s Frontend Course.

One example of a feature I’m trying to implement for myself is chronicling, a modification of the existing “Used” feature that tracks the last date it was used in a slideshow. Chronicling will be a way to track each show by a unique number, which will change by the date it’s used. With that, I want to implement a way to choose the oldest number based on the current date, eventually making a way of automating the song selection process for each Sunday. One button will grab ~6 of the oldest songs used and place them into the current show.

In summary, FreeShow is a promising application that’s been a massive upgrade from what we had used. Being a newer application, it suffers from bugs but is regularly updated with fixes and what seems to be an active developer community.

*You can support FreeShow and ChurchApp’s other programs by donating on their GitHub Sponsor page.

All rights to ChurchApps and FreeShow belong exclusively to them. I’m not sponsored by them, endorsed by them, or in any way officially linked to their software*
December 13, 2024