Replies: 8 comments 9 replies
|
Personally I think requesting lower quality benefits fewer users. While certainly something that would be a nice to have, I'd argue most hardware is perfectly capable of live transcoding to a lower quality inside todays media servers. Instead I think it would be better to show labels such as SD, HD, FHD, and UHD on the items page. Then allow a user to request a higher resolution. Much of my plex library is SD and FHD and allowing users to request FHD or UHD versions would be ideal for my use case as well as requesting quality level at the time of making a new request. For example, I could request Re:Zero and have the option of SD, HD, FHD, and UHD from the request modal. Some content will not be available in SD but it could certainly be treated as a minimum quality requested rather than I want this particular quality. No, as I mentioned above, even the most basic processors these days have hardware encoders so any media server in the last 5+ years should be perfectly capable of transcoding to a lower quality if it's needed. Yes. if SD and UHD exist, it would be ideal to show both as available. I think following the example of something like Infuse would allow for a good UI/UX. While I've included a basic example of the standard qualities here, something more akin to Infuse would look better. I'd argue that on movies putting it next to the genre would make it visible without disrupting the flow. For TV shows next to where it says "Available" on the season. |
|
I would really enjoy having pretty much all of the features from this Seerr PR #3060. The 4K badge showing up on the title cards when only a 4K version is available is what I am most looking forward to. But I know from conversations with my users that all of the other features and options in this PR would also improve everyone's UI experience. |
|
Dang, I was hoping this would have gotten some more visibility or positive comments by now. After checking the comments on the PR I hope this PR's changes can be split up so these visibility changes remain moving towards being pulled while still aligning with the devs' vision. |
|
Thanks for starting this discussion. Hopefully it will get more traction over time. As far as I'm concerned, the only thing missing for me is some kind of indicator that a 4K movie has been requested. That's it. Whether that's a separate 4K badge, or just the existing icon, I really don't mind. But something. My fear is that whole feature is now lost in a major refactoring / redesign effort that's been "in the works" for nearly 3 years since the Overseerr PR. I don't fully understand why, when Seerr has native support for separate 4K Radarr and Sonarr instances, that this is so controversial. PR #3060 would appear to address a feature gap I'm sure others would appreciate. |
|
Thanks for the points you're making and you're welcome for keeping the discussion alive. One thing though, PR #3060 is not mine. I am just rooting for all or most of its visibility features to be implemented. |
|
My bad! I blame the heatwave 🥵 |
|
Thanks buddy, hopefully they will see it useful as well, as the Overseer PR is outdated and stale for so long.. hope this one won't end the same. |
|
Do the devs have any new thoughts about this over the last couple months that we could discuss? |
|
I'd also like to see this change put in place. I understand there are concerns with changing the current UI patterns, but having the options available up front, at the same time, as well as badges to indicated what's already available without having to click into the media page itself would be a big win. This makes things easier on the end user, and less confusion on trying to figure out how to handle these requests. I'll also point out that while it's a long way off from being merged, this would also benefit the ebook/audiobook PR as audiobooks live in the same space as 4k. Having the option to request audiobooks upfront and not buried behind the ebook request would be another benefit of this change. |
|
@Flawkee Just wanted to give you an update on this. I have a few ideas for the availability badge on the poster that would keep the current minimal design without cluttering it, while still making 4K availability clear. I’ll run them by the team first and see what they think, then get back to you with any changes we decide on. |
|
I apologize if I’m misinterpreting this, but it sounds like you/the team would be opposed to a change that allows both request buttons on the card like shown in the PR images, attached below. Would this be right? If this isn’t desired as a default would you be opposed to it being an option in settings users could enable themselves? I would very much like to have this layout as it’s less of a confusion for my users to have all options available directly on the card, having to click into the media page and then hit a drop down has caused confusion many times and having this feature clears things up. 
|
You're misinterpreting it. That's not what my message was about. |
|
Oh I was aware that wasn’t what your reply was about sorry. Both that reply and the one on the PR itself only addressed the badge, and a different PR that was already in place for that so I was reading that as the only thing you wanted change. Glad to hear I was just misreading. Thanks! |
Sounds good mate. |
|
@Flawkee Wanted to give an update on this since it's been sitting a while. I was going to put together a design to walk you through before asking for changes, but once I started mocking it up, actually building it turned out to be less work than designing it separately, so I ended up implementing it myself. See video attached. On why we didn't go with the layout in your PR, the status indicator (and a second request button) was moved from its original position as how it shows in the app right now, corner badge, same spot, everywhere, search, discover, sliders, person pages, collections. Adding a second row for the request button down there also eats into space the title, year, and description already need, and that gets tight fast on mobile specifically. What we went with instead is, 4K status now shows as a ring around the existing non-4k badge, in same top corner, and no new spot introduced. A second request button only shows up next to the non-4k one when both qualities are actually requestable (on mobile it shows up as a quality selector). Hovering or tapping the badge opens a small tooltip breaking non-4k and 4K status out separately, so it lets the user know about what the status indicator means (sort of like a legend). status.mp4(a change i brought after i recorded the video as quality selector and tooltip should not specify the actual resolution dimensions. For mobile): Since this is already built at this point, going back to asking you to implement it by redesigning your PR doesn't make sense, so this is the direction we're moving with. Supersedes the PR linked to this discussion, #3442 Appreciate the work and the discussion put into this though. Thank you all |
|
@fallenbagel Great news! Did you implement the admin setting on whether or not users can request a quality where another already exists? It should be super useful as some might not want to have both 4k and HD qualities for the same content. |
Read my comment on your pr. I replied about the other two issues there |
Uh oh!
There was an error while loading. Please reload this page.
Meta Discussion: Aligning on Quality Request Model (Seerr #3060 vs Overseerr #3636)
I’d like to open a discussion to align on the intended product and UX direction before continuing implementation work.
This discussion is based on two different approaches currently proposed:
Both aim to improve how quality selection and availability are handled, but they represent different underlying models.
The Core Difference
The Overseerr approach (#3636) follows the existing design pattern where:
The approach in #3060 explores treating quality as a more explicit and independent dimension.
The Key Question
Before discussing implementation details:
Should quality (e.g., 1080p, 4K) be treated as:
or
Real-World Usage
In many real-world setups:
In these cases, quality behaves more like a choice, not just an upgrade.
Limitations Observed in the Upgrade-Based Model (#3636)
What #3060 Is Trying to Address
Discussion Points
To help align on direction:
I’m happy to adapt the implementation in #3060 based on the outcome of this discussion. The goal here is to align on the correct product direction first, and then implement it in a way that fits Seerr’s design language.
All reactions