If you have not already, we suggest setting your Plex username to something else rather than email which is displayed on your posts in forum. You can change the username at https://app.plex.tv/desktop#!/account

Welcome to our forums! Please take a few moments to read through our Community Guidelines (also conveniently linked in the header at the top of each page). There, you'll find guidelines on conduct, tips on getting the help you may be searching for, and more!

We'll be moving the forums to Discourse! Here's the scoop

We’re moving our community forums to Discourse in June! After researching and testing several solutions to address the shortcomings of our current forums platform, Discourse became the clear winner. It provides many advantages, including flexibility, configurability, tag-based filtering, and a more modern conversational approach. The new platform is modern, feature-rich, stable, and brisk.

TL;DR

Primary transition work is happening in May with the launch expected in the first half of June.

Features galore! We've detailed some of the new features we're excited about below, but here's a recap:

Flexible posting drawer: The auto-saving drawer lets you reply to a thread while reading, referencing, or quoting another topic. See who is typing in real-time and load replies (and their edits) dynamically even as you write, without refreshing. Get a real-time preview of your formatting, too.

Dynamic thread reading: No pagination, replies load dynamically as you scroll. A timeline slider lets you jump to a specific moment in time, or to the end. The URL is coded with your exact location in case you want to share or reference a specific reply or a place in time in the discussion. It's brisk!

Topic details at a glance: An expandable drawer shows thread stats, community participation, and a roundup of the links posted in the replies.

Control over notifications: Granular control over how you are notified for subscribed topics, categories, and tags, with different options clearly explained.

Smart search: More relevant results in less time using a combination of search terms, categories, and tags to refine results in one step.

Forum usernames: We'll be separating the forum user identity from your regular Plex account. Effectively, this means that you'll have a separate "forum username" in additional to what you may already have been using with your Plex account (and thus in the existing forums). You'll be able to see and edit your forum username upon first login to the new forums. Discourse has stricter username requirements, that include not allowing emails, special characters, or spaces.

Read on for the complete details!

What’s happening?

The title says it all, right? Ok, not quite . We’re excited to share with all in the Plex community that we will be moving our forums over to Discourse in June. The community is an incredibly important part of Plex and we want to ensure smart tools are available for users to get the full benefit of participating in the community, make it easier and simpler to get better answers in less time, while bringing critical functionality to help users, Ninjas, and employees identify and track issues. We’re aiming to solve a number of limitations the existing forums platform has, that make it harder for users, Ninjas, and employees to learn from others in the community.

This is a big move for us that we’ve been working on for some time now. We’ve researched a bunch of solutions, including exploring building a custom platform in-house. We looked at other communities to see what worked for them and what didn’t. After much research and testing, we landed on Discourse as the ideal platform that would give us the flexibility, customizability, expandability, and reliability we need in a community platform.

We’re also taking the opportunity this move presents us to clean up the forums, improve the organizational structure, making it simpler to find your way around and discover new and interesting things to read about. All posts and content that exist in the forums through the day of launch will be migrated. We realize that things will look and function differently, but we hope to make this transition as smooth as possible by providing advance notice — including lots of details on the “what”, “why”, and “how” — and preparing users, Ninjas, and employees by providing user guides. Understandably, there will likely be questions along the way. Feel free to respond in this thread to discuss and ask anything related to our move to Discourse.

Plan overview

We're starting the forum migration process with a focus on communication, design, configuration, data migration, and testing – basically everything we need to do to ensure a seamless transition for users and data. All of this is planned to be delivered in June.

Once we've successfully gotten our forums running and available on Discourse and let folks settle in a little, we'll continue working to make the experience even better for everyone. We won't be going into specifics yet, but we're definitely looking to level up the integration between content in the forums and other areas, as well as bringing in new tools to help users find what they need or get assistance with issues they're experiencing.

For our initial efforts and work, we'll be focusing on:

Timing

Planning really ramped up in March as we found a clear winner and started making decisions based on our research and experimentation. Our sights are set on the first half of June for launching this!

Migrating the data

