[happyindian]

Hello All,
This is my first post here and would like to get some feedback from users who have been using xmbc. Currently I have a desktop with Intel Xeon 3.0GHz processor and 1GB of RAM which has Centos installed on it. I have Plex Media Server installed on the system and access it using Rouk3 both of which are hardwired. With this setup I see a frequent buffering on the movie’s that I play, these movies are predominantly in .mkv format and the size vary from 1.5GB to maybe about 10GB. Superusers on Plex forum said the cause of buffering is a slower CPU and to get over this I have to upgrade my processor.
One other user pointed out to me that I can buy raspberry pi, install xbmc on it and my buffering issues would be gone. But before buying pi I wanted to be sure that this indeed would be the case, can someone please shed some more light on this? If you need any other information from my side please let me know.


Thanks,
HI.

[popcornmix]

With wired network and 10GB mkv files, I would expect no buffering issues on a Pi.

I'm talking about playing the files directly (e.g. from an nfs share).
I don't use Plex, but I would expect the result to be the same. Perhaps someone else can confirm.

[dandnsmith]

I think some research is indicated, as some people have had trouble with mkv files - seems to depend exactly what packages them and which version is used.

[popcornmix]

I think some research is indicated, as some people have had trouble with mkv files - seems to depend exactly what packages them and which version is used.

I don't believe this is true. I've never seen an mkv that wouldn't play due to the writing application.

(obviously using an unsupported codec, having TrueHD as the only audio codec, or a network/protocol with insufficient bandwidth may cause playback problems,
but none of these would be fixed by repackaging the mkv file).

[awp0]

I believe Roku added MKV support over HTTP a few months ago, which should have improved the whole Plex-Roku experience by allowing Direct Play instead of transcoding for many underlying formats. However, MKV is just a container and I believe Roku still doesn't support some of the codecs that could be inside an MKV. I think Plex attempts to detect this, and decides whether to "direct play" the file without transcoding, or to transcode the file into a supported format. If an experienced user on the Plex forum thinks that your server is underpowered and causing the buffering, then they may know that your running an unsupported format in the MKV container.

I believe the Raspi has greater codec support built-in so the Raspi with XBMC may solve your buffering problems, but it's not a certainty.

Beware that building a well-performing XBMC/Raspi solution is more challenging compared to installing the Plex add-on for Roku. XBMC is more powerful, more complex, and there are potentially more pitfalls that could be frustrating if you're not ready for it. And the resulting interface is quite different from Roku (better, IMO, but still different).

[happyindian]

With wired network and 10GB mkv files, I would expect no buffering issues on a Pi.

I'm talking about playing the files directly (e.g. from an nfs share).
I don't use Plex, but I would expect the result to be the same. Perhaps someone else can confirm.

Hello popcornmix,
Thank you for both your responses, I have few follow-up questions, when you say

"With wired network and 10GB mkv files, I would expect no buffering issues on a Pi.

I'm talking about playing the files directly (e.g. from an nfs share)."

Would this be also applicable in my case? I have all my files on a desktop running Centos and is hardwired in and plan to point RasPi directly to it.

I assume I can do a NFS share on a linux machine, is this correct?

Also what do you mean by playing the files directly? Does this mean the desktop to do all the transcoding?


Thanks,
HI.

[popcornmix]

Would this be also applicable in my case? I have all my files on a desktop running Centos and is hardwired in and plan to point RasPi directly to it.

I assume I can do a NFS share on a linux machine, is this correct?

Also what do you mean by playing the files directly? Does this mean the desktop to do all the transcoding?

Yes, NFS share exported from a linux machine should be easy.

By directly, I mean no transcoding.
The Pi can directly play all the common formats.
H.264 and MPEG-4 are most common and should cover the vast majority of your videos.
You can licenses for MPEG-2 and VC1 for a few pounds if you need them (live TV, raw DVDs and raw Blu-Rays use these).

So, without transcoding almost everything will play directly.

I don't use Plex, I believe it can transcode which should be fine, but as I have no experience of it I can't comment.
You may find that just using xbmc directly, without using Plex is a better solution.

[pecinko]

Also what do you mean by playing the files directly? Does this mean the desktop to do all the transcoding?

In XBMC you set up SMB/NFS share and access files directly. With Plex, you will play a file from a server over HTTP.

