Streaming Brain - discussion

General Discussions
41

@Monsters_Grin said:

@davehobson said:
WTF… I didn’t know we were playing Chess. So you have a library full of Xvid/avi/cams and 480p .mp4?

That’s just an expression :wink: . Didn’t mean to get on your nerves. Sorry :slight_smile: .

As for my library - my media ranges from 1,5 to 40Mbps, depending on the content. Most of it is not being streamed remotely, obviously. At least not until I get the 1Gbps symmetrical pipe installed. But that’s gonna take a looong time . . .

No worries but it just seems you are kicking off and demanding something that your current setup doesn’t support. Your upload speed will let a single person direct play a fraction of your library… God willing a handful of people will be able to direct play your lowest quality stuff.
Yes when you get your pipe upgraded things will be different but as already mentioned in this thread, the current way that streaming brain works is definitely only the beginning.
Am I missing something?

42

@gbooker02 said:
I always find it amusing when I see time estimates from someone without intimate knowledge of the design.
As per rationale: This slot value also controls index file generation, media optimizer, and sync transcodes. If this were set to 0, how many users do you suppose would then complain than those three no longer work?

Oh, please. Enlighten me :slight_smile: . Because - per UX rationale - I just choose the max number of transcoded streams there. I have no way of knowing that it also affects index file generation, media optimizer, and sync transcodes.

@gbooker02 said:
When you say that it is 5559kbps of overall bitrate, are you talking about the peak bitrate or the average? The above is a single line which is several layers deep in the decision process. Without the other lines and the metadata XML I can only guess, but if the decision process rejected direct play or direct stream (likely either at client request or due to bandwidth concerns), it’ll disable these two and run the decision process again. I imagine you are seeing subsequent runs of this process.

So where does Plex show the peak bitrate? And please don’t tell me it’s “in logs”.
If there’s a mediainfo option in the interface, don’t you think that a logical thing is to show it there?

I know that:

  1. this particular file has 8890kbps of peak bitrate
  2. I gave Plex server my upload as 10Mbps
  3. the server sets himself the peak upload at 8000kbps
  4. and therefore forces transcoding because this file’s bitrate exceeds this value.

I’m just making a point, okay?

@davehobson said:
No worries but it just seems you are kicking off and demanding something that your current setup doesn’t support. Your upload speed will let a single person direct play a fraction of your library… God willing a handful of people will be able to direct play your lowest quality stuff.
Yes when you get your pipe upgraded things will be different but as already mentioned in this thread, the current way that streaming brain works is definitely only the beginning.
Am I missing something?

My setup rarely sees more than one remote connection at a time.
But it’s not just about upload. It’s also about transcoding - something I wish to avoid.

43

@Monsters_Grin said:
I understand your approach. But not everyone has Plex on a server that is able to transcode multiple streams. Some just want to avoid transcoding like the devil avoids holy water :wink: . This should be the users choice. Plex Inc shouldn’t impose those kind of restrictions. Like I said many times before - looks like Plex Inc treats transcoding like a religion. That’s not right . . .
But, that’s their thing. It’s like playing Angry Birds and wanting to use a cross-bow instead of a sling shot or sheep instead of pigs.

Also, this is the just the initial release. It’s already been said that more features will be added so who knows, maybe it’ll be allowed in the future.

