Future of the Project

[lokenx]

Hi, all!

Quick update, and request for thoughts regarding PlexRequests! As I'm sure many have noticed, I've been MIA on this project for a number of months. Thankfully @rigrassm and others have stepped up and kept the project going; adding new features, fixing issues, and dealing with bugs--for that I, and the users, am grateful for!

However, I think the project is in a state where I'm curious if it's time to sunset the original PlexRequests and recommend people move over to Jamie's fork (OMBI). It has grown rapidly since he started it and in certain areas has surpassed the original.

I'm open to thoughts and ideas from others, collaborators and users alike! If there's still demand and energy behind working on things, great! Nothing would change, and I may have time to assist more. If however, others agree it's best to sunset things, I will be sad to see it go--but as my first OSS project, I can't complain. I will also work with Jamie to see if we can export/import people's requests (however I can't promise this is feasible).

Thanks lokenx

[carnivorouz]

Whatever you decide to do, it's been a pleasure working with you and thank you for by far one of the best parts of my Plex stack.

[bezerker]

Awww.. I literally just heard about this and installed it haha. Either way, understand the logic and reason from working in the tech field myself. Good luck in whatever you decide to work on and it was a nice project for the like 2days I used it. :)

[lokenx]

Well the app won't stop working or anything just because active development has slowed/stopped--I personally will probably keep running it as the effort to move to another is not worth the hassle!

Just looking for peoples thoughts! If I did start working on it again, I'd spend a lot of time actually cleaning the code base up (it was my first real JS app and Meteor was immature when I started).

Honestly, I'd like a re-write in Ruby/Python but that's silly when there's already a .net fork. Also, while it may seem silly, I don't want my biggest project being something that's legally grey--not great for employers!

[nbyloff]

I came from Ombi to use this version because it's not on .NET. I use this on a Synology NAS with 8GB of RAM and it was extremely slow. After a few days of running, it just would stop until I reboot the NAS. Was happy to find a non-.NET version. Just was a really poor experience.

So while this version currently has less features than Ombi, it's stable and fast. I'd rather just add features (like email notifications) to this one and continue it. I don't have lots of time to dedicate either. Since there's other people willing and able to take the lead, I say let them? As the features are added, I am confident this will become a lot more popular.

Either way, was happy I found your work and worst case scenario, we all have a pretty stable version to use for the foreseeable future.

[lokenx]

Thanks for your thoughts @nbyloff! I tend to agree with most of what you've said, I guess I was feeling guilty and needed to be upfront and open with the users of the app.

I'm finishing up a new project so once that's out the door, I'll look to cleaning things up so we can look into adding some of the long standing requests, no pun intended!

[RickyGrassmuck]

On mobile right now so gonna keep this reply short. I haven't gotten to talk to @lokenx about exactly how this would happen but I'm planning on at the very least keeping the project maintained for the foreseeable future.

I'm not a JavaScript developer by any means(this project is really my only exposure to it), so further development will definitely require outside contributions.

Eventually, I would like to do a rewrite in either Python or Golang with the goal of keeping the overall look and workflow the application as close as possible to this one.

So TL;DR: can't thank you enough @lokenx for building this project and hope we get to continue working on this or other projects in the future.

Users, fear not, Plexrequests-meteor will be here for a while!

On Sun, Mar 19, 2017, 6:01 PM Nathan Byloff notifications@github.com wrote:

I came from Ombi to use this version because it's not on .NET. I use this on a Synology NAS with 8GB of RAM and it was extremely slow. After a few days of running, it just would stop until I reboot the NAS. Was happy to find a non-.NET version. Just was a really poor experience.

So while this version currently has less features than Ombi, it's stable and fast. I'd rather just add features (like email notifications) to this one and continue it. I don't have lots of time to dedicate either. Since there's other people willing and able to take the lead, I say let them? As the features are added, I am confident this will become a lot more popular.

Either way, was happy I found your work and worst case scenario, we all have a pretty stable version to use for the foreseeable future.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lokenx/plexrequests-meteor/issues/460#issuecomment-287655479, or mute the thread https://github.com/notifications/unsubscribe-auth/AQbPDbRrhlKOaXNVnfy-lAlzuCtYU34Bks5rnbO7gaJpZM4MhMil .

