Skip to content

Notes

Zurg will default to WARP if gluetun is not configured

Further to the recent blog post about how we now need a VPN to use Zurg with RD, the necessary changes to our design are now done to support this scenario:

  1. If you don't have gluetun, your Zurg pod will use WARP
  2. If you add gluetun, your Zurg pod will use gluetun and not WARP
  3. If you remove gluetun again, your Zurg pod will revert back to WARP

To make this happen without impacting users bundles, we attach WARP and gluetun to your containers, but only one of them is active at a time. To confirm your connection, use the pod logs as illustrated in the gluetun video, or the troubleshooting video below.

WARPing around RealDebrid blocks with VPNs

About 24h ago (just as we ran a big Riven rollout), RealDebrid finally closed the IPv6 loophole which was allowing us to Zurg with RealDebrid from datacenter IPv6 range.

We added a new product / process to allow us to connect your pods (Zurg, in this case) to your own, existing VPN. On the plus side, it's extremely flexible, since gluetun supports a huge range of VPN providers. On the downside, it requires some user geeky interaction, which I explain in this video:

The solution works great, and several our of geekier elves validated it with Mullvad, Nord, ProtonVPN, and PIA. This was only a small subset of the affected users, and the process of VPN-ifying 100+ Zurg pods was looming unpleasantly...

And then our newest Elf-Venger, @Mxrcy, pointed me a container image for CloudFlare WARP, which can be used as a SOCKS5 proxy in Zurg 0.10, with zero manual config! After a bit more refactoring, we were able to reunite all users with their beloved RD libraries via CloudFlare WARP! 💑

However...

Riven is Ready for Revenue Sharing (and testing)

Iceberg has "melted" from the store, to be replaced with Riven, and the Riven/Plex Infinite Streaming bundle.

While we wait for UI dev to complete, I've replaced the UI with a realtime, live view of your Riven logs, via your browser (launched from your dashboard). From this UI, you can CTRL-C to restart (it's not actually the logs, it's the backend process itself!), and watch Riven do its magic in realtime.

Riven Revenue Sharing

Riven is the first ElfHosted product which falls under a new, experimental "revenue sharing" model. Because @spoked is working so closely with the ElfHosted team to make Riven work 💯 with our platform, 30% of your subscription will go to the Riven devs to support further development! ❤

You can also join me in sponsoring @spoked directly, via GitHub Sponsors

Remember, this is all very cutting-edge and geeky, so some assembly will be required. Jump into our dedicated #Riven forum topic with your bug reports, feature requests, and feedback!

Zurg 0.10.0rc2 rolled out, love live repairman!

It's been 4 days since Zurg 0.10.0rc2 was released (to sponsors), and we've had a few brave Elves testing it out. So far, there are no show-stoppers, so we've now rolled v0.10.0rc2 out to all users.

Significant improvments over v0.9.x are:

  • 1⃣ Repairing works again, without causing plex to stall its scans
  • 2⃣ Zurg can now co-operate with Real-Debrid to extract RAR-compressed "downloaded" media!
  • 3⃣ Zurg now supports non-video files (i.e., audio)

Read on for how to enable the new features...

Emby / Jellyfin transcode fixes

The recent transcode path fixes to Jellyfin / Emby have brought a small bug out of the woodwork.. in some cases, the streamers may insist on transcoding your media based on your perceived bandwidth limits, and then fail to transcode because (a) it's 4K content, or (b) the transcoding path is not set to /transcode, and we've prevented use of the network storage for such!

A simple workaround is to edit your Jellyfin / Emby users, and to remove their permissions to perform video transcodes, something like this:

Read on for more fixes...

Jellyfin 10.9 is out! (and now, fixed)

Jellyfin 10.9 was released last week, with new features including "trickplay" (live video scrobbing), admin UI revamping, and improved ffmpeg transcoding powerz.

Unfortunately there was a significant bug in 10.9 causing random lockups, but we were unable to roll back because of database upgrades. While the devs were working on the fix, we rolled out some changes to our health checks - rather than a TCP connection to confirm Jellyfin is alive (but, sadly, still locked up), we now use an HTTP test against the API's health endpoint, which fails when Jellyfin is locked up, so that we can at least quickly kill and restart a stuck Jellyfin instance.

The bugfix has rolled out in 10.9.2, so hopefully this is now a non-issue!

It also turns out that Jellyfin was not consistent in where it stored its transcoding data, and some instances were defaulted to /config/transcodes (/config is backed by our expensive NVMe network storage, not where we want to be sending GBs of temporary transcoding data!), while others were set to /transcode (correct) or /config/cache/transcode (also incorrect).

Tonight's update symlinks all of these combinations to /transcode, the 50GB ephemeral NVMe-backed disk on the local node, avoid stressing our network storage. In summary, you can ignore the transcode path in Jellyfin. We'll make it work in the backend :)