The Android app just shows which stream is being transcoded (video or audio). It won’t tell me if it’s because of the AVC level or something like that. Just shows the codec name. If the device tells exactly what is accepted, it should be reported to the server admin.
There should be a line under the video and audio info indicating why it transcoded.
Finding this in logs can take ages. And it will get even more confusing when Streaming Brain comes into play.
For example - I just tried playing one of the episodes remotely via Chrome. A video, previously direct played, now transcodes without a clear reason.
The only thing I found in the logs is

  1. “reducing bitrate to 7619kbps” - which is BS - the video in question has 5559 kbps of overall bitrate.
  2. Claims that direct play and direct stream is disabled which is not. I’ve selected “original” on all options.
    That same video was playing with just transcoded audio (because the audio is aac) just and hour ago. Now the video is transcoding too. Please don’t tell me I should just accept “the logic” :confused: .
    1 - Has PMS done the deep analysis on that file? If not, it will use double the average bitrate. Yes, the logic is a little different now. Before it used the average bitrate so if there was spikes in the file, those didn’t get handled well and you could get buffering or stutters. The new brain is more conservative and uses a higher level to avoid potential problems from spikes.
    2 - This is the thing I was mentioning earlier, where the device has already decided that direct play is not possible. When trancoding audio, that is not direct playing, so you would have seen the same message in the log. Have you set up bandwidth limits. The message in 1 sounds like it is hitting some sort of limit.
44

@Monsters_Grin said:
My setup rarely sees more than one remote connection at a time.
But it’s not just about upload. It’s also about transcoding - something I wish to avoid.

But they are totally linked… If you’re connection doesn’t support direct play for a large amount of your library and your server cannot support any transcoding whatsoever then surely you should not be sharing media that Isn’t sustainable for anything other than local play?

EDIT: @MovieFan.Plex
was just about to quote you from another thread but saw you jumped in here.
:slight_smile:

45

@MovieFan.Plex said:
But, that’s their thing. It’s like playing Angry Birds and wanting to use a cross-bow instead of a sling shot or sheep instead of pigs.

Also, this is the just the initial release. It’s already been said that more features will be added so who knows, maybe it’ll be allowed in the future.

I just want to avoid transcoding. Plex makes it extra difficult by not giving me info on why the transcoding was necessary. It’s like they want me to waste resources . . .

@MovieFan.Plex said:
There should be a line under the video and audio info indicating why it transcoded.

I know it is. But the web interface doesn’t show that. And it definitely should.

@MovieFan.Plex said:
1 - Has PMS done the deep analysis on that file?

Probably yes. But It doesn’t inform me of that.

@MovieFan.Plex said:
2 - This is the thing I was mentioning earlier, where the device has already decided that direct play is not possible. When trancoding audio, that is not direct playing, so you would have seen the same message in the log. Have you set up bandwidth limits. The message in 1 sounds like it is hitting some sort of limit.

Just like I explained in the previous post - I was just making a point.

Additionally:

  1. Plex does not inform you why the connection is using transcoding. Let’s be honest - showing “Transcoding (x264)” is not even remotely informative.
  2. The server admin shouldn’t be forced to search for this info in the logs.
  3. Plex does not inform you what is the peak bitrate of the file.
  4. If Plex shows devices authorized with that server, it should also show their playback capabilities.

Related question: I plan on buying an Android TV (not the Shield - a whole new TV), and I have no idea what are they capable of. TV companies are not exactly open about their devices’ hardware specs on the “smart tv” side of things, and I’d like to prepare my media in order to avoid transcoding or “optimizing”. I tried to search for those specs but found nothing. Could somebody help?

@davehobson said:
But they are totally linked… If you’re connection doesn’t support direct play for a large amount of your library and your server cannot support any transcoding whatsoever then surely you should not be sharing media that Isn’t sustainable for anything other than local play?

I know it could be a strange approach for you, but I just want the server to refuse playing if something needs to be transcoded in order to even be playable. Okay :wink: ? Let’s just say I’m weird but harmless :wink: .

46

@Monsters_Grin said:
Oh, please. Enlighten me :slight_smile: . Because - per UX rationale - I just choose the max number of transcoded streams there. I have no way of knowing that it also affects index file generation, media optimizer, and sync transcodes.
I think you’ve just made my point. Clearly not a 5 minute task is it?

So where does Plex show the peak bitrate? And please don’t tell me it’s “in logs”.
If there’s a mediainfo option in the interface, don’t you think that a logical thing is to show it there?
In the metadata XML. It’s not a single number so it is not displayed in the non-detailed info as to not clutter it up.

