The rapid advancement in Large Language Models (LLMs) has been truly astounding, bringing powerful AI capabilities to the forefront. However, many of these cutting-edge models often demand significant computational resources, particularly modern GPUs with substantial VRAM. This can be a barrier for enthusiasts and developers working with older or more modest hardware.

This post explores the feasibility and approaches to running recent LLMs, specifically Qwen3.5 and Gemma4, on older hardware. While it won’t be a seamless experience akin to state-of-the-art systems, with the right strategies, you can still leverage these models for various tasks.

Challenges of Old Hardware

Older hardware, typically characterized by:

• Less VRAM/RAM: Limits the size of models that can be loaded.
• Slower CPU/GPU: Increases inference time significantly.
• Older Architectures: May lack specific instruction sets or optimizations present in newer hardware.

Strategies for Running LLMs on Old Hardware

To mitigate these challenges, several techniques can be employed:

1. Quantization

Quantization is perhaps the most crucial technique. It involves reducing the precision of the model’s weights (e.g., from FP16/BF16 to INT8, INT4, or even binary). This dramatically reduces the model’s memory footprint and can also speed up inference, sometimes at the cost of a slight reduction in accuracy.

• Tools: Platforms like Ollama simplify running quantized models. Other libraries like bitsandbytes and quanto are also excellent. These often support various quantization formats (e.g., GGUF, AWQ, GPTQ).

2. Smaller Model Variants

Many popular LLMs, including Qwen and Gemma, are released in multiple sizes (e.g., 7B, 2B, etc.). Opting for the smallest available variant that still meets your needs is a straightforward way to reduce resource demands.

3. CPU Inference

If your older GPU has insufficient VRAM, running inference entirely on the CPU is an option. While slower, even old CPUs can still handle smaller quantized models. In my case, my old Unraid server has a decade old CPU: Intel® Xeon® CPU E5-2620 0 @ 2.00GHz

• Tools: Ollama provides an easy way to run models on CPU, leveraging underlying optimizations for efficient CPU inference and multiple CPU cores.

4. Batching and Optimizations

For specific use cases, optimizations like:

• Batching: Processing multiple prompts at once can improve GPU utilization, but increases VRAM.
• FlashAttention: If your GPU supports it, FlashAttention can reduce VRAM usage during the attention mechanism. (Less likely on very old hardware, but worth checking.)

Case Study: The Challenge with Qwen 3.5

An interesting challenge arose when attempting to run Qwen 3.5. Unlike previous models, the latest Qwen is a Mixture of Experts (MoE) model. This advanced architecture relies on newer technologies, specifically “Flash Attention,” for efficient operation.

Unfortunately, older GPUs like the AMD RX590 lack hardware support for Flash Attention. This incompatibility leads to a critical failure during inference. When attempting to run Qwen 3.5 on either the RX590 or the CPU-only server, the result was the same: a continuous stream of nonsensical, garbage text that would not stop.

On the other hand, an older Qwen 2.5 model works fine on such an old GPU:

This highlights a key takeaway: as LLM architectures evolve, they may introduce dependencies on specific hardware features, making them incompatible with older systems, even with techniques like quantization.

Case Study: Gemma4 on Old Hardware

Gemma, being a more recent and efficient model family from Google, is a good candidate for older hardware due to its design. Its smaller variants and optimized architecture make it more accessible.

Scenario 1: Gemma4:e2b on Ubuntu 24.04 with AMD RX590 (8GB VRAM)

This scenario involves using a mid-range, older AMD GPU. The key considerations here are:

• Model Variant: gemma4:e2b likely refers to an optimized 2-billion parameter model. This size is highly suitable for an 8GB VRAM GPU, especially when quantized.
• Quantization: For optimal performance and VRAM fit, aim for 4-bit (Q4) or 5-bit (Q5) quantization. This allows the model to comfortably reside in the 8GB VRAM.
• Frameworks: Ollama is recommended for its ease of use. In my case, I run a custom-built container that makes my RX590 work with the latest versions of Ollama (v0.20.2).
• Expected Performance: With proper quantization and GPU acceleration, inference should be reasonably fast for a model of this size, offering a good balance of speed and capability.