XBMC does not transcode so you will have trouble playing codec that is not supported by RPi. Plex server will transcode any non compatible but you need beefy server to make it work nicely.

There's and add-on for XBMC called PleXBMC which will allow XBMC to access Plex servers.

[happyindian]

I believe Roku added MKV support over HTTP a few months ago, which should have improved the whole Plex-Roku experience by allowing Direct Play instead of transcoding for many underlying formats. However, MKV is just a container and I believe Roku still doesn't support some of the codecs that could be inside an MKV. I think Plex attempts to detect this, and decides whether to "direct play" the file without transcoding, or to transcode the file into a supported format. If an experienced user on the Plex forum thinks that your server is underpowered and causing the buffering, then they may know that your running an unsupported format in the MKV container.

I believe the Raspi has greater codec support built-in so the Raspi with XBMC may solve your buffering problems, but it's not a certainty.

Beware that building a well-performing XBMC/Raspi solution is more challenging compared to installing the Plex add-on for Roku. XBMC is more powerful, more complex, and there are potentially more pitfalls that could be frustrating if you're not ready for it. And the resulting interface is quite different from Roku (better, IMO, but still different).

Hello awp0,
Thank you for the reply back, I do understand that building the well performing XBMC/RasPi solution would be more challenging than installing and configuring Plex. But you do feel that even with the old 3.0GHz Intel Xeon processor I would be able enough to handle all the transcoding load that would be required?

Thanks,
HI

[awp0]

Hello awp0,
Thank you for the reply back, I do understand that building the well performing XBMC/RasPi solution would be more challenging than installing and configuring Plex. But you do feel that even with the old 3.0GHz Intel Xeon processor I would be able enough to handle all the transcoding load that would be required?

Thanks,
HI

With a raspi there should be no need to transcode. I guess it comes down to this: Do you need Plex or Roku for any other reasons? If not, then you could just install XBMC on the raspi and use it without Plex. There would be no transcoding at all, so you wouldn't worry about your 3.0GHz server. It just becomes a file server, which could be handled by a tenth of that processor.

So your choices are:
1) Plex server connected to a Roku running Plex client: This is what you have now and it's not performing well.
2) Same as option1 with an upgraded Plex server: Will likely (but not definitely) solve your problem. Buffering can be caused by a lot of things. We're assuming that the Plex advice you received is correct and the problem relates to transcoding. But without more info then it remains just an assumption.
3) Plex server connected to raspberry pi running XBMC with the Plex add-in: Will likely (but not definitely) solve your problem. Unclear whether transcoding would be avoided for all formats (shouldn't be required, but who knows how the Plex server and add-in software works). If you don't need Plex for any other reasons then this may be unnecessarily complex.
4) No Plex at all. SMB or NFS shares connected to a raspberry pi running XBMC: Should solve your problem, assuming it's not a network problem or some kind of exotic codec or some other unlikely issue (hard drive dying, whatever). No transcoding would ever happen here because there is no transcoding engine. If you don't need Plex for other reasons then this is a great solution and probably the most likely to succeed IMO.

By the way, you could also test options 3 and 4 at the same time to see which one you prefer. There's no reason to uninstall the Plex server. It can run happily in the background while you're testing option 4. Hope this helps!

[happyindian]

Also what do you mean by playing the files directly? Does this mean the desktop to do all the transcoding?

In XBMC you set up SMB/NFS share and access files directly. With Plex, you will play a file from a server over HTTP.

XBMC does not transcode so you will have trouble playing codec that is not supported by RPi. Plex server will transcode any non compatible but you need beefy server to make it work nicely.

There's and add-on for XBMC called PleXBMC which will allow XBMC to access Plex servers.

Hello pecinko,
My media mostly consists of .mkv along with .avi and some .mp4 files, with this limited information would be able to comment on the ability of RasPi to play them or would you like to have more information about a particular file that I know does buffer on PLEX to see how it would be handled by XBMC?

Also with the PleXBMC add-on will XBMC try to play the file first and if it has issues will it ask plex to transcode it so that XBMC can play it?


Thnaks,
HI

[black_eagle]

See section 2.1 on this page for XBMC's codec support. http://wiki.xbmc.org/index.php?title=Fea...ted_codecs

[popcornmix]

My media mostly consists of .mkv along with .avi and some .mp4 files, with this limited information would be able to comment on the ability of RasPi to play them or would you like to have more information about a particular file that I know does buffer on PLEX to see how it would be handled by XBMC?