I know that:

  1. this particular file has 8890kbps of peak bitrate
  2. I gave Plex server my upload as 10Mbps
  3. the server sets himself the peak upload at 8000kbps
  4. and therefore forces transcoding because this file’s bitrate exceeds this value.

I’m just making a point, okay?
Is your point that the server made the right decision? It sure looks like that to me from the above. Also, where did you get the 8890kbps value from? This is a complex enough issue there is no single value.

Additionally:

  1. Plex does not inform you why the connection is using transcoding. Let’s be honest - showing “Transcoding (x264)” is not even remotely informative.
  2. The server admin shouldn’t be forced to search for this info in the logs.
  3. Plex does not inform you what is the peak bitrate of the file.
  4. If Plex shows devices authorized with that server, it should also show their playback capabilities.
  1. and
  2. This info is sent to the client (something that didn’t happen before). Clients are getting better at displaying this info but some are ahead of others.
  3. Answered above.
  4. This is much more complex than you are making it out to be. For example, what are the capabilities of an Android client? Oh wait, there are thousands of variations of these things with different capabilities. Furthermore, these capabilities change based upon preference set in the client.

I know it could be a strange approach for you, but I just want the server to refuse playing if something needs to be transcoded in order to even be playable. Okay :wink: ? Let’s just say I’m weird but harmless :wink: .
Then maybe you should just turn off bandwidth limits. Wouldn’t that put you back to where you were before?

47

@gbooker02 said:
I think you’ve just made my point. Clearly not a 5 minute task is it?

Well, it’s supposed to be. Since you present this value as controlling only the number of available transcode streams, not 267 other functions.

@gbooker02 said:
In the metadata XML. It’s not a single number so it is not displayed in the non-detailed info as to not clutter it up.

Clutter? You’re showing the duration three times there (separately - overall, video and audio), but you won’t show the bitrate required to stream the content because it’ll clutter the interface? Don’t be ridiculous.

Additionally - there’s no way of knowing if the file went through the deep analysis without going to the xml file. This should be marked clearly.

@gbooker02 said:
Is your point that the server made the right decision? It sure looks like that to me from the above. Also, where did you get the 8890kbps value from? This is a complex enough issue there is no single value.

My point is - I should be clearly informed what causes this behavior instead of being kept in the dark.
I want to solve the problem, not let it run and waste resources.
Value of 8890kbps was shown in the Android app when I tried to play the content remotely.
That’s a strange single number, right? Considering that there’s supposed to be few of them, as You’ve stated above.

@gbooker02 said:

  1. and
  2. This info is sent to the client (something that didn’t happen before). Clients are getting better at displaying this info but some are ahead of others.

The web interface is clearly in the Stone Age. And as for the web interface - it should show this kind of info in “Status” > “Now Playing”. Simply showing “Transcoding (x264)” is not nearly enough.

@gbooker02 said:
4. This is much more complex than you are making it out to be. For example, what are the capabilities of an Android client? Oh wait, there are thousands of variations of these things with different capabilities. Furthermore, these capabilities change based upon preference set in the client.

No it’s not. I’m not saying you should show all android devices available on the market. I was talking about devices already authorised to the server. And if the client has already contacted the server (let’s say - on first playback attempt), the server should be able to display the last known max capabilities of said device. I doubt that users meddle with settings so often that this info would change on each playback attempt.

@gbooker02 said:
Then maybe you should just turn off bandwidth limits. Wouldn’t that put you back to where you were before?

Turning off the bandwith limits would of course cause the playback to start for a few seconds without additional problems. The thing is - in such situation the user will see the error message after some time of trying to play the content instead of immediately being informed that his connection is not fast enough (to play without transcoding) or the server is not powerful enough (because it may not be able to transcode at all).

48

Before going into some of the details, note that I’ll answer some of your questions below but after that I am through. You are not familiar with all the intricacies involved and you are arguing with me as if you were. It’d take hours to describe it all to you and I’d rather spend the time actually working on code. This thread has become a large time sink and I’m not going to waste any more on it.