Which runs completely on the old GPU:

Scenario 2: Gemma4:26b on HP Z820 with Unraid 7.2 (CPU only, 48GB RAM)

This setup emphasizes CPU-only inference with a substantial amount of RAM. The CPU were a decade old: Intel® Xeon® CPU E5-2620 0 @ 2.00GHz

• Model Variant: gemma4:26b indicates a 26-billion parameter model. Running this solely on CPU will be a demanding task.
• Quantization: Quantization is critical for managing RAM usage and improving CPU inference speed. While 48GB of RAM is ample, a 26B model in full precision might consume a significant portion. Aim for 4-bit, 5-bit, or even 8-bit quantization to balance quality and performance.
• Frameworks: Ollama excels in CPU-only scenarios, leveraging multiple CPU cores efficiently. On Unraid, running Ollama within a Docker container is a straightforward approach, ensuring it can access your system’s CPU resources effectively.
• Expected Performance: Inference will be slower compared to GPU acceleration. However, with a powerful multi-core CPU (common in Z820 workstations) and sufficient RAM, you can still achieve usable inference speeds for batch processing or less latency-sensitive applications. The 48GB RAM is more than enough to load even highly quantized versions of a 26B model.

Running inside the Ollama container on my old Unraid server:

The Unraid console is showing the CPU usage and amount of RAM used:

Practical Considerations and Expectations

• Speed: Expect slower inference times. A response that takes seconds on a powerful GPU might take minutes on older hardware.
• Model Size vs. Performance: You’ll need to find a balance between model size (and thus capability) and what your hardware can reasonably handle.
• Context Size: Inevitably, you’ll have a much smaller context size to work with like 4096 or 8192.
• Setup Complexity: Setting up these models on older hardware, especially with custom quantization or specific Ollama builds, can require some technical expertise.
• OS/Driver Support: Ensure your operating system and GPU drivers are as up-to-date as possible for your specific hardware to get the best performance.

Conclusion

While running Qwen3.5 and Gemma4 on old hardware presents significant challenges, it is sometimes not impossible. By leveraging quantization, selecting smaller model variants, and utilizing user-friendly platforms like Ollama, you can still experiment with and derive value from these powerful LLMs. The key is to manage expectations regarding performance and be prepared for a more involved setup process. Happy prompting!

More in this series…

• AMD GPUs - Running Ollama with AMD cards.

The Installation Challenge

The installation process proved more complicated than a straight out-of-the-box experience. One of the main hurdles was dealing with localhost binding and the need to port-forward traffic. I had to route connections from my Ubuntu server, merry, over to my Unraid server, aragorn. This required carefully configuring SSH and networking settings to ensure that the services could communicate properly across my home lab setup.

Primary Agent: Gemini Flash

For the primary agent, I decided to go with Gemini Flash. I’m leveraging my Google Pro AI subscription for this. I bound my Google AI Studio project to the $10 USD per month credit provided by Google to cut API costs. This setup gives OpenClaw access to a decent reasoning model. Not as good as Anthropic’s newest Opus model, if reviews are to be believed, but I’m not paying $$$ for that.

Remote Access via Telegram and Discord

One of the real nice features of OpenClaw is the ability to access it remotely via Telegram and Discord. I set up a webhook for both services to allow me to interact with the agent from anywhere.

Secondary Agent: Ollama and AMD GPUs

I also wanted a local, open-source fallback. I made repeated attempts to configure a secondary agent connecting to my local Ollama server. This server is busy running various models on some older hardware—specifically, an AMD RX590 GPU. Getting the tools and Ollama to play nicely with an older AMD card turned out to be a failure though. I think the issue was the huge context being passed to the model on every prompt by OpenClaw. I may try again in the future with a more recent card.

Network Monitoring with Unifi

Finally, to bring everything together, I configured a Unifi skill for the agent. This allows OpenClaw to integrate with my network controller and keep an active eye on my home network’s health, giving the agent the ability to check on my devices and network topology.

Conclusions

