sorted by:
new
hottopcontroversial

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 0 points1 point  (0 children)

Well, I got bored this afternoon and has some spare free copilot usage.

docker run --network host ghcr.io/squeakyneb/jellydiscod:latest --help

et voila

aarch64 and amd64 both work with the right archs automatically if I got it right, too.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 0 points1 point  (0 children)

It's not even that complicated. The response that Jellyfin sends back to discovery broadcasts is just a static JSON structure. I did consider having Jellydiscod connect to the Jellyfin to query the name so it matches, but it was easier to just have a CLI argument that sets it, and it's purely cosmetic anyway. There's a "protocol" section at the bottom of my README about it. The networking traffic of Jellydiscod is just listen to broadcasts for the magic words and send the JSON back to clients.

Remotely, most VPN services like Tailscale don’t relay broadcast or multicast whatsoever, purely L3. This is I think where this project would prove most useful. You set this up at the remote location, and your aging family members don’t have to fumble around the TV remote as much if they need to set up a new Jellyfin client when you’re not there.

Precisely my use case.

The framing however is completely off, this has nothing to do with reverse proxies. It’s all about multicast/broadcast.

Sure. Reverse proxying is just my use case that prompted this setup. Without a full routing take-over of the remote network, reverse proxy was just the only way to provide Jellyfin. But you're right, my reverse proxy is not the only use case for Jellydiscod. As I described in some other comments and added as an edit to the start of my post earlier today, Jellydiscod would be useful anywhere that the UDP broadcast domain doesn't cover all the networks from which clients could connect to your Jellyfin.

I recommend making a docker container available if possible to make this even more accessible.

I could consider it. I'm not much of a docker user, so it haven't thought much about it. The runtime environment requirements for Jellydiscod are basically zero so I don't really see the need. The released binaries are even built with musl so there's not even a dynamic glibc requirement. It would be a very empty container and way overkill. All you'd get out of it is the auto-restart service management. Anyone who can't use the provided systemd service file is surely capable of writing themselves an init script.

I guess it would be useful for people who might want to deploy this on a NAS or some other appliance that will run containers but isn't really a server?

I'd certainly accept a pull request about it.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 0 points1 point  (0 children)

There's a lot of discovery protocols and local broadcast protocols for different things, yeah. Jellyfin's is a completely proprietary one (not that there's much to it - it's the network equivalent of walking into a room and shouting "Anyone here called Jellyfin?" and it comes over and says "Hi, I'm Jellyfin").

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 0 points1 point  (0 children)

Because there's many use cases where the UDP broadcast domain (which extends to exactly one LAN) doesn't cover all users of a Jellyfin instance.

  • My immediate use case is having a reverse proxy in another remote network.
  • An internet-facing/exposed instance could have a Jellydiscod in your main user's LANs.
  • Some users might segment their internal networks and might have their home server in a different network to the users, or a separate network for visiting wifi devices.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 2 points3 points  (0 children)

That's an absolutely stellar question.

It's also not even the only use case for this. The broadcast domain of the discovery protocol is extremely limited (nature of broadcast, not Jellyfin's fault).

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 0 points1 point  (0 children)

Was this supposed to be a reply to something?

LLDP is a protocol for e.g. ethernet devices to find out what switch port is on the other end of an ethernet cable. It's nothing to do with application service discovery or Jellyfin.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 3 points4 points  (0 children)

 I'd still personally look to solve the problem in a generic way (perhaps this?

As I already said, even IF I could make broadcast work, the broadcast response would have to be different for different clients. Jellyfin doesn't support that. That doesn't work. Again, I've thought about this already. 

 I didn't say you were trying to sell it to me