@Monsters_Grin said:
Clutter? You’re showing the duration three times there (separately - overall, video and audio), but you won’t show the bitrate required to stream the content because it’ll clutter the interface? Don’t be ridiculous.
You didn’t see what it looked like when all the values were there during development, did you? If you had, you’d consider your point ridiculous. As I’ve stated before, it is not a single number. You should read this article which describes some it: https://support.plex.tv/hc/en-us/articles/227715247

@gbooker02 said:
My point is - I should be clearly informed what causes this behavior instead of being kept in the dark.
I want to solve the problem, not let it run and waste resources.
Value of 8890kbps was shown in the Android app when I tried to play the content remotely.
That’s a strange single number, right? Considering that there’s supposed to be few of them, as You’ve stated above.
Yes, that is a strange single number. It also happens to be wrong. I know it is wrong because I know what it takes to compute the bandwidth numbers correctly and the Android app is not performing these operations.

No it’s not [more complex]. I’m not saying you should show all android devices available on the market. I was talking about devices already authorised to the server. And if the client has already contacted the server (let’s say - on first playback attempt), the server should be able to display the last known max capabilities of said device. I doubt that users meddle with settings so often that this info would change on each playback attempt.
There are other cases where these capabilities change. I only gave you two of several.

49

@Monsters_Grin said:

But not everyone has Plex on a server that is able to transcode multiple streams. Some just want to avoid transcoding like the devil avoids holy water :wink: .

If one doesn’t have a server that can run Plex, or doesn’t want the type of solution that Plex offers, then it seems to be then that Plex isn’t the right solution for them and they should look elsewhere.

This should be the users choice.

You have the choice to use a different product that meets your requirements.

Plex Inc shouldn’t impose those kind of restrictions.

The subset of users who want something Plex isn’t shouldn’t force Plex to create an alternate/inferior product to satisfy their demands, to the detriment of all the happy users who know was Plex is (and isn’t) and find that Plex is the right tool for them.

looks like Plex Inc treats transcoding like a religion. That’s not right . . .

Transcoding is an intrinsic aspect of Plex and how it does what it does to create the Plex “experience”/solution. What the anti-transcoding people demand is like asking car makers to make a car without wheels because they really like cars as a place to sit in comfortable, sheltered seats and listen to music. Sure, you can use a car that way if you want but it’s rather silly and contrary to the point of a car.

we’re being treated like sheep who can’t think for themselves and we should just buy expensive hardware and let everything work itself out by wasting resources.

No, you’re being treated like someone who bought a screwdriver and is complaining that it makes a lousy hammer, and so is demanding the screwdriver manufacturer change the handle and redesign the head for you.

50

@sremick too bad vanilla software won’t let me click insightful, like, LOL, and promote, I had to pick just one :slight_smile:

51

@gbooker02 said:
Before going into some of the details, note that I’ll answer some of your questions below but after that I am through. You are not familiar with all the intricacies involved and you are arguing with me as if you were. It’d take hours to describe it all to you and I’d rather spend the time actually working on code. This thread has become a large time sink and I’m not going to waste any more on it.

Please do. Because right now it seems like you came here to argue your way, and not to actually provide any solution. Throwing resources for transcoding is not a solution. If you want, go ahead, build yourself a 4 socket server with four Xeon’s E7-8890 v4. I’m not going to do that.

@gbooker02 said:
You didn’t see what it looked like when all the values were there during development, did you? If you had, you’d consider your point ridiculous.

Please, show me.

@gbooker02 said:
As I’ve stated before, it is not a single number.

I know. I’ve found eight for each stream in a file that had half the average bitrate than the one above.

@gbooker02 said:
You should read this article which describes some it: https://support.plex.tv/hc/en-us/articles/227715247

I’ve already seen that article. It has nothing to do with the fact that I can’t see those numbers until I open the XML and I am never informed if the file went through the deep analysis without looking into the xml.