Overall, the initial setup was complex and I was able to get a few things working. I completely struck-out on working useful local agents however, so I am not interested in building a lot of workflows that will simply generate a lot of API calls and big Google AI bills.

I’ll keep an eye on the project and may try again in the future once they improve the efficiency of local agents, allowing older hardware to be used more effectively.

While text-based local LLMs are interested, there are also good tools for image and video generation. On Windows, ComfyUI recently added some support for AMD GPUs.

1. Install latest AMD Adrenalin Edition (drivers for AMD GPU)
2. Install latest AMD HIP SDK
3. Install ComfyUI for Windows 11:

1. Select AMD GPU:

1. Try a test prompt in ComfyUI:

1. Generate the resulting test image:

NOTES:

I also tried this on my other machine, with an Nvidia 3070ti GPU, and discovered the install was simple and troubleshooting was not needed. Yet another example, where AMD is far behind the tool support that is available for Nvidia hardware.

More in this series…

• AMD GPUs - Running Ollama with AMD cards.
• Old Hardware - Running latest LLMs using old hardware (GPU and CPU)

Cloud Services

All of the options in this section are thin apps that simply pass your query up into the cloud. As a positive, this is often the fastest and most featureful appproach. On the negative side, you lose all privacy when conversing with a corporate cloud.

OpenAI ChatGPT

Anthropic Claude

Google Gemini

Microsoft Copilot

Mistral AI

Alibaba Qwen

MoonshotAI Kimi

Home LAN LLMs

After my deployment of private Gemma, Mistral, and Qwen LLMs on my home LAN, running Ollama on each PC, with a single instance of OpenWebUI fronting them all, I went looking for a mobile phone app to access my home LLMs. I found Conduit, which I connected to OpenWebUI via Tailscale on my Unraid server.

Conduit OpenWebUI

On Device Models

The real future of LLMs will likely be on edge devices themselves as phones/tablets get more powerful hardware. At this point, with my mid-range Google Pixel 9a, local LLMs can be run quite effectively.

Google Edge

The Edge app from Google is more of a playground demonstration than a real Chatbot app. They are mainly trying to attract developers looking to include AI in their apps, without requiring a network connection or cloud service.

Apollo LEAP

Similarly, the LEAP models in Apollo seem to be a developer demonstration, aiming for adoption and integration.

Pocketpal AI

Pocketpal seems to the leader of true on-device Chatbots, offering a wide-selection of free models.

Chatbox AI

On the otherhand, ChatboxAI mentioned a “Free” version, but I couldn’t seem to get to it, instead only being shown license sales pages…

More in this series…

• LLMs on Android Apps accessing Cloud Services

AI Investments

A huge amount of capital has flowed into the AI market recently, with OpenAI leading the charge. This has led to a large investment in AI data centres, in hopes of one day striking it rich on real profitability. Even the spending plans of the so-called hyper-scalers are somewhat ludicrous:

This is despite OpenAI’s expenses far outpacing its realistic revenues for the foreseeable future. With OpenAI planning an IPO in 2026, a public airing of their finances will likely be the cause of their implosion, in a tightening credit environment.

Google Catches Up

I became a small investor in Google’s parent company, Alphabet, when the original appearance of OpenAI’s ChatGPT combined with their clumsy early LLM efforts (Bard) depressed the stock price (PE ~17-20). Many thought that OpenAI was the first real threat to Google’s dominance in Web search and advertisting. However, I’ve been working with their rebranded LLM (Gemini) since early 2024, experiencing all the improvements they released so I stuck with them during recent stock runup (PE ~30).

Beyond the technological improvements, Google also started to expose these features in their main Search interface, raising their visiblity with the general public who seem mildly positive about them, but not clamoring to pay monthly fees for these features.

Google’s recovery after their initial stumbles doesn’t imply massive future success. With little in the way of user subscriptions for AI driving their revenue, will their infrastrucure build pay off? Will they be able to sneak more ads in, without further annoying their users?

Massive Infrastructure Build