The container (mkv/avi/mp4) isn't enough information. It's the codecs inside that matter.
You can identify the codecs with mediainfo (http://mediaarea.net/en/MediaInfo). You could try posting mediainfo for a few sample files, and we'll say if they are supported.

The vast majority of files use the standard codecs that the Pi supports.
The main exceptions are:
10-bit H.264 (Hi10P) used by some anime groups.
videos recorded by old camera and mobile phones may use proprietry codecs (shouldn't be a problem with newer devices).
very old SD rips using DivX v3 or earlier

[happyindian]

Hello awp0,
Thank you for the reply back, I do understand that building the well performing XBMC/RasPi solution would be more challenging than installing and configuring Plex. But you do feel that even with the old 3.0GHz Intel Xeon processor I would be able enough to handle all the transcoding load that would be required?

Thanks,
HI

With a raspi there should be no need to transcode. I guess it comes down to this: Do you need Plex or Roku for any other reasons? If not, then you could just install XBMC on the raspi and use it without Plex. There would be no transcoding at all, so you wouldn't worry about your 3.0GHz server. It just becomes a file server, which could be handled by a tenth of that processor.

So your choices are:
1) Plex server connected to a Roku running Plex client: This is what you have now and it's not performing well.
2) Same as option1 with an upgraded Plex server: Will likely (but not definitely) solve your problem. Buffering can be caused by a lot of things. We're assuming that the Plex advice you received is correct and the problem relates to transcoding. But without more info then it remains just an assumption.
3) Plex server connected to raspberry pi running XBMC with the Plex add-in: Will likely (but not definitely) solve your problem. Unclear whether transcoding would be avoided for all formats (shouldn't be required, but who knows how the Plex server and add-in software works). If you don't need Plex for any other reasons then this may be unnecessarily complex.
4) No Plex at all. SMB or NFS shares connected to a raspberry pi running XBMC: Should solve your problem, assuming it's not a network problem or some kind of exotic codec or some other unlikely issue (hard drive dying, whatever). No transcoding would ever happen here because there is no transcoding engine. If you don't need Plex for other reasons then this is a great solution and probably the most likely to succeed IMO.

By the way, you could also test options 3 and 4 at the same time to see which one you prefer. There's no reason to uninstall the Plex server. It can run happily in the background while you're testing option 4. Hope this helps!

awp0,

Responses to the 4 choices you wrote down,
1) Yes, this is not performing well
2) Based on the feedback from Plex superusers I would safely say that weaker server is indeed the issue, I do not see any other bottleneck.
3) I would like to try this and as I asked pecinko with the PleXBMC add-on will XBMC try to play the file first and if it has issues will it ask plex to transcode it so that XBMC can play it?
4) I am too inclined to go this route, now for step 2, what all I need to buy and how much would I be spending? RasPi, 8GB SD Card, case to hold RasPi, adapter, maybe licenses for MPEG-2 and VC1? I do have extra HDMI and LAN cables


Thanks for all your responses and breaking up my issue systematically.
HI.

[happyindian]

My media mostly consists of .mkv along with .avi and some .mp4 files, with this limited information would be able to comment on the ability of RasPi to play them or would you like to have more information about a particular file that I know does buffer on PLEX to see how it would be handled by XBMC?