A lot of forum data has accumulated over the years! We’re coordinating with our existing platform provider to ensure we get all of it out; images, file attachments, the works. This includes multiple data dumps along the way and a final delta on launch day. We expect we’ll only need put the forum into read-only mode for a few hours on launch day, though it could take as long as a business day. On the Discourse side, we’re working with our account representative and their migration engineering group that has been assigned to us. They’re experienced at working with data coming from our existing provider and will ensure all data moves as expected, including URL references to other threads. It will all link back up.

What about GDPR?

We’re paying careful attention to Europe’s new privacy law with regard to this move. We are ensuring that our current provider will delete all user records by the time our contract with them ends on July 8, 2018. This includes backups. We are also ensuring GDPR compliance with our new provider, Discourse. They are US-based and hosted and have completed their Privacy Shield certification.

Back end nuts and bolts

We’re aiming for a smoother single sign-on (SSO) experience than what we have now. The URL (https://forums.plex.tv) will remain the same, and all links within threads will redirect. Discourse does have stricter username requirements (covered in more detail further below) and we’ll be building an interstitial page to guide users through updating their username, if it will be necessary (example, no spaces or email addresses). We’re introducing Forum Usernames as part of this, which will add increased privacy control over how other users see your Plex username. You’ll be able to have a separate username for the community forums, if you so choose. Read further down under Forum Usernames for more details.

Design and configure

Our top design priority for the community forums is to make sure there is a high degree of readability and comfort for prolonged reading and writing sessions. We’ll leverage feedback from our community to make needed adjustments after launch. Expect to see some of the same customizations we did with our current provider, such as color-coding Ninja and employee posts. We’re aiming for a custom theme that is less busy, less confusing, and easier to find things.

Sentiment and feedback

After launch, we’ll be monitoring the new Discourse platform for user reactions as well as inviting everyone (yes, users, Ninjas, and employees) to take part in a survey to help us complete our planning for future work after the initial launch.

Forum usernames

One notable difference between Discourse and our current forum platform (and our regular Plex accounts, for that matter) has to do with username requirements. Broadly speaking, Discourse has much stricter guidelines for usernames, since the only characters accepted are letters, numbers, and underscores. More specifically, this means:

“Special characters” and foreign-language characters, including accents, are not valid (which means that email addresses are not valid)

Spaces cannot be used (they'll be replaced by underscores)

Usernames must begin with a letter or number

Periods, hyphens, and underscores are ok as long as they are not the first or last character

This is definitely quite different from our current situation, where none of those restrictions are in place. As such, it means that the usernames being used in the forums for many existing users won't be valid for Discourse.

So, what's going to happen with usernames?

As part of our migration to Discourse, we're going to be taking this opportunity to separate the forum user identity from your regular Plex account. Effectively, this means that you'll have a separate "forum username" in additional to what you may already have been using with your Plex account (and thus in the existing forums).

To make this as painless as possible for users, there will be a short, one-time process the first time you sign in to Discourse, which will allow you to choose or verify the username to use with Discourse. To make it as simple as possible, we'll be working to help provide suggested usernames where possible, assuming an existing username isn't already valid. Users can also always go back later and update the username, if desired, of course.

Improvements headed your way

Over the past (almost) three years, our community has shared feedback on many issues or shortcomings that have been experienced with the current platform. We’ve read them and they have helped to shape our planning. Here are some of the great new features and functionalities to expect from Discourse. This only covers some of the improvements and new features we'll be gaining from our move to Discourse. Please keep in mind these screenshots are based off of the stock installation, prior to design and customization.

Stacks and Tags

Discourse was co-founded by one of the co-founders of Stack Overflow, Jeff Atwood. As such, there is a decidedly “stack” approach to the organizational and navigational structure for Discourse. If you’ve used Stack Exchange or Quora, this will be familiar. Stacks are essentially topic lists that can be (or have been) filtered, using a combination of categories and tags. Stacks can be filtered using only a tag, which can be useful to see if an issue is arising across multiple categories.

Flexible posting drawer

Posting doesn’t require you to be viewing the topic you are replying to. Navigate to other topics (even across categories) without losing your progress. Reference and quote across topics and categories. The drawer can stay open as you navigate or be closed without losing your post. Use the included WYSIWYG editor or markdown to add images, links, and to style your post. Next to your post, you get a real-time preview that can be hidden if not desired. If new replies get posted to the topic you are replying to, those get dynamically loaded (even their edits) without having to refresh or wait until after replying to see what's been posted. Discourse also shows you who is typing in real-time, similar to chat apps.

Dynamic thread reading

Say goodbye to static page loading and pagination and hello to dynamically loaded topics with simple tools for visually moving through time. Want to read more replies? Keep scrolling at your own pace. Want to jump to the end or a specific point in time? Drag the date slider to where you want to go, or click right on your desired destination. The URL is coded with your exact location in case you want to share or reference a specific reply or a place in time in the discussion.

Topic details at a glance

Located below the first post in a topic is an expandable drawer with the topic’s details, including usage stat, frequent posters, and a shortcut to links mentioned in the topic. Quickly collapse the drawer to reduce vertical space used.

Granular control over subscription notifications

More options with less complexity. Subscribe to a category, tag, or an individual topic. Control your notifications for each subscription based on how involved you want to be. Straightforward descriptions help in making the right choice. You can also use these subscription options to “mute” categories and tags so that no notifications are received and so they don’t show up in the topic listings.

Suggests existing topics

A tooltip appears as you write a new topic providing suggestions for existing topics that might be relevant. This can help with reducing duplicate topics and point users in the right direction without having to context-switch to searching. If not desired, simply close the tooltip to make it disappear.

Suggested topics also appear at the very bottom of each topic. They’re out of the way, not adding clutter, but easily reachable by scrolling manually to the end or using the date slider to jump to the end.

Automatically expandable links

Bring more context and information to your post with automatically expanding links. The preview pane shows you what it will look like in your topic, and you can always hide the preview if you prefer not to see it. You can also prevent expanding links by adding a space before the link.

Summarize a topic

Use the Summarize button to condense long topics to just the most interesting and popular posts. The estimated read time can be helpful in giving you idea how involving the topic will be, if not summarized. Summarizing is predominantly based on the number of likes a post gets, with the top 10% most liked posts in the topic getting included in the topic summary.

Smart search with categories and tags

Enjoy better searching with auto-completion, suggestions, and fuzzy logic to handle misspellings. This allows you to drill down to a specific category and/or tag to get closer to what you are looking for in fewer steps.

Voting and tracking for suggested features

We will be implementing a new voting system for feature requests. This will mean you need to re-vote for your favorite feature, but we are also opening up voting to all members now. Voting on feature suggestions is more robust with clear totals by the topic title. Votes are visible in the topic itself and also in the topic view (which are also sortable by vote count), helping with tracking popularity. While voting for feature requests is not a guarantee they will get implemented, they do provide us with insights from the community that help shape development planning.

Categories & Tags

It’s not just about fewer categories. It’s about categories that make more sense and don’t necessitate “drilling down” to look for what you want, only to end up in the wrong place. We’ll be reducing the hierarchical levels so there are only 2 levels of categories to leverage a flatter (but not completely flat) organizational structure. Pre-defined tags will be used for additional organization. This will involve some moving of threads. Here’s an example of how an issue will be organized by category and tags:

A user experiences Live TV playback failing on their Apple TV and they have a Mac PMS. The user could post their issue in one of these categorical options: Plex Players > Streaming Devices or General > Features since the issue involves both an Apple TV and the Live TV & DVR feature. By adding the apple-tv, livetv-dvr, and mac-server predefined tags, the issue can be discovered (and filtered) by users, Ninjas, and Employees looking at issues related to Apple TV, Live TV & DVR, or Mac servers. The thread is now associated by server/client platform and feature and thus easier to find, both for other users and Plex employees.

In making the community more open to all members, we will no longer have areas exclusive to Plex Pass subscribers. Once we transition to the new platform, all categories in the forum will be accessible by all members of the community. One caveat is that the beta testing categories will be readable by all but only those participating in the betas will be able to post in them.

Stay tuned

We’re excited, and we hope you are too! Stay tuned for more updates and resources to help make the transition as smooth as possible. Feel free to use this thread to ask any questions or discuss the move.

Since feature requests are going in for all members, maybe there should be a space for smaller feature requests. I don't know what you would call it. Things that may not be bugs, but also not tentpole features that may get overlooked by a larger audience and devs. Like the fact you can't reorder libraries and have to use spaces to achieve that, and then it looks weird on some clients, like the Apple TV.

@kinoCharlino said:
In making the community more open to all members, we will no longer have areas exclusive to Plex Pass subscribers. Once we transition to the new platform, all categories in the forum will be accessible by all members of the community. One caveat is that the beta testing categories will be readable by all but only those participating in the betas will be able to post in them.

Please note the Legal notice for the usage of Google Analytics in my Channels.

We're working with Discourse's migration engineer as well as an engineer on our side on moving the accounts over. If the username is not in conflict with Discourse's username rules, then it will transfer over (so for instance, kinoCharlino will remain mine) and will sync up with plex.tv via our single-sign on protocol, where the account info originates on plex.tv and any changes to the account made on plex.tv (that relate to the forums) get synced up with Discourse. For those that have usernames that don't meet Discourse's requirements, they will have to edit their so it fits their parameters. In the case of MovieFan.Plex, Discourse will by default change it to MovieFan_Plex, but that person will be able to change it to something else upon first login to the new forums.

@derato said:
Since feature requests are going in for all members, maybe there should be a space for smaller feature requests. I don't know what you would call it. Things that may not be bugs, but also not tentpole features that may get overlooked by a larger audience and devs. Like the fact you can't reorder libraries and have to use spaces to achieve that, and then it looks weird on some clients, like the Apple TV.

@derato, thanks for the suggestion! So the feature requests should never be about bugs, per say, they should be about functionality that you would like to see added. For example, if sync were to break on a given platform, we wouldn't want a feature request for it, we would want to file a bug internally and point to one or more forum threads where it is being discussed and documented. The new tagging approach we're going to use will help get that thread into more prominent view of engineering in a way that hasn't worked very well for us on our current forum platform (for users or engineers).

So what I'm gathering is you would like to see feature suggestions split up into 2 areas: big ones and little ones, right? It's something we can consider, though I will say in our move to Discourse, one of our goals is to simplify the forums so it's easier for users to find things. More categories, more separation, would work against that goal. That doesn't mean we will never add a new section, just that we want to be very purposeful in doing it.

My question for you is, how would users determine if their feature request is a big one or little one? I could see a lot of miss-categorized feature requests because it is based on someone's own perception of what they see as big or small. One of our intensions for the feature suggestions section is to make it cleaner and easier to judge popularity (using better voting features in Discourse). I would be curious to see if the new format addresses this issue naturally, or if we do need to separate feature requests. We could use tagging to achieve this, similarly to how engineers tag an internal ticket with priority. It's just that I could see users tagging something as "big" just to get more eyes on it and a better shot at getting it implemented.

Like the fact you can't reorder libraries and have to use spaces to achieve that, and then it looks weird on some clients, like the Apple TV.

I do really like where you are thinking with this one and I think you will be pleased with what's to come.

@derato said:
Since feature requests are going in for all members, maybe there should be a space for smaller feature requests. I don't know what you would call it. Things that may not be bugs, but also not tentpole features that may get overlooked by a larger audience and devs. Like the fact you can't reorder libraries and have to use spaces to achieve that, and then it looks weird on some clients, like the Apple TV.

Adding to what I wrote above...

From my perspective, I would want to go to the product team with clear, actionable data from votes, especially if users were limited by the number of active votes they had to spend. What I'm referring to here is providing each user with a limited number of votes, forcing them to spend them on the feature requests that truly matter the most to them (as opposed to voting for everything that remotely looks cool). I think of it as voting for everything = voting for nothing and really doesn't give us a good sense of what the community actually wants. When a feature request gets implemented, the votes get returned to everyone who voted for it so they can be spent again on another feature request. In this scenario, we would be able to show the product team exactly how the community chose to spend their votes, which is a different message than saying, "these 10 users have been posting a lot about the absence of X functionality." We could show that when forced to choose, this is what the community values the most.

I'd like to hear thoughts on us adopting this voting method and what you think would be a good number of active votes to allow each user to work with.

Currently the visibility of all Plex Pass forum posts is limited to paying customers or employees, not the general public. If I'm understanding the migration process correctly, every post will be readable after moving to Discourse.
So question 1:
Will you give users the option to delete their existing Plex Pass forum posts in compliance with Article 17 of GDPR? Or are you arguing since one can now change the forum username, it's not "private" data?

Which brings me to question 2:
If I'm changing my username will all the @ mentioning and quoting of my name be replaced by the new name? Essentially giving one a new identity? Or is it a "normal" rename which simply changes the username but leaves post contents from other members untouched (essentially revealing that member X changed his name to Y).

Question 3 for the new "universal" categories:
Are tags required in order to open a new thread? Otherwise I fear the new forum will be unreadable because in my experience with other forums maybe 5% voluntarily use tags.

@kinoCharlino said:
From my perspective, I would want to go to the product team with clear, actionable data from votes, especially if users were limited by the number of active votes they had to spend. What I'm referring to here is providing each user with a limited number of votes, forcing them to spend them on the feature requests that truly matter the most to them (as opposed to voting for everything that remotely looks cool). I think of it as voting for everything = voting for nothing and really doesn't give us a good sense of what the community actually wants. When a feature request gets implemented, the votes get returned to everyone who voted for it so they can be spent again on another feature request. In this scenario, we would be able to show the product team exactly how the community chose to spend their votes, which is a different message than saying, "these 10 users have been posting a lot about the absence of X functionality." We could show that when forced to choose, this is what the community values the most.

I'd like to hear thoughts on us adopting this voting method and what you think would be a good number of active votes to allow each user to work with.

I like that. Just use the old ESC voting scheme (12, 10, 8 - 1) and make sure that feature requests get actually implemented so the users get back their voting points.

Please note the Legal notice for the usage of Google Analytics in my Channels.

First off, my bad on missing the point about the change in plex pass forums.

@kinoCharlino I agree, clean and simple would be the way to go. And having users pick what bucket to put the feature request in could get messy as well. Maybe that's an internal thing Ninja's and Employees would sort out.

Spending votes could be interesting. I'm not sure how you administer that, with various duplicate entries. Like I vote on something, it becomes a feature, but because I voted on a duplicate post, maybe I don't get my vote back. But I like the idea of users seeing their votes actually working.

My point of all this is to just in hope the smaller items get some attention too. And while of course the company needs to prioritize it's resources, it would be nice to know that some of these smaller items get on the whiteboard as well. Obviously the Grid EPG is important, and takes resources, but maybe my moving libraries example is smaller, but takes less resources.

I try to be a good soldier, checking and voting on features frequently. There's at least a half a dozen times I've searched for a "small" feature request only to find it's been a request for years, but either just wasn't seen or is important enough.

@Wiidesire said:
Currently the visibility of all Plex Pass forum posts is limited to paying customers or employees, not the general public. If I'm understanding the migration process correctly, every post will be readable after moving to Discourse.
So question 1:
Will you give users the option to delete their existing Plex Pass forum posts in compliance with Article 17 of GDPR? Or are you arguing since one can now change the forum username, it's not "private" data?

Users will have the ability to delete any of their own posts themselves.

Which brings me to question 2:
If I'm changing my username will all the @ mentioning and quoting of my name be replaced by the new name? Essentially giving one a new identity? Or is it a "normal" rename which simply changes the username but leaves post contents from other members untouched (essentially revealing that member X changed his name to Y).

I need to get back to you on this one. I've reached out to Discourse for clarification.

Question 3 for the new "universal" categories:
Are tags required in order to open a new thread? Otherwise I fear the new forum will be unreadable because in my experience with other forums maybe 5% voluntarily use tags.

We're using a combination of categories and tags in the structure. The categories will provide high level organization while tags will be for identifying the details. We're not going to be requiring tag usage, but it will be pretty obvious that we will highly recommend them. Lets use a Windows PMS topic as an example. If a topic is created without any tags, it will get filed under the Plex Media Server category and Computers subcategory. We're actually ok with that because it puts all issues for PMS in one place, separating those out from NAS devices, making it simpler for users, Ninjas, employee to research what's going on with server issues, as they don't have to go from category to category. Tagging the topic with windows-server would give users the ability to sort-out PMS topics by platform using filters. Search results also benefit from tags, although Discourse's search is pretty darn smart, regardless.

Tags are best suited for establishing relationships for a topic. Using a similar PMS scenario, a user experiencing an issue with Windows PMS while using Live TV & DVR on an iPhone would tag it as such: windows-server, livetv-dvr, ios. That would give a clear picture as to where the impact of the issue is, across our ecosystem, and give Ninjas and employees the ability to more easily discover and track those issues. With our current forum platform the issue would have likely been filed in Plex Media Server > Windows and an employee working on Live TV & DVR or iOS may not have come across it. QA can use this help determine if an issue is isolated or spread across multiple areas. Sure, you can add tags with our out current forum, but its a big mess with countless derivative forms of the same tag. That's all great IF users add tags, as you mentioned. We're going to highly encourage tag usage and were planning on doing these things to help users get the most out of the new forum platform:

Communicate to users early on, as we're doing now

Provide a user-guide that walks users through the core features, including posting and filtering with tags

Show simple instructions on how to use tags within the platform, at the point where they are requested

Use the 1st and 2nd level category descriptions to provide a list of the most relevant tags (though for flexibility, most tags will not be limited to being used in specific categories)

Use visual/text-based indicators at tag input fields to better set the expectation

@derato said:
First off, my bad on missing the point about the change in plex pass forums.

@kinoCharlino I agree, clean and simple would be the way to go. And having users pick what bucket to put the feature request in could get messy as well. Maybe that's an internal thing Ninja's and Employees would sort out.

Prioritizing, triaging, putting things into buckets – all of that does happen internally.

Spending votes could be interesting. I'm not sure how you administer that, with various duplicate entries. Like I vote on something, it becomes a feature, but because I voted on a duplicate post, maybe I don't get my vote back. But I like the idea of users seeing their votes actually working.

We want to fix the problem of duplicates, first! That seems to be the root of the issue here. If users see duplicate feature requests, they will be able to report them (much as they can now) and we will happily merge or close, as necissary. As for spending votes, users can un-vote (literally just by clicking the vote icon again) on any open topic and get tha vote back. That's good for changing your mind, or to recoup your votes on duplicate topics. Maybe you see a new one you would rather vote for, so you remove votes from one that you are less interested in. It's fairly flexible in it's "stock" form, though we are exploring the possibility of doing further customizations after launching. In its current form, you can only vote once for a given topic. I'd like to look into the possibility of giving users the ability to allocate multiple votes for a give topic, if they really wanted to stand behind one so much that they would sacrifice votes for other ones.

My point of all this is to just in hope the smaller items get some attention too. And while of course the company needs to prioritize it's resources, it would be nice to know that some of these smaller items get on the whiteboard as well. Obviously the Grid EPG is important, and takes resources, but maybe my moving libraries example is smaller, but takes less resources.

What's GRID EPG? I have never heard such a thing? I don't want to go off-topic, so I'll stick to your idea. I write about advantages to the user community, but one big piece of this, and what led us to Discourse, is the advantages it provides us in helping to get better info out of the user community. There's a lot of noise in the forums and it's time consuming to sift through the noise to get at the gold nugget we're after. I think this is actually a user issue to, as that can frustrate those who aren't interested in the banter and debate. But for employees, the improvements coming for how we post, vote, and track feature suggestions is going to help us get a clearer picture of what users want, even if the feature requested is not complex. Ultimately we won't be able to make that whiteboard available to the public, but we do believe better tools and better process will help get more consideration for feature requests.

One clarification on usernames. Numbers, periods, hyphens, and underscores are allowed, as long as they are not the first or last character. So MovieFan.Plex won't have to see his username changed to MovieFan_Plex or something else. I'll update my post to reflect that.

Question 3 for the new "universal" categories:
Are tags required in order to open a new thread? Otherwise I fear the new forum will be unreadable because in my experience with other forums maybe 5% voluntarily use tags.

More on this one... we do have the option of enforcing tagging on a per-category basis. We're discussing it, and think it might be best to require tagging for some categories, while leaving things more open and free in others. For example, we could require tags for the Plex Media Server > Computers category, with tags including: windows-server, mac-server, linux-server, linux-server-tips, freebsd-server, dlna-server. We will also have tags for player apps and features.

Will the new forum also help the people supporting some of the big addons here? I am thinking Tautuli as an example.
At the moment they have to have everything in a single thread so they can keep track of issues but that makes it unwieldy for them, and users trying to keep up

@borochris said:
Will the new forum also help the people supporting some of the big addons here? I am thinking Tautuli as an example.
At the moment they have to have everything in a single thread so they can keep track of issues but that makes it unwieldy for them, and users trying to keep up

The third party app section will pretty much stay like it is now. except the ones that are currently sections like OpenPHT will be tags like other sections will be turned into. You would only have to filter on that tag. there will be a third party>apps and tools section to browse but not for individual apps

You should really be posting issues with Large-"ish" apps like Tautulli, Infuse, etc, in their own forums or primary support channels. Most have github or their own forums/chatrooms http://tautulli.com/#support

We are trying to keep the number forum sections to a minimum. We will take on a case by case basis just like now if will make a tag for a particular third party app

@Wiidesire said:
Which brings me to question 2:
If I'm changing my username will all the @ mentioning and quoting of my name be replaced by the new name? Essentially giving one a new identity? Or is it a "normal" rename which simply changes the username but leaves post contents from other members untouched (essentially revealing that member X changed his name to Y).

What I’ve been told from Discourse is that by default, username changes during the migration process do not account for broken mentions right now. They are, however, looking into the possibility of amending their import script to support this for us.

@derato said:
Since feature requests are going in for all members, maybe there should be a space for smaller feature requests. I don't know what you would call it. Things that may not be bugs, but also not tentpole features that may get overlooked by a larger audience and devs. Like the fact you can't reorder libraries and have to use spaces to achieve that, and then it looks weird on some clients, like the Apple TV.

Adding to what I wrote above...

From my perspective, I would want to go to the product team with clear, actionable data from votes, especially if users were limited by the number of active votes they had to spend. What I'm referring to here is providing each user with a limited number of votes, forcing them to spend them on the feature requests that truly matter the most to them (as opposed to voting for everything that remotely looks cool). I think of it as voting for everything = voting for nothing and really doesn't give us a good sense of what the community actually wants. When a feature request gets implemented, the votes get returned to everyone who voted for it so they can be spent again on another feature request. In this scenario, we would be able to show the product team exactly how the community chose to spend their votes, which is a different message than saying, "these 10 users have been posting a lot about the absence of X functionality." We could show that when forced to choose, this is what the community values the most.

I'd like to hear thoughts on us adopting this voting method and what you think would be a good number of active votes to allow each user to work with.

My answer would be (3) votes any more and there would be dilution of relevance or applicability.

@SE56 said:
My answer would be (3) votes any more and there would be dilution of relevance or applicability.

You're strict! I was thinking 10 votes, but am very much open to considering less or more, just not a ton more.

I agree that numbers should be small, very small, but I doubt that it will ultimately be any better than the current system as so much is hidden from Plex users. The decisions Plex makes about features are never disclosed or discussed with users and Plex has said that "power users," which make up a good part of those that post here, do not represent the true user base so their input does not really count for much.

I just hope the migration does not make bitching harder. After all it would be bad to reduce the only enjoyment some of us get.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.” Philip K. Dic*k (This STUPID forum software does not allow a perfectly valid last name, hence the unusual looking formating)

From a High School paper on Greek Philosophers:
"Socrates was a famous Greek teacher who went around giving people advice. They killed him. Socrates died from an overdose of wedlock."

Quick Links

When logs (server or client app) are requested for an investigation, please do NOT turn on "verbose" logging unless it is explicitly requested. Verbose logging makes things much more difficult in the majority of cases.