The American tech giants are planning to spend an extraordinary amount on building large data centres with depreciating hardware. Each week brings new announcements from Microsoft, OpenAI, Google, AWS, Oracle, and others; all trying to outspend each other, often using promised funds from one deal to pay for the next deal, in a financial game of musical chairs. Their planned spend for 2026 is hundreds of billions of dollars, all of which is money not being spent on the rest of American economy, which is relatively moribund after considering inflation and the $US decline.

As seen above, borrowing is increasing in effort to raise more funds for this unprecedented build-out.

Where’s the Demand?

My own experience is that LLMs are novel and interesting, but they are not a magic bullet. I have long used Gemini for various tasks including writing, mathematics, image generation, and of course coding. The LLM has acted as a slightly faster search engine in my experience. For example, when coding I would normally find snippets from sites like Stack Exchange, that I would piece together and then test myself. While Gemini generates larger snippets, I still must test the program and fix the inevitable flaws it comes with. Yes models are improving over time, but I don’t forsee revolutionary improvements putting millions of people out of work, slaves to the billionaire class. In my experience, management routinely overestimates the importance of technology, while underestimating the importance of staff.

In fact many studies are showing that few businesses are getting anywhere near the expected benefit from their trial AI & LLMs to justify any significant per-employee subscription. Even if an LLM saves a white-collar worker an hour a week, this time-saving rarely translates into a measurable ROI that justifies an expensive monthly subscription for every employee, especially in light of the continued need for human fact-checking and refinement. To be clear, free LLMs offer nearly the capability of the high subscription offerings, so why pay more?

For a counterpoint opinions to my bearish take, the Blackrock investment firm is confident that demand will materialize for the incredible spend on infrastruture however. As well, JP Morgan is heartened by rising GPU-usage in data centers. I’m not surprised that investment peddlers are bullish on this market… time will tell I suppose.

China Rising

The large American tech giants which have focused on closed-source and closed weight models, with small side projects such as Google’s Gemma model. Chinese firms, on the other hand, have targetted open-weight models, freely available for enthusiasts to run at home, often on gaming PCs with a discrete GPU. Yes, while this approach is lagging behind the current state-of-the-art closed frontier models, these Chinese models are not much farther than a year behind. Most importantly, for many mundane day-to-day tasks, these free models are quite sufficient. China is also leveraging their manufacturing base to build both humanoid and industrial robots with specialized AIs that don’t need to have all of Wikipedia at their fingertips to function.

As well, the short-sighted and scattershot approach to hardware controls that the US has attempted to impose on China, have been ineffective at best, simply leading the Chinese to re-double their efforts to engineer cutting-edge silicon themselves at firms such as SMIC. While Nvidia and TSMC are making bank right now, selling shovels to prospectors during this gold rush, it’s not clear they will maintain that lead over Chinese fabs forever. Nor is it clear, that all these crazed prospectors will actually find real AI gold (aka enough revenue).

Conclusions

Overall, LLMs are an interesting tool that will no doubt improve over time and become part of daily life for workers around the world, just like the Internet did decades ago. However, just like the “dot Com” bubble burst around the turn of the century, I think this “AI infrastructure” bubble will also result in a large drop in stock prices of North American tech companies as the lack of true revenue growth for new AI services becomes apparent. I don’t see every white-collar worker worldwide paying hundreds of dollars monthly in new AI subscription charges to these tech behemoths, even accounting for potential layoffs.

Finally, the massive American AI infrastructure build implicitly assumes a “winner-take-all” outcome; a digital moat allowing a single champion to garner all possible revenue from huge user and API subscriptions. This isn’t even close to the case today with a lot of competitors having similar offerings. In the future, I expect more competition, not less, thus preventing one champion from charging the many hundreds of dollars in monthly subscription fees per seat they’ll need to recoup their planned infrastructure spend.

Almost four years ago, the original devloper of BitTorrent released a new cryptocurrency named Chia. Unlike the two large cryptocoins at the time (Bitcoin and Ethereum), Chia didn’t use the expensive proof-of-work approach which needed both in GPU hardware and lots of electricity. Intead Chia used a proof-of-space consensus using mostly hard-drive storage.

