@marcelhehle said:
What about opening a bug-tracking system!!! I know that you guys are putting a lot of effort into it, but it is a bit of student’s project approach after all …
I too would love to see this. Before I was a Ninja I highly advocated this as well. As a Ninja I still advocate for this. Unfortunately I don’t get to make the decisions. 
Plex recently (few months ago) created a Ninja only ticket system that is working out nice for us Ninja’s. We don’t need to see all the nitty-gritty stuff the employees might need but it allows us to track bugs and users issues. Maybe down the road Plex will extend this to users as read only so you guys can see what’s been filed but keep write access for Ninja’s to make sure everything is filed correctly and of course keep out the numerous dupes that would happen. That could perhaps be a way to go in the future.
@tachtevrenidis said:
@cayars thanks for engaging us although it is not always pleasant! In other posts, I have talked about Plex focusing on one thing and doing it well before it tries to expand its core capabilities. It seems to me that if there was one permutation of hardware/software that would get people a stable/robust Plex experience, folks would not mind investing in that hardware. See Plex is trying to be everywhere (Roku, SmartTVs, Android TV, Apple TV etc) and IMO it does not do it well enough anywhere. When you spread engineering so wide 1) features come out slow 2) they don’t work right etc. Since last year, I have seen photo tagging, alexa, news, VR, and now the rumored podcast support. Plex engineering is spread too thin!
If everyone was using a device such as the ShieldTV which can direct play mpeg2 video and do it’s own de-interlacing (and quite well) it would make this a much simpler endeavor for sure. But if your neighbor had the ShieldTV and you didn’t have the upload bandwidth it really wouldn’t matter if they were using a Roku as the stream would need to get transcoded anyway.
Plex essentially had to find the ideal way to record while being able to funnel the live-tv streams through the transcoder to allow for this for type of thing to support the different clients and bandwidth restrictions that could be in the way. To be able to make use of the auto bitrate adjustments already present in the mobile apps, etc. I believe this was the post 1.6 version changes.
Plex has been very “die-hard” working to identify and fix these issues in the “core” of DVR/Live TV since it’s fundamental to the product working correctly long run. The “technology” will also be of use for other things possibly like streaming from additional services. It’s a far different animal to stream a local file that you can know the bitrates of to something coming in live (from the internet or from a tuner). Identifying the streams in real-time as you can imagine is much harder then looking up what has already been discovered through a deep analysis of the files. It also poses new challenges that need to get discovered and fixed. As an example something simple like the US Fox Channel can broadcast Spanish as the first track and English as the second and not identify the streams correctly. To make matters worse even though the first channel is Spanish the advertisements might still be in English. So depending on when you tune into the channel you might get English or Spanish on that channel. You of course can record all streams but for LiveTV you only want to send the correct language channel to save on bandwidth (in many situations). Not to mention the pre-padding might have a show using stereo while the new show is 5.1 with advertisements being something different with each new commercial. Sounds simple until you have to program for it.
Another simple example of “new” issues for Live-TV is CC or Closed Captions in North America. Unlike files ripped from disc you don’t have separate streams in the file for the “subtitles”. Instead in NA this CC data is embedded in the even line 21 field. Obviously not all the default players used in the apps know how to use this data since some of them can’t decode mpeg2. Plex needs to handle this on the server side at times so the client will be able to display the CC data.
There are lots of little gotchas like these that no one would think about and the only way to find this stuff out is to get your software out in the wild being tested world-wide. It’s obviously best to do this during the preview period so these issues can be identified and a remedy is found before piling on more and more features making the fixes that much harder down the road.
So from that standpoint Plex is working quite hard on fixing any and all “core” features before adding on a lot of bells and whistles we all want to have.
Carlo
However, think about this. If Plex was to create specific code for each device we might have Android, XBox and Roku with everything else in the pipeline schedule for a later date.