@gbooker02 said:
Yes, that is a strange single number. It also happens to be wrong. I know it is wrong because I know what it takes to compute the bandwidth numbers correctly and the Android app is not performing these operations.

This is the number I saw in the app. The message also said that the available bandwidth was 8000kb. I assume it’s because I set the max upload at 10Mbps and Plex limits itself at 80% of the available bandwidth.

@gbooker02 said:
There are other cases where these capabilities change. I only gave you two of several.

So don’t expect me to answer either.

@sremick said:
If one doesn’t have a server that can run Plex, or doesn’t want the type of solution that Plex offers, then it seems to be then that Plex isn’t the right solution for them and they should look elsewhere.

@sremick said:
You have the choice to use a different product that meets your requirements.

Really? Just say what on your mind. Don’t dance around it.

@sremick said:
The subset of users who want something Plex isn’t shouldn’t force Plex to create an alternate/inferior product to satisfy their demands, to the detriment of all the happy users who know was Plex is (and isn’t) and find that Plex is the right tool for them.

Really? Would it be so harmful to you if Plex gave users the ability to disable transcoding? Would that make you unhappy?
Plex is a media server. I understand that one of Plex’s features is transcoding, but I don’t want to use this feature. I want to block it. And since this is not a feature that would significantly cripple Plex for me, I should be able to do that.

Another thing is - Plex is so hung up on transcoding, yet it won’t support hardware accelerated transcoding. Why? Apparently “just because” . . .

@sremick said:
Transcoding is an intrinsic aspect of Plex and how it does what it does to create the Plex “experience”/solution. What the anti-transcoding people demand is like asking car makers to make a car without wheels because they really like cars as a place to sit in comfortable, sheltered seats and listen to music. Sure, you can use a car that way if you want but it’s rather silly and contrary to the point of a car.

No. It’s expecting a little city car to not require a supercharged V8 in order to run the A/C.
I would be happy to enjoy Plex experience if I wasn’t forced to transcode everything because the app didn’t like something and won’t even tell me what so I could have a chance to fix it.
And I mean really fix it - not throw computing power at it to create “optimised versions”.
Fix it so I won’t have to create “optimised versions”.

No, you’re being treated like someone who bought a screwdriver and is complaining that it makes a lousy hammer, and so is demanding the screwdriver manufacturer change the handle and redesign the head for you.

No. I simply refuse to buy an 18-wheeler to transport a family with groceries for a week, if we have to stay in automotive metaphors.

52

Transcoding is a fallback, in case the media can’t be Direct Played. It’s just one option to make sure you can always play your media.

But to require transcoding for streaming seems that Plex is setting up the smaller devices for failure on the get-go. Many smaller CPU devices just haven’t got the power to handle RT transcodes. Yet those same devices will always TRY to transcode, or present an oblique error stating the device can’t do it, without providing a possible solution in the error message.

Those folks that buy a WD or ARM7 or other small NAS don’t know anything at all about transcoding or the CPU requirements for RT transcodes. They know their own business, whatever that may be. They aren’t IT people, or even people with extensive computing backgrounds. They are as clueless as a 5th grader would be when asked to drive in the Grand Prix. (To keep the car metaphors going.)

Now we get some folks asking to have transcoding disabled, and wow. Just WOW!

Transcoding isn’t INTRINSIC within Plex. Someone could run a Plex server and never have ANY RT transcoding going on. If they take the time top set up the media correctly. But, not everyone knows what’s required, or how to go about doing it. And those that can help haven’t been that forthcoming, either…

So, how does someone reduce or eliminate transcoding? Find out the limits of the connection. Both in the playback device’s supported codecs and containers, and in bandwidth limitations. The next step is to ensure all of your media is encoded with those containers and codecs, and within the bandwidth limits.

How? Converting the media to the MOST COMMON file container and codecs is a start. That would generally be MP4 with H264 video and AAC stereo audio codecs. You can use Handbrake, custom conversion scripts, or a slew of other tools. These can be run on a desktop or laptop computer, or on your PMS device itself, depending on which route you want to go down.

