2023-09-30, 01:20 PM
(2023-09-30, 08:15 AM)bitmap Wrote: For sure. I have no intention of setting up shop to support the Servarr stack, but when issues like the one that brought this to a head for me come up, it's easier to say, "Look you really need to focus on custom formats in Sonarr/Radarr, split your server to a different machine than the one you're gaming on, get a different device for HWA, or find a client that supports the media you're trying to play."
Knowing that presenting options, without any offer or intention of supporting the tool, configuration assistance, etc. feels like a good balance. Appreciate you taking the time.
EDIT: Shit I think I broke the latest posts widget.
Nah, you're fine. I broke...something...by splitting out these posts as their own thread. Post away.
I sounds like we're largely on the same page, but just to extrapolate a little more for the sake of posterity:
I think the thing that gets lost in translation sometimes, or maybe just often overlooked, is the implication of something like "custom formats in Radarr/Sonarr" and why I'm saying that it crosses a line. That stack has no ability to format shift media. If they were transcoding tools, you could and should of course share information on that. But they are not. There is exactly one way that radarr or sonarr can filter formats or provide formats, and that way is one of things that is explicitly against the rules here: content acquisition. They do this by telling other things to go out and GET media in a given format, and we're not going to help with that configuration here. It's perfectly fine to tell someone that they might need files in h264 or HEVC, or whatever. It's even fine to explain how they might convert their existing files themselves. But implicit in what you're talking about here is configuring a tool to acquire media in a specific format for Jellyfin, and that's where the line has been drawn with respect to the rules.
We are talking about the difference between saying, "you might need source files that are encoded differently," and letting the user sort out how they want to approach that, and, "sonarr and radarr can get you source files encoded differently if you adjust these settings." And the latter is exactly the sort of thing that the team has decided we're still not doing even under the new, relaxed rules. You're not wrong that this is less helpful, it's just something the team doesn't want us to help with here. As a bit of background, Kodi has had trouble with approvals on app stores and such because it has such a reputation as being a tool that enables piracy, and Jellyfin's team does not want that to happen to Jellyfin as well--hence these arm's length rules. Sonarr and Radarr do a lot of things, and some of them, like library management, are directly related to Jellyfin and completely fine to support. But they also do a lot of things are not, and it's generally better to let their own support communities accept those risk if they wish to. The fact of the matter is that most guides related to this stack step pretty far over the line for Jellyfin's community standards, so it's best to just send them to the official support channels for these projects and let them go from there.
Jellyfin is FOSS, and people can use it for what they want, and we certainly want to encourage a broadly helpful support community. But this is just a line in the sand that Joshua and the project team have drawn to protect themselves and the project, even if it means some extra steps for users to take at their own personal risk.