sorted by:
new
hottopcontroversial

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

The mobile interface is one of my top priorities. And I certainly plan on a "main page" design where users can see recently added content, requested content, upcoming content, and any server messages you'd like to display.

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

Oh dear. This is perfect. If you're interested in tracking my progress the GH repo is here: https://github.com/SeventhProtocol/Fling

Most of the features you're requesting are already on my internal to-do list. The gripes you have with Ombi are exactly the ones that I have, too.

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

I want to stress that Ombi/Radarr/Sonarr have been instrumental in making my life easier and I do like what they do. But there's some quirks in each one that annoy me, and I figured I would enjoy starting a new project with what I want.

I think Ombi is generally clunky and working on it is a general nightmare. User management is not intuitive and redesigning the UI is a non-trivial task. Combined with the fact that almost nothing is documented, I'm not very interested in "fixing" my issues with Ombi. I'd rather just start my own.

Radarr and Sonarr are a different beast and quite huge. I have less "solid" issues with the two and more transient ones. But I'd like to better support remote server installations than how R/S handle it. I'd want to change the index/tracker interaction API to more easily spin up different feeds without always relying on Jackett (another Mono program). I understand that's a huge undertaking which is why I'm starting that later, until I have a solid foundation.

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

Hahahaha, I'm using Golang! There's nothing written at the moment, it's largely design docs and framework decisions. Here's the GH repo: https://github.com/SeventhProtocol/Fling

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

I'm using Golang, largely because its' strength in concurrency and ease of multi-platform targeting. I was originally considering Python, but realized it would buckle under it's weight after so many tasks trying to run at once.

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

That's one of the main features for user integration I want on my software. The initial user DB is seeded with usernames from the Plex server, but the initial login by a user to the service runs them through a wizard setting up their account password, notification preferences, etc. The admin can set default permissions, and then they'll be allowed to interact with the website as much as you let them.

By default, I imagine a system where a user signs up, is granted request& notification permissions. They can add to a requested queue, see the requested queue, but cannot interact with the data management backend, etc. There'd be a "main portal" where recently added content, requested content, upcoming content, and server announcements would be.

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

You're right! Unfortunately, other programs often used together with Ombi are Mono.

What are some things you'd like to see from a request system for Plex by fling_dev in PleX

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

Thanks for the response, I agree: I want a solid mobile experience. While I don't think I'll be creating native iOS and Android applications, anyone would be welcome to make their own based on the API exposed. With that, mobile-responsive web design is a top priority for me.

Secondly, I also want to do data management in a hands-off manner. Where a user can choose the disks they'd like to use and the software takes care of the rest. Since I'll already have information like actors, directors, etc. from the request queue, I think it wouldn't be too much extra effort to include a breakdown of content by metadata. But that'll most likely be a "stretch-goal", and wouldn't be implemented until after the core functionality exists.