Bandwidth limits can be dealt with by leveraging the Optimize Media feature already built into Plex Media Server. Yes, this will use Plex’s built in transcoder for the conversions, but it KEEPS the files around, until you delete them! It runs in the background and when it’s done, it’s done. Make a simple test run with a few different settings, and then try them to see which give good results. Then branch that test out to include more of the library.

After a while, the media is converted to a more Direct Playable container, codecs and bitrates, and transcoding should be a rarity rather than a norm. Some file juggling and it could actually become the entire library, replacing the less Direct Playable media on the system completely if that’s the goal. (Reduced bitrates, but that might fit some people’s desires.)

For consumer level NASes transcoding = evil. I can completely understand why people would ask for a switch to turn off RT transcoding on these devices. They want the option to turn it off and still be able to enjoy Plex. They might have to wait to watch something, but if that’s OK with them, why is it so hard to entertain the idea?

BTW, I ran Plex for over a year on a NAS with right at 200 passmarks doing this very thing. Don’t tell me it can’t be done, because I KNOW better! (And it did it all without the Optimize Media feature, so I had to mess around manually with bitrates to find the “sweet spot” for the environment I was in!)

53

I know how to reencode my library. All I want from Plex server is to tell what wasn’t right and let me fix it. Using the optimising feature to do it would take ages. Besides, I have a lot of media with external subtitles and getting it to work after optimisation is additional hassle. It would be better to mux it in during the conversion but first I’d like to know what is causing Plex to transcode my media.

I can understand that sound may need to be transcoded when played in browser (unless someone knows a browser that can play DTS or a way to load DTS codec into Chrome?), but other than that I’m in the dark.

And just for a “funny story”:

Recently, I added all my music to Plex. Practically 99% is in FLAC.
I get that Chrome probably can’t play FLAC, and that’s why it’s transcoded for playback.
But the behavior on Android and logic behind playback and mobile sync just baffles me.
My phone is perfectly capable of playing FLAC - just like 99% of phones after circa 2010.
If I try to stream FLAC music from the server, it direct plays just fine. Everything’s okay.
But if I try to sync it, the highest quality I can choose is 320kbps mp3.
There’s no “original” option that would just copy the files along with the playlist to the phone.
Why? Apparently “just because” . . .

I thought that’s strange, since I saw the “original” option in libraries for videos.
I went back to check it, selected a file I know could be direct played,
clicked sync icon, selected “Original” . . .
And you know what happened? Plex tried to transcode the damn thing!

Can someone explain it to me? Because it just doesn’t make any sense . . .

54

@Monsters_Grin said:
I know how to reencode my library. All I want from Plex server is to tell what wasn’t right and let me fix it. Using the optimising feature to do it would take ages. Besides, I have a lot of media with external subtitles and getting it to work after optimisation is additional hassle. It would be better to mux it in during the conversion but first I’d like to know what is causing Plex to transcode my media.
Plex can’t tell you because it depends on the client. 1 client might be able to direct play, but another might not. However, with streaming brain, there is now a mechanism is place to allow clients to provide better feedback. It’ll need client updates, but it is now possible for more feedback.

Like I mentioned earlier, not every device will provide the info on what it supports, so the messages may still be vague. Yes, devices are suppose to answer when the Plex app queries it, but devices don’t always respond. If every device responded properly, Plex wouldn’t need to provide device profiles.