[lokenx]

Thanks @rigrassm, you've been an integral part as well! A Python rewrite is what people have always wanted and I've started work on it numerous times and then gave up (as well as a new cleaner JS version); I think mainly because while I like the language, I use it so infrequently and am so unfamiliar with it, everything felt like a chore compared to JS/Ruby.

I guess an important question is: continue with the Meteor version, or properly and openly start working on a Python version?

I know some have wanted it for it's portability and ease of getting up and running. SickRage, CouchPotato, and PlexPy I believe are all Python projects--I just don't know if redoing all the work has any feasible benefits besides a change in underlying technologies. When that time can be put towards cleaning the existing code base and adding new features.

[RickyGrassmuck]

Yeah, I've had the same internal debate with myself too @lokenx lol. My biggest concern is the direction that the meteor platform has taken is pretty much going to require a rewrite (albeit a majority of the logic will be reusable) to bring the project inline with the frameworks direction.

The main attraction to going with Python, for me at least, is the fact that 90% of what Plexrequests needs to function already exists in the form of well established libraries. Even Plex interaction, thanks to the work of the PlexPy devs, is already implemented.

On Sun, Mar 19, 2017, 7:01 PM loken notifications@github.com wrote:

Thanks @rigrassm https://github.com/rigrassm, you've been an integral part as well! A Python rewrite is what people have always wanted and I've started work on it numerous times and then gave up (as well as a new cleaner JS version); I think mainly because while I like the language, I use it so infrequently and am so unfamiliar with it, everything felt like a chore compared to JS/Ruby.

I guess an important question is: continue with the Meteor version, or properly and openly start working on a Python version?

I know some have wanted it for it's portability and ease of getting up and running. SickRage, CouchPotato, and PlexPy I believe are all Python projects--I just don't know if redoing all the work has any feasible benefits besides a change in underlying technologies. When that time can be put towards cleaning the existing code base and adding new features.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lokenx/plexrequests-meteor/issues/460#issuecomment-287658920, or mute the thread https://github.com/notifications/unsubscribe-auth/AQbPDZmWWUN6fqGXCWv1k7Ch07fJ_rq-ks5rncHOgaJpZM4MhMil .

[jaketame]

I tried the Ombi project and didn't like using yet another Mono application, they inheritently run with higher memory / cpu usage which I don't like. This meteor version is great, code is much lighter, more responsive etc...

I would be happy to help out with a recode onto Python where I can.

[carnivorouz]

I've solely used Ombi for the last week since my first comment and all I have to say is please god do not abandon this project. It has some nice bells & whistles I would like to see in PlexRequests but damn is it ever slow over WAN and that's with gigabit.

[crotinger]

I would agree with everyone above in the terms of stability and efficiency plexrequests-meteor is miles ahead of ombi especially on Linux systems. I would love to see a python port.

[lokenx]

What about a Ruby port? I personally would struggle to lead a Python port, haven't touched in it years, but if that's really what people are after we can start planning that instead of adding new features!

[crotinger]

I am not opposed to any language.

[Magikarplvl4]

I'm just reading this. It's making me sad. @lokenx you did and does a very good job with making plex requests. I was one of the first users that was reporting bugs and helping you to make it better. i hope you don't stop

[lokenx]

I think I'm going to have some time this week to spend planning some things out. I'm going to keep it generic enough that it would work with either Ruby (Rails) or Python3 (Django or Flask?), or really even this current project (but it's so out of date with the Meteor world, and there's no benefit staying with Meteor).

[rcross]

was the consensus to keep this project going? i've been using ombi for awhile now and considering trying this project out as an alternative. Ombi seems to be in the process of a major rewrite, which is kind of leaving the current version a bit unmaintained and no obvious clues when the rewrite might be done/available.

[qw-in]