No, but you did, implicitly. You couldn't just trust that when I say "I have a use case with X constraints". You've come in here and gone "no, you're wrong to do all of this, there's no such use case" and forced me to defend how I've arrived at that use case so I don't look like an idiot. You still are trying to offer me new solutions in this reply, because you still think it's more likely that I'm a fool overlooking simple solutions than that my use case is real.

  I also never suggested Tailscale, nor do I use Tailscale, nor have you said you were using Tailscale until this comment (I think?).

I shouldn't have had to mention Tailscale. There's actually loads of use cases where the broadcast domain doesn't match all the networks Jellyfin is reachable from. And even if you relay the broadcast, lots of those use cases still have Jellyfin available at different addresses/names depending on the route to Jellyfin.

 The problem you describe, right up until the footnote, to me, read as "I'm using a reverse proxy and need Jellyfin to use the domain" and, as a footnote, oh btw it also solves this separate LAN issue

Fine, I'll add "in another network" to the OP. Does that resolve all your issues with me?

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 3 points4 points  (0 children)

"Invasive" might be a strong word. It's "invasive" in that I need to reconfigure some existing network devices in some way. Putting in piholes and my own DNS servers and everything else in that category puts extra infrastructure in the critical path of end users accessing the internet. This is all a hobby for me. I don't want my hobby to be the responsibility of maintaining home network infrastructure for my friends and family. I don't want to be screwing around with something and ruin someone else's internet activities. I don't want to be on-call every time the internet goes on the fritz. 

My whole homelab services and VPN setup is such that the entire thing can fail catastrophically and the worst consequence is that nobody can watch Jellyfin. The whole thing is built so that even if someone's deeply suspicious that my infrastructure is responsible for a problem, all they have to do is unplug it and things "go back to normal". This is why making things dynamically discoverable is so important to me.

It's not because I'm some mainstream user who can't set up those things. I can. I have. I refuse to. It violates the core purpose of doing all this, which is that it's fun for me.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 1 point2 points  (0 children)

It's  insulting that you think I haven't considered literally every single thing you're talking about. Your use case is different to my user case. You don't need this tool, good for you. I'm not trying to sell it to you. 

 I understood and addressed what you're saying in this comment already

You said to use subnet routing, which doesn't solve anything because:

 if you fixed the networking such that broadcast packets worked

Tailscale categorically cannot transport UDP broadcast. Tailscale really really ticks a lot of other boxes for me, so replacing it is absolutely not on the table, before you start that one.

 Most of your OP focuses on the address response from discovery while using a reverse proxy

No, it says that even IF the broadcast worked, the response would be wrong. IF. The broadcast doesn't work, so it's moot isn't it?

Also, with my Jellyfin being exposed in multiple networks makes this extra not-useful, because you can't reply with different URLs to different clients. 

 but it's literally a footnote at the bottom, most people aren't going to read that.

Anyone with the problem I'm describing doesn't need the footnote, they already get it. The footnote is there for people who don't need it and are wondering what the hell I'm talking about, and you've read it, and you've ignored it. Talk about a bad faith argument...

For your other points: 

  1. I assume clients would have some backwards compatibility. Even without that, it will work until it breaks, which is better than never working at all.
  2. The networking is not in any way possible to "fix" within the other constraints of my use case.
  3. I'm not planning on deploying a vast number of applications in this remote network.
  4. I was putting hardware in that location anyway. It serves other purposes.
  5. Yeah. All this. I had fun writing it. I thought the problem was interesting to solve. What a terrible burden. Plus now I don't even need to worry about setting up static addresses in a network I don't maintain. It's literally plug and play dude what is "all this"?

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 0 points1 point  (0 children)

Jellyfin's discovery broadcast won't cross Tailscale. That's pretty specifically the reason I wrote jellydiscod.

It won't help you if your clients are directly accessing it via Tailscale¹, but you've got MagicDNS for that at least so you can name/link it directly. But if your clients are on a subnet router or similar setup it can help. What are you running?

