Sure would be nice if Plex added a new category in the forum of known issues(bugs) reported and being worked on. Have so you could see by device and and OS something like that. Sure would help everybody to know what has been reported and to know that it is being looked out. Sure would help the feeling you are shouting and no one is listening.
1 Like
I tried that, as proof-of-concept, in the Synology forum last summer.
It went unused / unheeded. People would ask anyway, with ANY searching, just as they do now.
There are a couple tough questions to figuring out how to make what you suggest, which I agree with BTW, actually work.
- Which forum(s) should this post (or posts) be in?
- How should it be maintained?
- I can only see it existing as a closed thread, where Ninjas and Employees add to with updates / changes.
If you, or ANYONE, has some thoughts on how to do this right, please speak up. Iāll bring it up in our next weekly team meeting.
@ChuckPA, I agree that only Ninjas and Employees can update and change. It would be nice just have a category maybe one within PLEX Pass and One in General, where you go into it be able to search on your PMS, or player, OS and find what has been reported and what is being worked on. , if it was nothing more that PLEX is aware of this problem and investigating. Surely this would have to help everyone involved. I know it would be a lot to maintain and you have to get people to look at it, anything would be better than nothing, start small and build on it. I am encouraged that you will take it to your team meeting. Thank you.
While I agree with @ChuckPA that such a thinking would not avoid questions for individual user problem experiences, I donāt think that this should be the major advantage of such a iist.
A) transparency
Users will become aware of which problems doch exist, and how devs rate their priority (critical/cosmetic/ā¦)
B) good reference
You would not need to āignoreā doublettes any longer or explain to euch User why this is redundant. Other Users can do this by pointing to that listās url.
C) insightful
Users can easily Check what Kind of problems they will run into before they buy a certain player device, for example.
D) one thread for one Problem
You could open issue related threads or point to these in that List. Users will know that somebody from the Team will follow these threads.
E) Progress visibility
It is simply a good feeling to strike out an issue from that Iist and an even better feeling to have a clean sheet.
F) Management
Even developers donāt have the time to closely follow all threads. One central List would have an advantage that related problems can be tracked down better.
All threads can stay where they are. One top-Level sticky post editable only by devs and Ninjas would be okay.
Thatās a great list. I already have this on my list
A: Reporting back how someoneās issue has been classified is bound to be confrontational with some. One manās āquirkā is anotherās āshow stopperā. Sure, it can be reported but in order to influence their determination further would take more than āthe loud fewā to sway their decision. A good example is the 1.4.x - 1.5.2 streaming speed. It was there until Championed. One known, I grabbed it. We all worked together, gathered the data and gave the team what they needed. Since neither I nor the others can be everywhere in the forum at once, this is where we need community help. If/as things are found and solidified into concrete , repeatable, sequences, then we have enough to for us to replicate again here independently. This gives us what we need. Your results, plus ours plus the writeup we do when submitting it (can be painfully extensive). Our goal is to give them a āHere it is, all pulled together for youā issue to work on/ resolve. We request a classification and they confirm or adjust as needed. (this is the standard Support - Engineering method). This would be when we can report back. If / as things develop along the way, we can update (the painful part of this task).
B: Good Reference? Please explain. There are many users who read only what they want from one personās solution. They are quick to judge and then spiral off. (figuratively) 50 loosely related threads to the real issue is virtually impossible for us to do. Telling the user heās redundant is a painā¦ but having that thread hanging is a problemā¦ It needs resolving. Technically it should be closed after linking. This is a good point for me to bring up but please do explain your thoughts further?
C: This impossible to maintain. Itās effectively asking for āwhat are you going to run into when using PMS 1.5.3, on a Roku 3, when using Windows, and the power goes outā type question. The permutations and combinations is beyond doable. This needs to be refined further.
D: One Problem per thread / One thread per problem IS policy & guidelines. Asking the community at large to conform to this is unlikely. Sadly, most take the easiest routeā¦ Ask first, NEVER search. I hate closing / deleting threads but have had to do so because of blatant duplication. When users donāt read the community guidelines, can we reasonably ask them to read the sticky at the top of a forum? I think not.
E: Progress visibility As we get information, it makes perfect sense to report it. I do my best to let everyone know. The problem I face in this position is I often donāt know the status of something until engineering has the āfix ready to testā.
These are my initial thoughts. Letās see how we can sharpen this up? While supportive 100%, Iām also going to be āa bit toughā so the request and justification is solid and shows the value added clearly.
I think that it would be better to have ticketing system rather than a āpublic list of problems being acted onā (which can be dangerous for the image of a product, create too much ānoiseā, and be unmanageable).
Foruns are good to test and report beta releases, help users, share experiences, but I would not publicize my problems using foruns or blogs (unless they affect large audiences, but for this we already have this)
Ticketting has one big issue as I see itā¦
I would be writing, or worse, copy/pasting, the same answer over and over and over. It effectively would multiply the amount of work I need to do because only that individual benefits from my effort
Of course your experience counts to make a decision, but all major companies use ticketing systems, not forums, as a way to escalate problems to level-2 (and up). Also, itās not always simple for a user to notice that the same problem occurs on different platforms, and several users confuse āplex clientsā with DLNA with Plex Server, so foruns are a ādisperseā way of reporting and tracking real problems.
If you look at the Synology and QNAP foruns, for example, users are often directed to report problems (via ticketing system) not solved by the community. Only usage problems are solved through foruns.
After being filtered by level-1 (which I suppose @ChuckPA is) problems could have another treatment. I am a PP user, therefore a paying one, and I think that I am entitled to receive answers for the problems that I put, and this does not always happens. Also I donāt think that level-2 support should spend valuable time looking at foruns.
Donāt such companies also have call centers and staffing levels considerably HIGHER than the scope weāre dealing with here at this point? Weāre not Apple (yetā¦ hahahaha)
Iāve submitted tickets via Synology. After an unending series of a) no reply b) we need to log into your machine to see what is going on or c) it does not work that way ā¦ .youāre holding it wrongā¦ I gave up. In the 4 years Iāve owned my Synology, not one of the problems Iāve submitted, with kernel logs got an answer.
A good example: showing where the device driverās probe and device reply causes the USB enclosure to fail to mount properly, ZERO attention to it.
I have written devices drivers (I used to teach device driver writing to other engineers), and can see where the tweak (so minor) needs to be made.
I will not be a hard ass here but will sayā¦ IF Plex goes to a ticketing system, The response time in Linux and Synology from me will get a lot longer in ways I canāt predict.
My experience with Synology support was also disgusting. But now that Iāve moved to QNAP Iām positively surprised (and in portuguese, my native language). I donāt think that a ticketing system is what makes support good or bad. Itās the people behind. If the people behind (like you) thinks that a forum is the way to go, then please continue with it. But I donāt think that a ticketing system complementing a forum would require more people than the forum alone.
Iāve been looking at a couple ticket systems. Look at Corsairās system. Itās very transaction oriented. There is a huge amount of āboiler plateā which can be applied. Letās set that aside for now.
There is a finite amount of time I have per day. In a ticket system, I take the next in the queue. If that takes me a couple hours, it does. I canāt move forward until itās done even if itās a known non-priority for the user. Itās regimented.
If there is another way to allow flexibility, then good. That provides me hope. I just donāt want to be known as that āThank you for writing Plex Supportā guy. YUCK! lol lol lol lol
I brought this up long time ago in the Cayars Venting Thread. 
What that long conversation came up with was a public ticket system where a select set of users or Ninja or higher could post/edit the list.
The main benefit is this gets the active forum users working to help the Ninjas with many things. As example a new thread pops up and someone like myself notices itās a duplicate of a known issue and we could refer the user to the ticket system so they know itās known and and can check the status (such as devs need additional info, devs canāt reproduce, in queue, etc). That new thread will quickly die and the Ninjas donāt need to get involved.
It solves the general problem many have with lack of communication. Often we donāt know if a problem is acknowledged or not, being worked on or is just being ignored or not seen yet as a problem. It would also help tie the different forum sections together or problems. By this I mean a windows problem and a Linux problem that users might not visit both forums to know about but really is a code problem in the server that affects both or all platforms. Could be the same with a client issue. A problem in Android and PMP for example. Different clients but same āmasterā problem affecting both.
I could elaborate much more but this is just the high level thought process.
Carlo
BTW, this public ticket system doesnāt need to be super elaborate, it just needs to be able to break things down by category and be easy to navigate. In all honesty it could be a web page or even a NOTEPAD/TEXT document. Itās just a communication vessel to allow the users to āknowā if Plex is aware of something and if they need additional information, etc. It probably DOES NOT need to be used like a traditional ticket system in that the order or entry is the order a dev works on them. It probably doesnāt need real time status such as checked out by dev A. It just needs to get closed when the fix is put is released or possible re-opened if said fix doesnāt workā¦
May I share, from my little corner, a sense of scope?
Today has been virtually silent (and now Iām going to jinx it with this HAHA)
Here is todayās Forum email count and year-to-date (2017-01-01 -> 2017-04-04). Again, this just pertains to my little corner and those threads Iām involved in.
@ChuckPA said:
A:Reporting back how someoneās issue has been classified is bound to be confrontational with some.
Trueā¦ it would most likely provoke a few comments, but something like ālast known statusā
āWe Need Server logsā, āProblem found, patch expectedā, āProblem unsolved, further Details necessaryā would be good.
Together with the single thread link, which has ninja/developer Attention would provide good info for all who pay Attention without closely following the thread traffic.
B:Good Reference? Please explain. There are many users who read only what they want from one personās solution. They are quick to judge and then spiral off.
Example: User XYZ opens a new thread, reporting a Problem. Right now, he gets either no comment at all or some good soul points him to another thread.
With this list of bugs/Problems/things that are worked on, a reference to this list (maybe including a number #1234 for issue 1234) instantly helps the user not only finding the ārightā thread to respond to, but also brings recent Information up on current status and what he can do to help solving the Problem.
List example (no real Problems mentioned):
PMS:
#1234 - Server crashing when newest Simpson episode gets recorded by DVR
Current Status / Severity: we need more logs from users experiencing this problem / Critical
affected platforms/versions: Windows (no version info)
Main thread: ā¦/what-the-fork:-bart-has-blown-up-my-server.html
Timestamp of last change in this list: Today
ā¦
Fire TV:
#3456 - Report module crashes each Friday night
Current Status / Severity: Workaround suggested (URL: ā¦/do-not-use-on-friday-nights.html) / severe
affected platforms/versions: sic! (5.6.6++)
Main Thread: ā¦/just-another-of-those-friday-night-experiences.html
Timestamp of last Change in this list: 12-31-2016
ā¦
Single long list of issuesā¦ easily searchable.
C:This impossible to maintain. Itās effectively asking for āwhat are you going to run into when using PMS 1.5.3, on a Roku 3, when using Windows, and the power goes outā type question. The permutations and combinations is beyond doable. This needs to be refined further.
Well, the Roku Team will add to this list as well as the Android/FireTV Team will add their stuff to it.
During the next few months, make it the central list for all who are willing to use it - in best of all cases everybody.
If you have a good list of what is known as an issue for āRokuā, then you might be able to post to the right thread without actively wading through the forum, finding four different threads, reading all of them to decide which is the āgoodā one.
D:One Problem per thread / One thread per problem IS policy & guidelines. Asking the community at large to conform to this is unlikely. Sadly, most take the easiest routeā¦ Ask first, NEVER search. I hate closing / deleting threads but have had to do so because of blatant duplication. When users donāt read the community guidelines, can we reasonably ask them to read the sticky at the top of a forum? I think not.
I see this as a support forum. It is not ist only usage, but users cannot possibly report their problems any other way.
If you follow this forum - say in a year from now - and you see two dozen threads with accurate answers of please check out the URL ā¦/list-of-known-problems.html for issue #1234 which is most likely the already known cause of the Problem of user XYZ, then people start checking the list before posting.
If manainance makes it worth to check, of course 
E:Progress visibility As we get information, it makes perfect sense to report it. I do my best to let everyone know. The problem I face in this position is I often donāt know the status of something until engineering has the āfix ready to testā.
If the engineers know that such a list is active, they could even develop a Standard procedure of reporting back without talking through each problem.
This is a long-term goal, of course.
Thank to everybody for making this a starting point. I like the idea of keeping it simple, but effective.
I see what is being asked for, I understand the level of detail being requested.
This is a list of 5 āasksā. Some are related to forum member management (all those threads which are floating out thereā¦ AND what to do with themā¦
A/B. Should all those unanswered floaters just be deleted? There are only a few hundred pages of them (since the epoch) of NO activity past the OP
C. Is the Ask for them to report in a different location or is the Ask for them to report in two locations ( forum and the internal system)? This excludes normal dialog from the Roku team (which is really great btw)
D. This is a member/user management problem. What do we do with the several hundred pages of 1-post threads where the user posted, then joined another thread and got the needed answer but never closed the first thread? delete it? Also, do you realize the effort needed to go cleaning out that many threads? Probably a few months of dedicated work by 1 person.
E. This is the the hardest thing to accomplish. Remember, thereās a fine line between feedback (which I try to give as I know) and asking a dev/team member to report as they do. My job is to be here. Their job is to be eyes on the software, not eyes on the forum. Itās the āDo you want it fixed ASAP or do you want accurate progress reports which really are company confidential anyway? Choose oneā problem. How do we find the win-win āAskā?
Please? Can we take this down about 2 or 3 notches? Start small. Itās easier to ask for and get the sandbox now then swimming pool will come later.
Would be happy to see the sandbox happening 