@rcross Do you know what the rewrite will consist of? (I had a quick look but couldn't find anything obvious). I have been using Ombi for ~6months because it had some compelling features but I find the interface is clunky / slow (not sure if just me).

[Magikarplvl4]

@Qw-in the V3 is focus on stability on linux platforms and running a lot faster then the old one.

[jaketame]

@lokenx I think preference would be Flask, for the size of the app we can pull in whats required rather than have the bloat of Django

[bagobones]

Currently running both plexrequets and ombi in Docker containers to check them out right now.. O GOD IS OMBI SLOW! (it does however have much more developed user management and music support)

Unfortunately both essentially equate to manual request trackers for me right now as my automation is all built around flexget and nether projects have general or friendly outputs of the darn request lists no API to get the lists from an external app, no FLAT file output locally, NO CLI events to trigger actions etc.

I would love to see these projects focus on just being a great lightweight front end for taking requests and then making the back-ends as open as possible to integrate with various things.

[lokenx]

What’s Flexget? What backend are you using? Don’t we cover most of the major tv and movie trackers?

I am in favour of a more light weight and extensible tool, probably in python. I just have done python in a while—will see!

On Sep 24, 2017, at 01:05, bagobones notifications@github.com wrote:

Currently running both plexrequets and ombi in Docker containers to check them out right now.. O GOD IS OMBI SLOW! (it does however have much more developed user management and music support)

Unfortunately both essentially equate to manual request trackers for me right now as my automation is all built around flexget and nether projects have general or friendly outputs of the darn request lists no API to get the lists from an external app, no FLAT file output locally, NO CLI events to trigger actions etc.

I would love to see these projects focus on just being a great lightweight front end for taking requests and then making the back-ends as open as possible to integrate with various things.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bagobones]

Flexget is automation tool that includes series tracking logic etc but is prodominatly CLI / config file based and can run on very low resource systems. https://flexget.com

It also notably makes use of both Transmissions and Deluge native rename and move functions allowing you to download and rename while still seeding whereas couchpotato, Sickrage and Sonarr all depend on simlinks and file moves and originate from newsgroup practices.

It can easily consume lists from sites (with a plugin like trakt), rss fees, files etc.

[RickyGrassmuck]

@bagobones What data needs to be included in an RSS feed in order for flexget to parse it?

[bagobones]

@rigrassm That is the nice thing about flexget it is flexible. Without adding code to flexget the regexp_list should be able to pull any fields included and import them into a movie tracking / series list etc.

Having separate lists for movie and series would probably be a good idea but even that could be overcome with a type flag in the feed item that indicated if the entry was a movie/episode/season request.

So I would suggest including everything about the state of the requests in the item object, in theory the title alone should be enough but if the entire list is always output being able to check the approved and available status as filters would be important.

It should be fairly easy to build a proper managed list in flexget that is specific to plex requests and consumes the feed directly once the data is accessible as has been done with some other sites.

<item>
  <type>movie</time>
  <title>Wonder Woman</title>
  <releaseddate>May 29th, 2017</releaseddate>
  <link>https://www.themoviedb.org/movie/297762-wonder-woman</link>
  <approved>true</approved>
  <available>false</available>
  <user>testuser</user>
  <requesteddate>September 27th, 2017</requesteddate>
  <issues></issues>
</item>

[ersan]

Ombi is a nightmare full of bugs, inefficient coding, memory leaks, crashes, and features that don't work. I also found the developers to be pretty rude with their responses to issues, and I get the impression that most of them are pretty inexperienced. I just switched to this project and even though it is missing a few features (namely searching plex or radarr/sonarr to see what already exists) I prefer it.

Not to mention the whole 'v2 is discontinued and probably doesn't work but v3 isn't ready' nonsense, that is not how you run a project. I know it's free software and I probably sound ungrateful, but since I have a choice I feel like I can make those assertions.

If Ombi v3 turns out significantly better I'll switch back, but what they've churned out so far is not very promising. I would love for this project to continue if you have the time.

[Magikarplvl4]

@ersan, OMBI isn't a nightmare. The core functions are working perfectly. Yes there are bugs, but it isn't in the core functions. Also, you didn't help us out in the past with reporting bugs. Excly, you didn't report anything at all in the past about bugs in Version 2 :/ And Yes, we have memory leak problems on the Linux platform beceause we have a dependence on mono. We make a difficult decision to deside to focussing on a new version without a depandence on mono. That means, we need to rewrite everthing. @tidusjar is working for 5 months now to rewrite the core functions. It take a massive much time to do that. We decide to drop the support of Version 2 because the core functions are working and we can't fix the memory problem with mono without re-write everthing. So instead of fixing Version 2. We decide to start all over again and set the basic right. i think you not understanding how mutch time supporting and maintain takes. Its not "nonsense" just a hard decision we maked. Also, its opensource, You are free to patch the bugs on your own and share it with the rest.