I can understand that sound may need to be transcoded when played in browser (unless someone knows a browser that can play DTS or a way to load DTS codec into Chrome?), but other than that I’m in the dark.
Nope, can’t be done through a browser. The browser is a very basic player. If you want HD audio and video, you really should switch to a full player like Plex Media Player.
My phone is perfectly capable of playing FLAC - just like 99% of phones after circa 2010.
Not sure where you got this number. I’ve had 2 Android devices (made after 2010) that don’t support flac.
If I try to stream FLAC music from the server, it direct plays just fine. Everything’s okay.
But if I try to sync it, the highest quality I can choose is 320kbps mp3.
There’s no “original” option that would just copy the files along with the playlist to the phone.
Why? Apparently “just because” . . .
It’s because the “original” setting is for the bitrate, not codec, hence all the other numbers below it. Same when playing back, setting the quality to “original” doesn’t mean direct play, it means use the original bitrate.

Remember previously I mentioned how during playback the app will ask the device if it will direct play a file or not before PMS decides how to transcode. Well, with Syncing, this step doesn’t occur. Which is what allows you to set up sync jobs even if the device isn’t connected to PMS. Since it can’t identify what the target device supports, it plays it safe and uses a common format. This is the same reason you cannot sync a HEVC video or any other video that your specific device might support. Plex is looking to improve this logic so hopefully, in the future, you can sync a file directly.

55

@MovieFan.Plex said:
Plex can’t tell you because it depends on the client. 1 client might be able to direct play, but another might not.

It would be better if Plex tested the limitations of the device on first connect. That way it could build a database of all authorized devices along with their capabilities.
This could serve as a basis for preparing media to ensure direct play on all devices.

@MovieFan.Plex said:
However, with streaming brain, there is now a mechanism is place to allow clients to provide better feedback. It’ll need client updates, but it is now possible for more feedback.

Great! Now, it would be nice to show us that info, instead of just “Transcode (x264)”.
And please don’t tell me about “clutter”. I still think we should be able to easily check the max bitrate in mediainfo.

@MovieFan.Plex said:
Like I mentioned earlier, not every device will provide the info on what it supports, so the messages may still be vague. Yes, devices are suppose to answer when the Plex app queries it, but devices don’t always respond. If every device responded properly, Plex wouldn’t need to provide device profiles.

Okay, but that doesn’t mean that Plex is unable to inform the server admin on the parameters used to transcode and provide media.

@MovieFan.Plex said:
Nope, can’t be done through a browser. The browser is a very basic player. If you want HD audio and video, you really should switch to a full player like Plex Media Player.

Yeah, I know. Just “wishful thinking”. As for the PMP - it would be nice if there was a portable version.

@MovieFan.Plex said:
Not sure where you got this number. I’ve had 2 Android devices (made after 2010) that don’t support flac.
Android supports FLAC natively since version 3.1 - that’s 2011, sorry.
I don’t know what those devices were, but I don’t recall any of mine ever having problems with FLAC files.
But that’s not the problem - the problem is with syncing FLACs.

@MovieFan.Plex said:
It’s because the “original” setting is for the bitrate, not codec, hence all the other numbers below it. Same when playing back, setting the quality to “original” doesn’t mean direct play, it means use the original bitrate.

It doesn’t make any sense to change the codec if the device could direct play the file in the first place.

Remember previously I mentioned how during playback the app will ask the device if it will direct play a file or not before PMS decides how to transcode. Well, with Syncing, this step doesn’t occur. Which is what allows you to set up sync jobs even if the device isn’t connected to PMS. Since it can’t identify what the target device supports, it plays it safe and uses a common format. This is the same reason you cannot sync a HEVC video or any other video that your specific device might support. Plex is looking to improve this logic so hopefully, in the future, you can sync a file directly.

First of all - Being able to invoke sync from the web app is a nice feature. I really liked it when I was toying with music (we know how that went).

Second of all - Why was it designed like this? Was there some kind of limitation or devs just now realized that it should be done differently?
If it’s the latter, I’m really disappointed. Why? Because I’m pretty new when it comes to Plex, yet the correct logic is obvious to me. And I’m probably not even half as smart as those guys.
Yet, they did it that way.

Anyway, that doesn’t solve the mystery of missing “original” option when it comes to music. I hope someone will shed some light on this as well.

56