Eventually a talented developer in Germany released a GPU-based enhancement in early 2023, that was simply more competitive than the original design, providing a strong-incentive to start buying new GPU hardware for an improved plot format. At the time, I was discouraged that the “Green” vision of Chia had been lost. The CNI group responded by hinting at a new plot format that would return Chia to its original roots one day.

My Machinaris Project

As a user of Unraid, when trying to adopt Chia in early 2021, I found there was really no good option. My Machinaris project was essentially a bundling of various tools and forks that sprouted up around Chia when it first appeared years ago.

However, with the loss of interest in Chia over the past few years, all those related tools have been dropped by their authors. As well, my own interest in the Chia ecosystem has waned considerably, so as of now, I simply don’t want to invest a lot of upcoming time in trying to patch all the various old tools (plotman, chiadog, madmax, gigahorse, bladebit, etc…) that will inevitably break/change when CNI’s new plot format finally drops.

Conclusion

I think this means the end of my Machinaris project. For those that want to continue running Machinaris against the current format plots, using Chia 2.5.X, that should be possible until CNI releases an urgent security fix or some other backwards-incompatible change. Thanks everyone for the support over the years, it’s been fun.

More in this series…

• Chia on Unraid - Chia CLI on Unraid with Docker
• Machinaris - a new WebUI for Chia on Unraid
• Distributed Farming - Machinaris on many worker systems
• Chia Tools - open-source Chia projects
• Chia Forks - running forks of Chia with Machinaris
• MMX Blockchain - MMX blockchain on Machinaris
• MMX on GPUs - Farming MMX with a GPU
• Gigahorse - Farming Chia with a GPU
• Gigahorse Fees - Pay to play for Chia
• Chia Layoffs - Chia Network Inc. lays off many developers

Since then, enthusiasts online have filled in the support that AMD themselves can’t seem to deliver. Thanks to this Github project, it is now possible to run recent models on the 6750xt (aka gfx1031). Even more impressive, thanks to this Github project, I was able to rehabilitate my old Radeon RX590 (aka gfx803).

AMD Radeon 6750xt

This is an interesting card as it lacks the Nvidia CUDA support, but has 12 GB of VRAM rather than the 8 GB of the Nvidia card.

Installing Ollama

On this PC, I install apps and data on the larger D: drive, so first download OllamaSetup.exe and install via Powershell:

.\OllamaSetup.exe /DIR="D:\Program Files\Ollama"

Then quit Ollama from system tray and download the correct ROCM libraries for the 6750xt which is the gfx1031 generation.

1. Find the rocblas.dll file and the rocblas/library folder within your Ollama installation folder (located at D:\Program Files\Ollama\lib\ollama\rocm).
2. Delete the existing rocblas/library folder.
3. Replace it with the correct ROCm libraries.
4. Set env var OLLAMA_MODELS=D:\Program Files\Ollama\models (create the folder)
5. Then run Ollama again from Start menu.

Then launch OpenWebUI in Docker:

docker run -d `
   -p 3000:8080 `
   -v open-webui:/app/backend/data `
   --name open-webui `
   --restart always `
   -e OLLAMA_BASE_URL=http://host.docker.internal:11434 `
   ghcr.io/open-webui/open-webui:main

Then browse to http://localhost:3000 to access OpenWebUI, where I tested the recent Qwen v3 model:

Monitoring the speed of the response, I was pleasantly surprised. Much faster than the CPU-fallback mode I experienced earlier. Ollama reported GPU being used:

Monitoring the GPU usage via Task Manager, I was able to run queries against both Qwen and Gemma, though that is a bit too tight:

AMD Radeon RX 590

For an even bigger challenge, I decided to look at running Ollama using a AMD 590, nearly a decade old card now.

sudo docker run -it -d --restart unless-stopped --device=/dev/kfd --device=/dev/dri --group-add=video --ipc=host --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -p 8080:8080 -p 11434:11434  --name rocm64_ollama_095 robertrosenbusch/rocm6_gfx803_ollama:6.4.1_0.9.5 bash