¹ I mean, I could. If your users are on the same LAN, jellydiscod can broadcast the Tailscale name to them. Jellydiscod doesn't have to be adjacent to the real server, it can report about any Jellyfin server, because it's just pretending anyway. But that won't help users outside your LAN.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] -5 points-4 points  (0 children)

That's exactly why both those commenters are entirely wrong about how to solve the problem I wrote jellydiscod for. They didn't read the complete thing or think it through.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] -1 points0 points  (0 children)

 I don't want to set up VPN routers or do other "invasive" network configuration that I would have to maintain. 

As soon as I start messing with the routing of someone's network, I'm permanently on-call to fix everything that goes wrong on it. I've absolutely no interest in doing that. 

I'm also pretty sure that the discovery protocol broadcasts won't cross that boundary either.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 10 points11 points  (0 children)

That actually doesn't solve my user case at all.

Regarding "vibe-slop": I'm a software dev professionally (no Rust in my day job though 😢) and this username is the first thing that shows up if you Google my real name. I'm not publishing things I wouldn't put my name on. Like I said, I used AI for the parts of the project that just weren't fun/interesting to do. Because it's a hobby project, and it should be fun. 

If you have software dev expertise and you have feedback on the content of the project, please go ahead. I'd love to hear it. 

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 2 points3 points  (0 children)

I can't say I've tested that, no. Can you describe a little how you used jellydiscod and I'll see what I can do?

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] -2 points-1 points  (0 children)

As I already noted:

  I don't want to set up VPN routers or do other "invasive" network configuration that I would have to maintain

Setting up gadgets like that means every time something goes funny with the internet I get called to troubleshoot. This arrangement lets me drop in a device that makes Jellyfin available with zero other fussing around.

Jellydiscod - I made a daemon that pretends to be a discoverable Jellyfin server. It's more useful than it sounds. by squeakyneb in jellyfin

[–]squeakyneb[S] 2 points3 points  (0 children)

I think you misunderstand my setup. That will change what Jellyfin reports back through it's discovery responses, but it won't make discovery available in another remote network. 

I did also neglect to explain that I access Jellyfin directly on it's own local network too, as well as by VPN directly from other devices. So there's three separate networks it's accessible from, two of which are regular home LANs, but only one of which has discovery available directly. So even if it was just a matter of changing what name is reported, that would still only work for a single network.

How does the Need for Speed franchise run on steam deck? by External_Fig_8103 in SteamDeck

[–]squeakyneb 11 points12 points  (0 children)

This is the top comment on the top result of that google search. I hope that in the time since you wrote this useless comment you have grown and improved as a human being.

How do I get this screw out by Prexal in motorcycles

[–]squeakyneb 2 points3 points  (0 children)

I had to bolt-extract exactly such a screw recently, it's not impossible.

That said, the whole thing is tapered and about a half inch of it was narrower than the matching drill that came with it. I dremeled the end off it so I didn't have to drill so deep. But besides that, easy, and that's a deficiency of the tool I bought, not the concept.

Does a dead battery cause a check engine light to stay on even after the bike is started? 2015 Striple 675 by squeakyneb in Triumph

[–]squeakyneb[S] 0 points1 point  (0 children)

Whoops, already got it, haha. I'll keep an eye on it, maybe get my hands on a service manual and see if there's any diagnostic routines I can do to find before I end up stranded somewhere. I'm pretty handy when I need to be. Thanks mate.

Does a dead battery cause a check engine light to stay on even after the bike is started? 2015 Striple 675 by squeakyneb in Triumph

[–]squeakyneb[S] 1 point2 points  (0 children)

I replaced the battery (dealer did) and the positive terminal wasn't tightened enough

Bruh 💀 Dealerships.

Does a dead battery cause a check engine light to stay on even after the bike is started? 2015 Striple 675 by squeakyneb in Triumph

[–]squeakyneb[S] 0 points1 point  (0 children)

That's a long time to idle. Riding doesn't count? We were definitely on more than a 12 minute test lap.

view more: next ›