I think ‘out of house’ testing (post first code freeze) is optimal. When it passes beta, it’s an easy release candidate
Sent with Tapatalk
Beta testing would be ideal. For instance, we have PSx and xbox apps now that are essentially in beta for PlexPass only. But guess what, they're literally the first thing anyone sees on the homepage of Plex. I think this is a prime example of an absolute communication and marketing failure. If it were *clearly* labeled as beta and *not* featured on the homepage nearly so prominently I think a lot of the misunderstanding that surrounded all the bugs the first weeks would be far less.
EXACTLY!
As I understand it, that opening image used to be easy to modify, but that flexibility was taken away in subsequent software releases, and now it can only be changed by switching to one of the third party skins. (Someone can correct me here if this was not the case).
If the image your are talking about is barkley inside a tv set then its a jpg in the PMS directory, its easy to change but gets reverted each time you upgrade PMS which can get a bit annoying.
\program files\plex media server\resources\graphics\
Beta testing would be ideal. For instance, we have PSx and xbox apps now that are essentially in beta for PlexPass only. But guess what, they're literally the first thing anyone sees on the homepage of Plex. I think this is a prime example of an absolute communication and marketing failure. If it were *clearly* labeled as beta and *not* featured on the homepage nearly so prominently I think a lot of the misunderstanding that surrounded all the bugs the first weeks would be far less.
To put that in tangible context, does this make sense?
1. Public Download - As normal
2. Plex Pass (Preview) Download - The early release of beta-tested and approved software, as was the original intent.
3. Plex Pass Beta Download - Software which may have passed internal testing, but needs more testing / shake down.
With a Specific Sub-Forum to report these errors in. Only posts reported in the sub-forum will be on the Development team's direct radar.
Developers may/will, if they wish, interact with those testing here to collect needed data.
While I loathe more 'control', Access to the beta test downloads and forum is probably best restricted to avoid confusion and misplaced posts.
If the image your are talking about is barkley inside a tv set then its a jpg in the PMS directory, its easy to change but gets reverted each time you upgrade PMS which can get a bit annoying.
\program files\plex media server\resources\graphics\
Fully aware of that, but thanx... Found the image some time ago... but it caches, cannot be simply replaced, and gets re-installed with, as you say, "every upgrade."
It used to be user configurable, and is still totally annoying.
There are a few skins that allow changing it permanently. (Black Edition and Black Edition Remix to name two - my thanx to DeadEyeFlint and Badaas respectively)
@Elan: Thank you so much for showing up and answering!
One question:
adamskoog: A software company not giving any kind of a road map or time frame for anything is kind of a cop out in my opinion
In that case, most companies are copping out :) We try to do (and I’m doing above) exactly what you say, letting the community know we’re aware of issues, they’re on our radar, or that they’ll be fixed in the future.
I believe you that you think you are doing so - but it doesn't reach me (and others). The impression is we report bugs and fight problems and nobody knows which threads are noticed by Plexville and which aren't.
Please (!!!!) consider doing as you say in ONE place where we could look at if we experience an issue. A table, a list ... anything would do. And save me (us) sooooo much time and frustration.
One answer:
cayars: At a high level, why would anyone design a system that has to do all transcoding before starting any uploading
Let me end with a question: why are trying to Cloud Sync massive amounts of media to the cloud? Do you have poor upstream bandwidth and stream outside the house? Do you want your media to live in the cloud? Help me understand.
In our case it's a lot history in it - to be honest.
CPU: We started with a little home server machine with a atom in it. Meanwhile our home server is the most powerfull PC in our home - only for the purpose of Plex.
But I think many people are still having a cute little CPU sitting in their server that can't handle more than one transcoding task (all the Synology people i.e). Cloud Sync = pre-transcoding.
Bandwith: long time we hadn't got a chance to upgrade our bandwith. Each bit was painfully uploaded and should NEVER be deleted again. Streaming to outer house wasn't possible. --> Cloud Sync was a solution. Meanwhile we have a bit more bandwith, but more kids outer house. And in fact it is still too slow to upload and delete again. We cannot offer higher qualities - but until now our kids doesn't have big screens so it doesn't matter. That will change.
Backup: We have been Bitcasa users for a long time and as every one here we have to handle a backup of our data. It was a charming idea to have a offsite backup at Bitcasa (or now Google) ... and the step to the idea to USE this backup isn't very far. It was possible to access Bitcasa as drive so we could should down the HDDs (although still a bandwith problem for us for a long time) with Google that isn't possible anymore - the Plex server still had to be up running. Next step: how to shut it down. --> Then Plex brought Cloud Sync. A solution! We never dared to try a VPS with Plex as we aren't so IT-skilled as we maybe should be - and now with Google Drive it wouldn't work anyway.
This backup thoughts are a bit outdated for us because we canceled Bitcasa and we havn't been able to connect Google or OneDrive as a drive with a reliable speed. But still it would be enticing if Cloud Sync could use already uploaded files ... but I do understand that's not reasonable.
Energy: As our server isn't the small energy-saving little home server anymore (powerfull hardware, many hdd) we don't really like to have it up running 24/7 just in case a kid wants to watch something or listen to music. Cloud Sync is really a great fall back.
Hardware Issues: When we are running into problems with our server, crashes, down-times .... our kids really have the talent to use Plex ONLY at those times. If I want them to call us ... just turn off the server. Again: Cloud Sync is a great fallback.
Holidays etc ... perfect.
If only we could do more selection with the audio-streams (double language).
Maybe you have a little impression why we like Cloud Sync.
Thank you for reading - btw I like Barkley. :D
@Elan: Thank you so much for showing up and answering!
One question:
I believe you that you think you are doing so - but it doesn't reach me (and others). The impression is we report bugs and fight problems and nobody knows which threads are noticed by Plexville and which aren't.
Please (!!!!) consider doing as you say in ONE place where we could look at if we experience an issue. A table, a list ... anything would do. And save me (us) sooooo much time and frustration.
This is the most frustrating thing. You spend many hours troubleshooting a problem. Finally presenting the evidence for the Plex Team ready to be looked into by a Dev and you never know if anyone from the Plex Team looked at it, registered it, discussed it with Devs.., or just ignored it waiting to see if loads of other people report the same problem and if they do not, then hard luck
A register of all issues visible to all of us is needed urgently and a commitment that no topic / post gets missed by then Plex Team and even topics looked into by us and where we get to a point where we need the Plex Team to look into it then a commitment that this will happen 100% of the time
Edit:
And to add to this:
Forum Based Community Support should only be used where customers do not have to pay for a product. Once you charge for a product then you either provide a bug reporting interface eg email / form managed 100% of the time or if you believe the forums is the vehicle then it needs the guarantees that 100% of reported issues get picked up
To put that in tangible context, does this make sense?
1. Public Download - As normal
2. Plex Pass (Preview) Download - The early release of beta-tested and approved software, as was the original intent.
3. Plex Pass Beta Download - Software which may have passed internal testing, but needs more testing / shake down.
With a Specific Sub-Forum to report these errors in. Only posts reported in the sub-forum will be on the Development team's direct radar.
Developers may/will, if they wish, interact with those testing here to collect needed data.
While I loathe more 'control', Access to the beta test downloads and forum is probably best restricted to avoid confusion and misplaced posts.
Yes. Like you I loathe more control but at the same time doing something to make PlexPass beta downloads opt in makes the most sense. That being said in the phase 2 step you've outline I believe it is crucial to still not fully market the feature/application until it nears a "public" release (if such a release is a viable option, which for some features like sync never will be). To my mind this system seems fairly painless to implement and could quite easily avoid some of the miscommunication around here if properly done.
ChuckL,
Couldn't agree more with public, preview and beta status. I'd go as far as to say only public and preview are mentioned on the the website and beta is only known to users of the forums (where they would get help or comment about the beta).
higeko,
Good narative of what I think most people wanted in cloud sync. You provided the optimal use of it for many people.
sa2000,
Ideally they should have a forward facing trouble ticket system. It should be viewable by everyone. Maybe limit write access to it for Ninja's and select users who use the forums often and have shown to be able to diagnose and troubleshoot things and keep the ticket system from having dupe entries. You would be a prime candidate for example.
Everyone could use the forums as usual to report things and everyone could view the ticket system but the "liasons" would keep the two in sync. This would keep the devs from having to de-dupe and manage the ticket system and it would stay "streamlined" for easy use by them. But at the same time everyone could easily see any progress, status, assignments or updates made on the issues. Sort of WIN/WIN for most people and a great use of proper tools for "communication".
Carlo
There used to be a public bug tracker at Lighthouse ( https://blog.plex.tv/2008/07/22/move-to-lighthouse/).
Not sure when that was discontinued. I'm assuming they moved it in-house.
A public facing bug tracking system, much like Bugzilla (fedora folks use it), which provides a great interface, would be an good model to use.
It has the ability to provide opt-in/opt-out notifications, and super interface for watching state changes as it transitions: Submitted, Confirmed, Assigned, Fixed (with optional targeted release version), Closed-Fixed, Closed-dup, Closed-notabug, Closed-wontfix. Users who opt-in can follow along without disturbing developers. Developers can ask and receive directly, via bugzilla, the required info. This would have a major benefit of moving all the problem reports from the forum (which are spread everywhere) to one central store, properly qualified and quantified.
There's also Trello. Sonarr, among many others, use Trello with great success. I'm not optimistic, but something like this would be awesome for Plex: https://trello.com/b/MadvFKy4/sonarr
There is one potential problem with a bug tracking device I can see right from the start though....
We don't have visibility of any Plex Team coming here to view any of the topics we're commenting on now. If they were to implement a bug tracking/fixit ticket system then maybe the current presence on the forums would drop off completely. Communication, as has been stated time and again in this thread, a problem area for the Team. If there were to be one more layer between the devs and the users, I could see that one day a dev doesn't have time to go to the forums to check on his area. He looks at tickets and thinks "I'll do that tomorrow." Tomorrow comes along and again he's swamped, so pushes to tomorrow again. Pretty soon it's been 3-4 weeks and that dev hasn't been on the forums once.
You can't have a single dev searching the forums for issues or reply to those things he needs to reply to, because that could become a full time job, just lurking and posting in the forums. Unless that person were strictly PR he wouldn't have time for anything else.
Don't get me wrong... I LIKE the idea of some sort of escalation system and a ticketing system seems to fit the bill. In order for us, the subscribers, to get a "Warm Fuzzy" over it, though, I think we would need to see more active participation from ALL of the devs on the forums, even if it's just poking in and a single comment of "Yeah I was here."
Not having visibility of the Plex Dev team, or any dev team on any product, isn't new. Devs are best when silent among the users. I always kept my developers protected from the end users unless they (developers) requested it or it was required (special customers).
That's why the tracking system. It's ordered, reviewed and prioritized by management, and in the absence of 'Sky Felling Emergencies', predictable. It allows users to follow comments placed by the developer(s) as they work on their tasks. They (devs) are free to look and integrate user-supplied supplemental data as needed.
Each dev has their assigned tasks (so reported in what users see). They are prioritized internally (development and management team). If/when priorities change drastically, that's when people like the Ninjas, the current public face of Plex, can explain what's happening if needed. It's a very simple, easy flowing, non-confusing model. It provides just enough filtering to keep it calm and controlled. The current method clearly doesn't work. It prevents getting swamped by hundreds of users clambering for a feature. Those show up in the reports (many ways to report).
I'm not suggesting the dev team make a regular presence known in the forums. By making their progress visible to the users in the tracking system, they won't have to be seen. Their work will speak for itself as work moves through the pipeline.
Agreed on every count and exactly why I brought it up.
Besides having a bug tracking system, we should have a feature request system to go with it. Microsoft uses this pretty much across its entire product line, examples:
We could use the feature voting system, to help drive those community driven releases that people had suggested or just for better tracking, prioritizing and cleaning up the forums.
It could even be broken out for all the various clients.
Perhaps it would be worth a shot to set something up, at least for issue reporting, without official Plex sanction? Through up a bugzilla or Jira interface and point users to it to submit their bugs. It may just grab the attention of the powers that be.
For those interested in seeing bugzilla, they have a test/demo server "Landfill".
https://landfill.bugzilla.org/
Version 4.4 (clickable on the right) will take you into the vanilla (as distribute) config where you can play with it and poke around.
Edit: If you want to see what Fedora folks have enabled: http://bugzilla.redhat.com
Also of note Mojang has a fairly robust set of bug tracking tools based on Jira for the public to use. They are slowly getting more closed off in development and keeping features under wraps until beta testing these days but they still keep on top of bug reports with their users.
Minecraft specifically - https://bugs.mojang.com/browse/MC
Mojang landing page for all 3 of their trackers - https://bugs.mojang.com/secure/Dashboard.jspa
Consider this a bit more UI friendly than the bugzilla types of trackers, but both are powerful and can empower the community if used/maintained properly.
Are you guys talking about tracking bugs only, or also insight into new projects? Because I do not see the latter as especially possible to do in the world of NDA:s and such.