sudo docker exec -ti rocm64_ollama_095 bash

./ollama pull gemma3:4b
./ollama pull qwen3:8b
python3 /llm-benchmark/benchmark.py

Then in another shell, I monitored the GPU usage with amdgpu_top, ensuring the old card was working as hard as it could:

The results of the benchmark are not fast at all, but just impressive that these new models even run on hardware from a decade ago. Kudos to Robert Rosenbusch for his great work making this possible.

Finally, I browsed to the Ollama webui and asked the Qwen model if it thought I could run it on such an old AMD GPU. Quite rightly, Qwen advised me that it is highly unlikely it could run on such ancient hardware:

Network Hosting

With multiple systems on my home network hosting Ollama and different models now, I decided to put a single instance of OpenWebUI on the home server running 24/7 in the basement. This lets family members use local LLMs from anywhere on our home network, useful for comparisons against the public models like Gemini and ChatGPT.

While the LLM frontend can expose different models on different computers, but it doesn’t do a good job of labelling them, dealing with certain workers being offline, nor selecting the fastest available worker. I am hopeful that OpenWebUI will improve handling of multiple Ollama workers in the future.

Benchmarking

After forking and fixing a simple LLM benchmarking script, I deployed it to all 3 of my systems to see how well they ran the same prompts using the gemma3:4b as a common test.

Setup

First in Gitbash:

cd "d:/Program Files/Ollama"
git clone https://github.com/guydavis/llm-benchmark.git
cd llm-benchmark
python -m venv venv

Then in Powershell:

cd "d:\Program Files\Ollama\llm-benchmark"
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
.\venv\Scripts\activate
pip install -r requirements.txt
ollama list
python benchmark.py -u gemma3:4b

AMD Radeon RX 590

AMD Radeon 6750xt

Nvidia RTX 3070ti

Conclusions

Clearly, the open-weight models are rapidly improving if they can run reasonably on such old hardware. Soon these mid-weight LLMs will run on portable devices such as phones, improving upon the current embedded models. There is still clearly a serious performance penalty to run on an AMD GPU, instead of industry-standard Nvidia GPUs. Though simply being able to use AMD hardware is honestly a pleasant surprise.

With such progress happening, I fail to see why the American tech giants will be able to charge premium subscription prices. With the AI stock market boom in full swing right now, it will be interesting to see if they are still flying high in a year, in the face of open-weight model competition.

More in this series…

• Llama 3 - Llama 3
• Ollama - Ollama via OpenWebUI
• Deepseek - Trying small distills locally.
• Old Hardware - Running latest LLMs using old hardware (GPU and CPU)

1. rclone - Used to transfer files from the Unraid server to GDrive
2. restic - CLI for automated backups
3. backrest - WebUI for restic

RClone

You want this to be installed directly on the Unraid OS level, not within a separate Docker. For this, install the rclone from Waseh, which will put the rclone binary directly on the Unraid OS CLI.

Then you need to configure rclone for access to your GDrive, using these directions. Basically, you need to create a new Google Cloud project (in Google Console), enable the GDrive API, then create a Service Account (named Unraid Backup or similar). The service account needs the Storage Object Admin privilege, then you create a Key for the Service Account, which will download a JSON private key. With that info, you run rclone config and add a new rclone remote, which I called ‘gdrive’. To verify that rclone can access Google Drive, run rclone lsd gdrive which should list the folders at the top of the remote Drive. I then created a new folder in Drive called ‘Backups’ to hold these backups.

Restic and Backrest

The restic CLI binary is included within the BackRest docker container, installed via Unraid Apps:

Be sure to add a new Path that will allow the Rclone config on Unraid OS to be shared into the Backrest container as well:

Once Backrest is running in the Docker container, we need to add a restic repository that is backed by the configured Google Drive (via rclone):

Once the repo is created, then create a backup plan that uses it:

I chose to backup once weekly. To validate, I started the backup manually:

As this was my first backup, it took about half a day. I immediately saw that Restic was creating files within the Backups folder I had created in Google Drive.

Conclusion