Ombi v3 is completed rewrited. I'm not sure what you meaning with "not very promissing". Are you sure you are running v3 before? We got a lot of postive messages about v3. We are now working to get a open beta up and running. First we focussing on fixing bugs we can found in V3 with a small group. Next step will be a open beta.

I therefore assume that you will be able to help us improve the software in addition to criticism only.

[ersan]

@PotatoQuality I'm not a .NET developer, I dabble but for the most part I'm a web developer. If I see a bug I'm capable of fixing I'll submit a pull request. More likely I'll start contributing to this project as I'm more familiar with the language. I appreciate the work you guys are doing but I have had bad experience after bad experience with Ombi, for instance at the moment my V2 installation freezes after 5 or 6 hours of running with no error and I've just given up on it. I have also used mono applications that do not have memory leaks, so I'm not sure what you mean by that. Other people seem to share the same sentiments based on the responses on this thread.

I tried to use V3 before I realized it was incomplete (because that isn't made clear on the github page where there should be a note at the top of the README about the project status so other people stop making the same mistake and you stop getting new issues that you have to close, which I would have raised an issue about but apparently issues involving V3 are forbidden) and it was not functional, I'm not sure what kind of assumptions I can make if it's unfinished and not working, but based on V2 and what I've seen from V3 so far I don't have very high hopes - I don't think .NET should be the platform for this project but I certainly understand limitations in language flexibility. I would be overjoyed to be proven wrong.

As a side note, I did submit a bug to Ombi V2 at one point that got fixed, and then broke again, and never received a response after I updated the issue.

[tidusjar]

@ersan If you have any issues please feel free to jump on Gitter to discuss anything with me, or raise an issue on the Ombi github and we can continue the discussion on there and not hijack this issue.

[lokenx]

Sorry to hear you've been having issues with Ombi, I know Jamie and them are hard at work on a new version that should hopefully solve some of the issues!

I personally don't have the time to put much into this version, but I know @rigrassm is very much holding the fort down single handedly.

Honestly, a python version would be ideal--I've started it multiple times, but I don't use the language on a day to day basis that it's just hard to get off the ground! Plus there's the whole Python 2 vs 3 silliness that last I saw is still silly.

I'd personally gladly do it in Ruby or Elixir as they're the languages I use (or vanilla Node not Meteor) but then Windows becomes an issue! A hosted version would be interesting, but I feel like the users of the product are ones to baulk at that and rather self host (and it could get complicated opening up ports and such for everything to talk to one another).

Personally I use my own installation rarely, and am thinking of chucking my Plex server out and just having it for me and my immediate family--the maintenance is time consuming!

[RickyGrassmuck]

It's definitely not all me holding down the fort, had a few pull requests that came from others that tackled a couple annoying like bugs that I hadn't been able to get to as well as one that added the discover feature for movies (don't remember the Contributor off the top of my head but he/she did a great job on that one).

I just want everyone to know that as long as I'm still using Plexrequests as my front end request manager I'll be at least doing maintenance in the project with the occasional improvement and feature additions added in. As always, if others want to step up and work on something, be it a bug, new feature or just some general improvements, I will definitely get the changes merged provided they are done well. The more work and time put in by others (especially in the bug fixes and general improvement areas) usually will result in me being able to work on implementing more new features that a large majority of our users will see benefits from.

Going back to the rewrite topic, I would love to see this project done in Python (Python 3 specifically, 2 is dead and absolutely should not be used for a new project). I have wanted to do this for a long time but the one thing that has always stopped me from really jumping into it is the fact that I don't do front end development outside of being able to make minor tweaks to existing code. The back end work would actually not be very hard at all and I would be willing to do it if I had someone that could handle the front end design and implementation using one of the Python templating engines.

Sorry for the wall of text, lots of stuff to talk about and I have a bad habit of doing it in big chunks lol.

[lokenx]

If you’re interested in doing a python backend that provides an API that can also serve some front end code, could do a Python and Vue combo?

I haven’t seen an integration of those two but I’m sure it’s been done by someone? That would also allow an API that others can hook in to (flexget?)?

Otherwise just a python template language and some JS would work too obviously, which would be simpler. I can do front end fine (and backend in other languages) just my python is real rusty.

Worth a thought at least!

On Sep 28, 2017, at 17:06, Ricky Grassmuck notifications@github.com wrote:

It's definitely not all me holding down the fort, had a few pull requests that came from others that tackled a couple annoying like bugs that I hadn't been able to get to as well as one that added the discover feature for movies (don't remember the Contributor off the top of my head but he/she did a great job on that one).

I just want everyone to know that as long as I'm still using Plexrequests as my front end request manager I'll be at least doing maintenance in the project with the occasional improvement and feature additions added in. As always, if others want to step up and work on something, be it a bug, new feature or just some general improvements, I will definitely get the changes merged provided they are done well. The more work and time put in by others (especially in the bug fixes and general improvement areas) usually will result in me being able to work on implementing more new features that a large majority of our users will see benefits from.

Going back to the rewrite topic, I would love to see this project done in Python (Python 3 specifically, 2 is dead and absolutely should not be used for a new project). I have wanted to do this for a long time but the one thing that has always stopped me from really jumping into it is the fact that I don't do front end development outside of being able to make minor tweaks to existing code. The back end work would actually not be very hard at all and I would be willing to do it if I had someone that could handle the front end design and implementation using one of the Python templating engines.

Sorry for the wall of text, lots of stuff to talk about and I have a bad habit of doing it in big chunks lol.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[qw-in]

So, I have been kicking around this idea about the possibility of redesigning a request system around comments & user interaction. I know that ombi and pr both support it to some degree but starting with a comment timeline (github issues are a nice example) on the media page could really help with making it clear to users on how to report issues with downloads or even discuss requesting a show. I think this along with a nice big public calendar of upcoming content could distinguish this system from ombi in more ways than just speed (especially considering that is meant to get fixed). Of course it would have all of the current search / request / permissions features as well. Figured I would throw this out there and see what interest levels are like

[bagobones]

Looks like Ombi v3 clears up the performance issue in Docker / Linux in general... Still interested if the projects diverge and offer something different but it looks like I will be running Ombi for now.

[AppleTechy]

Can we get support for Radarr? Also, I checked the wiki but didn't see an instruction guide for MacOS, is there anything special required? Or can I proceed as if it is a linux install?

[RickyGrassmuck]

Radar support has been available for quite a while now.

Regarding installing on OSX, just follow the Meteor instructions for installing Meteorjs on OSX and then the rest is the same as the other platforms.

On Sun, Nov 26, 2017, 6:27 PM AppleTechy notifications@github.com wrote:

Can we get support for Radarr? Also, I checked the wiki but didn't see an instruction guide for MacOS, is there anything special required? Or can I proceed as if it is a linux install?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lokenx/plexrequests-meteor/issues/460#issuecomment-347051558, or mute the thread https://github.com/notifications/unsubscribe-auth/AQbPDUDAgoUGZW0GQNiAzSH8VEME7p1Yks5s6gHqgaJpZM4MhMil .

[AppleTechy]

Alright thanks. In the readme file it didn’t say that it supports Radarr so that’s where my confusion was. Thanks for the response.

On Nov 26, 2017, 6:42 PM -0700, Ricky Grassmuck notifications@github.com, wrote:

Radar support has been available for quite a while now.

Regarding installing on OSX, just follow the Meteor instructions for installing Meteorjs on OSX and then the rest is the same as the other platforms.

On Sun, Nov 26, 2017, 6:27 PM AppleTechy notifications@github.com wrote:

Can we get support for Radarr? Also, I checked the wiki but didn't see an instruction guide for MacOS, is there anything special required? Or can I proceed as if it is a linux install?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lokenx/plexrequests-meteor/issues/460#issuecomment-347051558, or mute the thread https://github.com/notifications/unsubscribe-auth/AQbPDUDAgoUGZW0GQNiAzSH8VEME7p1Yks5s6gHqgaJpZM4MhMil .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.