I agree, developers let us users decide if our server is powerful enough!
@ebike said:
I agree, developers let us users decide if our server is powerful enough!
As we’ve seen with other devices, this doesn’t work well. First off, when the device can’t transcode well, the user comes here and asks what the problem is. Then when they are told that the device isn’t powerful enough for on-demand transcoding they complain that they shouldn’t have transcoding even enabled, then.
This is a 6 of one and half dozen of the other. Or damned if you do and damned if you don’t if you prefer. If the device has transcoding disabled when Plex Media Server installs on devices without enough power to do the transcode then the user comes on and asks why it’s not enabled, as is the case now.
Well since you don’t know all the combination CPU/GPU out there, you can’t possible make an accurate assesment of the hardware capabilities unless you run some sort of GPU benchmark as part of your script.
Since you are not doing that, then you should leave the choice to the user. You may get some users who will always complain, the majority of us should be able to make the decision, please do not take it away from us.
If it is a setable transcode option, then all you have to do is document it in the trouble shooting section of
your document as a possible source of issues …
Don’t remove the option because you think everyone is too thick to work it out …
My 2c 
Don’t forget to “Like” this thread folks, if you agree.
@MikeG6.5 said:
As we’ve seen with other devices, this doesn’t work well. First off, when the device can’t transcode well, the user comes here and asks what the problem is. Then when they are told that the device isn’t powerful enough for on-demand transcoding they complain that they shouldn’t have transcoding even enabled, then.
Then why not to disable transcoding by default on ARM devices, but allow user to enable it somewhere deep in advanced settings and add corresponding hint there?
Well I have got bitten by this … yet AGAIN …
I am trying to watch some mumudvb streams (mpegts) so I created a *.strm file with the URL of the channel I want to watch, add it as a video source … play it, and this is what I get
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Starting analysis of Original
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Analyzing direct play
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Direct play failed; unsupported container: undefined
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Analyzing video direct stream
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Analyzing audio direct stream
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Analyzing playability
2016-02-20 15:37:54 [ INFO ] JS: [MDE] Unable to play; server unable to transcode video
2016-02-20 15:37:54 [ INFO ] JS: canPlay: false
2016-02-20 15:37:54 [ INFO ] JS: canDirectPlay: false
2016-02-20 15:37:54 [ INFO ] JS: videoResolution: 360
2016-02-20 15:37:54 [ INFO ] JS: [PDE] Unable to play item; This server is not powerful enough to convert video.
My server is perfectly able to transcode mpegts … but again plex won’t allow me to watch it.
How to I set it for directplay to get around this crazy behaviour … what determines if that source is DirectPlay or if it needs transcoding …
The stream plays fine in mpv … just can’t watch it in plex … why does plex not support mpegts container when mpv does?
The crazy thing is that the stream is generated ON the client, so why can’t I watch it on the client, the server does not even have to get involved for this case … bah!
I pays my money and I gets what I get I suppose …
Since you guys have been wanting a cross-platform benchmark that you can use, how about nbench.
I compiled version nbench-byte-2.2.3-2 for my Odroid-XU3 “without” any special compile optimizations and got a score of:
MEMORY INDEX : 10.707
INTEGER INDEX : 13.923
FLOATING-POINT INDEX: 18.229
According to the table here: http://www.tux.org/~mayer/linux/results2.html
That puts it about the similar performance of AMD Athlon 64 Processor 2800+ 1809MHz and far better than my 1.6G quad-core Atom that probably would pass on your server performance test.
(When you consider that the Atom is 64 bits and the ARM is 32 bit … well you do the math …)
My Quad-core Atom results where:
MEMORY INDEX : 14.157
INTEGER INDEX : 9.629
FLOATING-POINT INDEX: 13.215
Apologize for the blatant cross-post, but it was relevant to both threads.
**** Ends my Case for fairness & equality ****
EDIT: Note: nbench does not share across cores, so this test is on ONE core only
@m0thman said:
The problem is that I can not compile version for required platform with needed flags because plex is not open source.
You can get the source for the Transcoder from
http://files.plexapp.com/elan/ffmpeg/PlexTranscoder.tar.bz2
http://files.plexapp.com/elan/ffmpeg/PlexNewTranscoder.tar.bz2
Whether or not that’s sufficient to get you going, I don’t know, but hopefully it’s a start!
EDIT: Then there’s also https://forums.plex.tv/discussion/156162/guides-install-plex-media-server-on-armv7-sbc-e-g-raspberry-pi-2/p1
If you get a modified transcoder working, please post method here …
I will have a go as well …
PS: What’s to stop anyone from compiling their own version of ffmpeg that is installed over the plex one.
I see there is an** ffmpeg-full-arm-git** in the Arch AUR repos, I guess it just won’t have the burn-in subtitle support added by plex. (I guess if it is a built-in library that won’t work)
PPS: I don’t see in the code for PlexNewTranscoder linked above, where they disable support for ARM …
Hmm: It seems plex developers already have been caught not releasing GPL code … which they have since corrected. #2974 (Plex Media Server: LGPL/GPL violation) – FFmpeg
I’ve been told on some ARM platforms they just dont ship a transcoder binary, which I guess effectively disables it.
Anyway, in the ARMv7/RPi2 thread they have a working transcoder binary included. From what I’ve read about the RPI3, the platforms remain binary compatible so that may work there too, which may have enough grunt to actually transcode video rather than just remuxing / audio transcoding only.
Well on the odroid it does transcode(standard Synology armv7h build), to web client, see my benchmark and transcode testing in this thread:
Just as a comparison, I have installed the emby server and using their web client tested transcoding.
Works perfectly well transcoding 1080p -> 1MB stream using at worse 50% CPU on 4-cores, 90% on one other, 3-cores idle … (compiled ffmpeg with neon support)
When I get the TVHeadend plugin for emby working, I will be switching.
At least their developers don’t punish you for using ARM !!
(…and their web client is much nicer than Plex’s IMHO)
Early 2021 clean-up: while Arch-Linux as a distribution is not officially supported, Plex has added/implemented support for ARM on various supported platforms (Linux, NAS…)