The container (mkv/avi/mp4) isn't enough information. It's the codecs inside that matter.
You can identify the codecs with mediainfo (http://mediaarea.net/en/MediaInfo). You could try posting mediainfo for a few sample files, and we'll say if they are supported.

The vast majority of files use the standard codecs that the Pi supports.
The main exceptions are:
10-bit H.264 (Hi10P) used by some anime groups.
videos recorded by old camera and mobile phones may use proprietry codecs (shouldn't be a problem with newer devices).
very old SD rips using DivX v3 or earlier

Here is a sample...

PHP Code:

General 
Unique ID : 230878312394502128714691805583106534839 (0xADB18BA82ECD8D73BD328F64259A6DB7) 
Complete name : XXXXXXXXXXXXXXX
Format : Matroska 
Format version : Version 2 
File size : 10.1 GiB 
Duration : 1h 37mn 
Overall bit rate : 14.8 Mbps 
Encoded date : UTC 2013-10-20 23:01:16 
Writing application : mkvmerge v3.2.0 ('Beginnings') built on Feb 12 2010 16:46:17 
Writing library : libebml v0.7.9 + libmatroska v0.8.1 

Video 
ID : 1 
Format : AVC 
Format/Info : Advanced Video Codec 
Format profile : High@L4.1 
Format settings, CABAC : Yes 
Format settings, ReFrames : 4 frames 
Codec ID : V_MPEG4/ISO/AVC 
Duration : 1h 37mn 
Bit rate : 11.8 Mbps 
Width : 1 920 pixels 
Height : 1 036 pixels 
Display aspect ratio : 1.85:1 
Frame rate mode : Constant 
Frame rate : 23.976 fps 
Color space : YUV 
Chroma subsampling : 4:2:0 
Bit depth : 8 bits 
Scan type : Progressive 
Bits/(Pixel*Frame) : 0.247 
Stream size : 7.85 GiB (77%) 
Writing library : x264 core 133 r2334 a3ac64b 
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:0 / analyse=0x3:0x113 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.05 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=12 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=11765 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=40000 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.50 / zones=135132,140309,q=30,deblock=1:2 
Default : Yes 
Forced : No 

Audio #1 
ID : 2 
Format : DTS 
Format/Info : Digital Theater Systems 
Mode : 16 
Format settings, Endianness : Big 
Codec ID : A_DTS 
Duration : 1h 37mn 
Bit rate mode : Constant 
Bit rate : 1 509 Kbps 
Channel(s) : 6 channels 
Channel positions : Front: L C R, Side: L R, LFE 
Sampling rate : 48.0 KHz 
Bit depth : 24 bits 
Compression mode : Lossy 
Stream size : 1.03 GiB (10%) 
Language : English 
Default : Yes 
Forced : No 

Audio #2 
ID : 3 
Format : DTS 
Format/Info : Digital Theater Systems 
Mode : 16 
Format settings, Endianness : Big 
Codec ID : A_DTS 
Duration : 1h 37mn 
Bit rate mode : Constant 
Bit rate : 768 Kbps 
Channel(s) : 6 channels 
Channel positions : Front: L C R, Side: L R, LFE 
Sampling rate : 48.0 KHz 
Bit depth : 24 bits 
Compression mode : Lossy 
Stream size : 538 MiB (5%) 
Language : Dutch 
Default : No 
Forced : No 

Audio #3 
ID : 4 
Format : DTS 
Format/Info : Digital Theater Systems 
Mode : 16 
Format settings, Endianness : Big 
Codec ID : A_DTS 
Duration : 1h 37mn 
Bit rate mode : Constant 
Bit rate : 768 Kbps 
Channel(s) : 6 channels 
Channel positions : Front: L C R, Side: L R, LFE 
Sampling rate : 48.0 KHz 
Bit depth : 24 bits 
Compression mode : Lossy 
Stream size : 538 MiB (5%) 
Title : Flemish 
Language : dum 
Default : No 
Forced : No 

Text #1 
ID : 5 
Format : UTF-8 
Codec ID : S_TEXT/UTF8 
Codec ID/Info : UTF-8 Plain Text 
Language : Dutch 
Default : Yes 
Forced : No 

Text #2 
ID : 6 
Format : UTF-8 
Codec ID : S_TEXT/UTF8 
Codec ID/Info : UTF-8 Plain Text 
Title : non-Dutch 
Language : Dutch 
Default : No 
Forced : No 

Menu 
00:00:00.000 : en:00:00:00.000 
00:03:22.994 : en:00:03:22.994 
00:08:04.734 : en:00:08:04.734 
00:15:50.867 : en:00:15:50.867 
00:18:28.232 : en:00:18:28.232 
00:24:36.892 : en:00:24:36.892 
00:30:50.724 : en:00:30:50.724 
00:34:40.704 : en:00:34:40.704 
00:40:48.279 : en:00:40:48.279 
00:46:26.200 : en:00:46:26.200 
00:51:23.122 : en:00:51:23.122 
00:56:27.426 : en:00:56:27.426 
01:00:00.472 : en:01:00:00.472 
01:03:27.053 : en:01:03:27.053 
01:08:44.078 : en:01:08:44.078 
01:14:01.979 : en:01:14:01.979 
01:18:08.058 : en:01:18:08.058 
01:22:33.907 : en:01:22:33.907 
01:27:09.099 : en:01:27:09.099 
01:30:33.720 : en:01:30:33.720