[cr77]

Look forward to the results of the webdav stream.

I didn't know Upnp URLs weren't stable / static which is a shame as they've worked extremely well for me so far.

Is Upnp a less intensive protocol than smb/cifs hence why people seem to get better performance from it?

My readynas has options for upnp/smb/http so am wondering which is the best in terms of reliability and performance.

[vagabondking]

Honestly it's going to be tough to test things out. Without knowing how xbmc handles different sources. I have an idea of what I should do, not I just need some time.

Setup: Samba, FTP, Webdav, UPnP and XMBS.

For each of the above methods:
Play the same video while doing a full packet capture. Reboot ATV2 at end of movie and move to next protocol.

I was gong to then run the captures through wireshark and similar tools to generate statistics.

There are going to be quite a few variable that I am not going to be able to compensate for, but this is the best test I can think of. Time and bandwidth are static, so I'm gong to look at number of packets, amount of data transmitted and anything else that comes up that might be useful.

[nienburg]

I think in this situation, you are making things more complicated than needed.

To be honest, cifs/samba works great for the average person. I would honestly just use it over anything else. If you have issues, then sure, look into the various alternatives mentioned here.

I however agree with the others, upnp is not a great option, I would avoid it if possible.

cifs is the way to go.

[vagabondking]

Why is UPnP not a good option? and why is smb/cifs a better option?

I'm not looking for the easiest to configure, i'm looking for the most efficient.

[topfs2]

They serve different purposes. If you want to share files then use samba, if you want to share complete libraries then uPnP is the way to go.

As for performance, they ought to be the same for the client. uPnP allows for transcoding etc so depending on the client it may add load to the server (if the server allows for transcoding etc.)
EDIT: XBMC is such a client which more or less allows everything afaik so should not add anything significant on the server.

[vagabondking]

I would expect protocols like UPnP,FTP and Webdav to have less overhead than SMB. From what I understand, the SMB protocol is encrypted while DAV and UPnP are not. To me, that sounds like SMB has more overhead. Of course, more aggressive TCP window scaling and caching might make up for that, but I don't know if samba does all of that.

I would just copy files to the atv2 from my NAS, but not all protocols allow direct copying and I'm not sure how XBMC connects as a client.

[topfs2]

You need to define what overhead because encrypting a channel will not add bandwith overhead (unless the encryption adds data to mask the size, which most don't) and as such caching won't matter (in the comparison at least). It will obviously add cpu overhead and introduce some latency, both of these are depending on the situation uninteresting.

Secondly, I'm not sure if smb is encrypted. I would not be surprised if it is but I don't see why it would need to be (its designed to be used in a local network where encryption is seldom needed).

[vagabondking]

I realize that bandwidth is the same regardless of protocol, it's a matter how much data you can push through with the available bandwidth. I'll do some digging about samba and encryption. I have to admit that I have an aversion to samab, it's just always been slow.

[topfs2]

I don't see how protocol and encryption matters if you assume that your server is able to encrypt and handle the protocol cpu overhead.

i.e. if samba produce X amount of data with Y CPU usage and uPnP produce the same data size (lets assume this for simplicity) but with Z CPU usage. If we say that Y > Z both will produce the same amount of data per second given that your cpu is not limiting the transfer, i.e. if your CPU > Y > Z. Obviously the first batch of data will take longer if we encrypt which is why I said it introduces latency.

[vagabondking]

You are correct, samba traffic is not encrypted. It's just the authentication handshake that gets encrypted.

[topfs2]

You are correct, samba traffic is not encrypted. It's just the authentication handshake that gets encrypted.

correct and correct, I had no idea Interesting that they use encrypted handshake and nothing else, oh well, I'm far from networking expert so they probably had a reason for it

[procrastinator]

I used to have terrible trouble with streaming content over SMB on my Windows install of XBMC, but had no such problems over UPnP. When I posted in the general help forum I got this reply from Hannes The Hun

sorry, it's just too obvious... my only explanation for why UPnP works and SMB does not would be that SMB has quite a big overhead compared to other network protocols. long story short: try to switch to wireless N or (esp. necessary for HD material) use LAN instead.

If you're interested in finding out more I suspect that he may be able to help you understand the differences

here's the original thread BTW: http://forum.xbmc.org/showthread.php?tid=82409

[vagabondking]

Thanks for the link. I would expect that SMB has a much more overhead than UPnP as "Hannes The Hun" said, but the issue with UPnP is that there is no Library import. Although with mediatomb and the <pathsubstitution> directive, I believe that it might be possible to make a hack to get library support working with upnp, but it would be ugly. I'm not quite ready to head down that road yet.

[galvanash]

Thanks for the link. I would expect that SMB has a much more overhead than UPnP as "Hannes The Hun" said, but the issue with UPnP is that there is no Library import. Although with mediatomb and the <pathsubstitution> directive, I believe that it might be possible to make a hack to get library support working with upnp, but it would be ugly. I'm not quite ready to head down that road yet.

I personally think the differences between the protocols performance have more to do with the implementations of the client libraries used in XBMC and the differences in XBMC itself when it comes to supporting certain actions on each protocol (particularly stating files and such). Also, certain protocols are treated as "remote" by XBMC which results in certain code paths not being active (like scanning for .nfo files and thumbs over FTP). The point is they are not all exactly on absolutely equal footing and comparisons are really about XBMC's implementation of client support for said protocols, not the protocol itself.

For example, http is extremely slow relative to other protocols when it comes to listing directory contents. This is because file sizes are not parsed from directory listings - instead XBMC issues a stat on every single file in the listing to get its size. There are lots of other examples like this where there is special handling for certain operations depending on the protocol used.

[Starstream]

Thanks for the link. I would expect that SMB has a much more overhead than UPnP as "Hannes The Hun" said, but the issue with UPnP is that there is no Library import. Although with mediatomb and the <pathsubstitution> directive, I believe that it might be possible to make a hack to get library support working with upnp, but it would be ugly. I'm not quite ready to head down that road yet.

It's possible to do a library import with UPnP as long as the UPnP server exposes the filename of the movie in it's path unfortunately very few actually do this, you get random numbers or various other bits of info.

One of them that does is PS3 Media Server, add the server (dont use set content when prompted) browse the listings to your folders then bring up the context menu and select set content. It will import the media into the library, the only side affect is that you cannot refresh movie info so if it gets an ID on the movie wrong you will need to start from scratch again.