FinAmp is a fantastic JellyFin music player, and even supports offline downloads for on the road. Sadly the interface isn’t really AndroidTV-friendly, but it works great on android touch screens, iOS, linux, and macOS (probably Windows too, but I’ll never know).

I’m looking for a good AndroidTV player as well, because the official JellyFin app doesn’t background well. We like to play music in parallel with a screensaver or fireplace app, but JellyFin pauses after about a minute when hackgrounded.

I run Adguard Home containers (the primary auto-syncs to the secondary) and use redirect filters to assign hostnames to each of my containers. I have a “services” folder of bookmarks for each container host so I don’t have to remember each service’s port number. I use KeePassXC to track all my passwords and certificates so authentication is a breeze (someday I’ll get around to setting up an SSO solution). I also keep a .txt file with my basic network info that doesn’t always translate well to dns hostname redirects in adguard. I occassionally remember to update my hosts listed in the file. My individual config files aren’t backed up beyond my automated container backups, but so far none of my services have been that complicated I couldn’t just rebuild from scratch.

It’s not perfect, but combined with my automated backups I have barely enough to rebuild if/when my hardware fails.

As far as I could tell: yes, and yes.

I wonder if this post has anything to do with the unmanic API outage earlier today, lol. I was pulling my hair out trying to figure out what I’d done wrong until I finally convinced myself there must be a cloud-side outage impacting the plugin browser. By the time I figured it out they came back online and the plugins were browsable again, but I lost hours over this stupid problem.

Today’s outage perfectly illustrated why we choose to self-host in the first place. I too would love to see a completely self-contained foss solution for this service. Some clever shell scripting is probably all you really need to perform automated ffmpeg calls, but individually containerized services are clearly what we all prefer. I do wish I had more time to code…

FYI, you can run LineageOS on your Nvidia Shield. There’s a small loss of functionality, but maybe that can be minimized if you install gapps (I didn’t, and I still have sufficient functionality to warrant the inconvenience).

afaik airtags are apple-proprietary, so someone would need to reverse-engineer them first. that’s probably not a small ask. i haven’t personally looked into it though, so here’s hoping! 🤞

qemu vm. I really wanna run this with the first fairphone to become readily available in US (fp6 i assume) but there’s still a ways to go…

Yup! Kali is a rolling distro built on Debian Testing, not Stable, annual releases. It can be used as a desktop OS, but still has pen testing and other security tools as their main focus

interesting… I was not aware of that. good to know; thank you!

yeah, ubuntu’s good for that. annual LTS cycles (used by distros like ubuntu and debian) are exactly how to sidestep the issue I’m referring to

True. but you have to keep a much closer eye on when it’s safe to update. that was my solution while running Debian Sid (unstable) on my other MacBook for awhile (I really wanted KDE 6 before Trixie was officially released), but believe me this approach gets old. I eventually relented and set it to Debian Stable once Trixie was official. I’m looking for a more stable approach to a rolling release cycle that allows the kernel to upgrade when it’s available, without also breaking the wifi. another commenter suggested the broadcom module might be replaced by the intel iwd driver, which I definitely need to try.

Please do! For stability’s sake, I recommend installing a distro that follows an annual, stable release cycle such as Debian or Linux Mint. Mint famously has the required support for most hardware right out of the box, allowing for a easy experience.

very possibly! I’m not 100% certain what is actually breaking there that seemingly gets solved after “some time” has passed. you might be on to something!

Sorry, I think you misunderstood me. My point is that holding back the kernel indefinitely is an issue, especially in a rolling release distro. the broadcom module is always significantly behind the kernel, so allowing the kernel to upgrade in a rolling release cycle will frequently break wifi that relies on that module. However, another commenter has suggested that broadcom module might be replaced by the intel iwd driver, which I’m definitely going to try.

you certainly make a good point, and replacing the hardware has definitely been a popular suggestion. fwiw, this MB Air was just a free hand-me-down, so I’m specifically using it to distro hop and fart around with different Linux distros on old Mac hardware that I have no attachment to

Interesting. I actually tested Endeavour OS on this MB Air specifically (as well as my main MB Pro, but several years back) and the wifi was not natively supported out of the box. I was able to get it working by installing the broadcom module, but it still broke with the next kernel update. Another commenter has suggested replacing the broadcom driver with Intel iwd; I need to give that a shot. Endeavour seems a very approachable way to run Arch on MacBook hardware if I can solve this wifi problem more permanently.

I was not even aware there was an alternate driver option. I definitely need to look into that; thanks!

indeed, distros that follow an annual LTS cycle definitely avoid the issue

yeah, a common suggestion has been to just replace the hardware.

Yeah, Mint is based on Ubuntu LTS, which follows an annual release cycle. That’s precisely how to avoid this issue.