Huge huge thanks to @gbooker02 for your contributions on this thread. While it may have felt like banging your head against a brick wall at times, the level of information and feedback from an actual Plex Employee is immensely valuable to me as a user, and massively appreciated.

Thank you!

57

@Monsters_Grin said:

Nice idea. I like it. But the user part would need to be dynamic. We would have to assume that users move and connection quality changes. But I can live with a delay before the app starts playing.

Oh, okay. One person can live with a delay and suddenly everyone else has to put up with the delay? Come on!

Tossing your own argument back at you. :slight_smile:

58

@MovieFan.Plex said:
Has PMS done the deep analysis on that file? If not, it will use double the average bitrate. Yes, the logic is a little different now. Before it used the average bitrate so if there was spikes in the file, those didn’t get handled well and you could get buffering or stutters. The new brain is more conservative and uses a higher level to avoid potential problems from spikes.

This explains those unexpected bufferings in the past when I knew I had the network bandwidth. Hooray for the new brain. :slight_smile:

59

@sGarver said:
Oh, okay. One person can live with a delay and suddenly everyone else has to put up with the delay? Come on!

Tossing your own argument back at you. :slight_smile:

Oh, you sly devil, I like you :stuck_out_tongue: .

60

@MikeG6.5 said:
Transcoding is a fallback, in case the media can’t be Direct Played. It’s just one option to make sure you can always play your media.

Yes, but it’s a common “fallback” because of the many things that ultimately require transcoding.

But to require transcoding for streaming seems that Plex is setting up the smaller devices for failure on the get-go.

I never got the impression that Plex server was targeted at “smaller devices”. It’s just that people with insufficient funds are trying to run Plex on what they have or what they can afford, not what it was designed to run on.

Those folks that buy a WD or ARM7 or other small NAS don’t know anything at all about transcoding or the CPU requirements for RT transcodes. They know their own business, whatever that may be. They aren’t IT people, or even people with extensive computing backgrounds. They are as clueless as a 5th grader would be when asked to drive in the Grand Prix. (To keep the car metaphors going.)

Bingo. So expecting them to do all that pre-transcoding using Handbrake and it’s 5000 manual settings is rather unreasonable. One way or another, “transcoding” happens… whether it’s beforehand by uber-technical people who understand how to use tools like Handbrake, or if it’s for the “set it and forget it, just play all my media and MAKE IT WORK” functionality that Plex tries to offer. It’s that “magic” which caters to the exact “folks” you’re describing.

Transcoding isn’t INTRINSIC within Plex.

Although perhaps not required on a technical level, it is intrinsic to the Plex “experience”.

Someone could run a Plex server and never have ANY RT transcoding going on.

Sure, if they’re OCD, even more technically skilled than the average Plex user, and have a lot of time on their hands.

So, how does someone reduce or eliminate transcoding? Find out the limits of the connection. Both in the playback device’s supported codecs and containers, and in bandwidth limitations. The next step is to ensure all of your media is encoded with those containers and codecs, and within the bandwidth limits.

…and so on, with all your additional steps… all of which flies right over the head of those non-technical users who just want to install Plex and have it magically play every file they have on every device they have. Regardless if it’s MKV, MOV, AVI, MPG, etc.

For consumer level NASes transcoding = evil.

Yep. They’re too under-powered for the experience that Plex advertises. Sure, they’re general-purpose CPUs and one can shoehorn Plex to run on them… but not run “well” and it’s a handicapped, restricted experience.

BTW, I ran Plex for over a year on a NAS with right at 200 passmarks doing this very thing. Don’t tell me it can’t be done, because I KNOW better!

No one said it couldn’t be done. No one said you couldn’t rip the wheels off your car and use it as a stationary music listening room with comfy seats. No one said all sorts of interesting fringe-case things could be done with Plex by someone with extreme skill, time and patience under controlled circumstances. But that’s not the “Plex experience”. That’s not the promise on the box. And that’s not what can be managed by the average Joe just wanting to point, click, install some software, tell it where all his video files are and then send it to all his things.