This wasn’t the simplest setup with three different components, but it does seem to be working. Next month, I’ll investigate the resulting backups and incrementals, to verify the recovery process. So far, so good…

More in this series…

• Unraid Urbackup - initial backup solution from a few years back

Instead, I wanted to host access to my own library of ebooks and audiobooks again, using Readarr, Libation, and Audiobookshelf.

Readarr

Readarr is part of the Servarr group of media management tools, including Radarr (movies), Sonarr (shows), and Lidarr (music). Unfortunately, the Readarr project itself has been retired, but the community has picked it up, and are carrying forks forward. The best, today anyways, seems to be Bookshelf by pennydreadful.

Deploying on Unraid is pretty easy, I simply used an existing Unraid app like “binhex-radarr” and change the Repository line to: ghcr.io/pennydreadful/bookshelf:hardcover:

Libation

Since, we had some audiobooks on Audible, I needed to use the Libation project to extract them into a format that I could host myself. Setup on Unraid was a bit tricky as I first needed to install the Libation desktop app on Windows, enter my Amazon Audible logic credentials to generate some encoded JSON files, then install the app on my Unraid server, placing the JSON settings files from Windows into the Unraid appdata area.

Then every half hour, Libation running in a Docker container on my Unraid server would look for any new audiobooks and extract them into place where Audiobookshelf automatically cataloged them, ready for listening by my whole family.

Audiobookshelf

For hosting, browsing, and reading the books, I chose Audiobookshelf. ABS, as it’s known, is a Docker container deployed on my Unraid home server, combined with an Android app on our phones.

Deploying on Unraid is shown. I also added a Path for my ebooks.

Then viewing the running instance of Audio Book Shelf, within a browser:

While it is possible to use the web browser to play/read books, I found this interface better for just managing and listing the catalog.

Instead, listening is best done on a phone with the ABS app itself:

Reading ebooks on the phone can be done with the ABS app directly (left screenshot) or another reader like Moon+ (right screenshot).

Conclusion

This whole setup was quite a bit easier than I expected. I’m really impressed with the quality of the Audiobookshelf web app and phone app too. I forsee no problem cancelling our Audible subscription on expiry. Yet another American digital service that my family here in Canada will never pay for again.

More in this series…

• Ebook Readers - hosting ebooks and audiobooks myself

Lidarr Workarounds

Digging into the Lidarr Discord for support, I found a fork from blampe that seemed to help somewhat. However, the issue with broken metadata lookups involved server side as well, so this wasn’t a final solution.

Spotify Playlist Import

A common way to share album lists these days seems to be Spotify. I’ve never been a subscriber myself so I looked for tools to extract an album list from Spotify into a CSV file that I could then import into Lidarr. This sounds easy, but the slight variation in naming of artists and albums makes this a challenging data cleanup problem.

To start with, I used Spotlistr generate the CSV file with appropriate fields from the Spotify playlist:

Then I used my lidarrtools scripts, to complete the import from CSV file into my Lidarr instance, working around missing meta-data.

Soulseek Alternatives

As I was looking at my music library, I stumbled across Soulseek as an alternative means of sourcing music, for import into Lidarr. In my case, I am running Unraid so I found Docker templates for ‘slskd’ and ‘soularr’. Soularr is a headless Python script that connects Soulseek and Lidarr.

Here’s the configuration for Soulseek:

Here’s the configuration for Soularr:

I needed to edit the slskd.yml file at /mnt/user/appdata/slskd to set an urlbase of /slskd (behind my SWAG proxy) and add an api_key for connection by Soularr.

Then I needed to create a config.ini file at /mnt/user/appdata/soularr, filling in the lidarr and slskd sections:

Then port-forwarded 50300 and 50301 on my router to allow for Soulseek traffic. After this, Soularr seemed to start querying Soulseek for missing albums, and then importing them into Lidarr.

Conclusion

UPDATE: Eventually in August, the Lidarr devs deployed a new metadata service that began to correct the missing API hits for artist & album searches. Big thanks to them for improving Lidarr, a very useful bit of software.

More in this series…

• Lidarr Importing - Scripting album imports