Kodi Community Forum

Full Version: atv2: UPnP or CIFS? Which is the better option?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
I realize that there is no nfs or afp available for the atv2 due to kernel restrictions, but I'm curious about the different options/limitations for SMB or UPnP. My atv2 is running an official release. All of my media is on a home linux NAS that I built. Rather than dealing with SMB, I just put up a MedaTomb server. I'm able to stream movies with no issues. The problem is that nothing seems to be added to my library. It looks like it's not scraping anything. No thumbnails or movie data is displayed, I just have to browse to the movie by navigating through the directory path. Is this a limitation of UPnP? If so, what are some others? If not, can someone please offer some advice?

Thanks
The only real limitation for UPnP is that the URLs are frequently not stable, so you cannot add it to the library.

smb:// or smiilar does not have this issue, as the URLs are stable.
By "not stable" I guess you mean not static? I was really hoping that I wouldn't have to go to smb/cifs. I would love to see an nfs4 mount option, but I realize that is an iOS issue and not XBMC.
vagabondking, I think the topic of not being able to use the library feature of XBMC because uPNP's url isn't static comes up with every thread about the subject. So it may be faster to look for those threads in case nobody gives you a definitive answer.
Correct, not static.
I think there may be a better alternative.

I'm using wifi between the (Windows) PC and ATV2.
I have been using CIFS so far, but have problems with buffering with 720p (even the relatively low bitrate WEB-DL).

I know this should be possible, since I've been playing this content fine with a Popcorn Hour. (Using same wifi). One difference is I stream using http to Popcorn (with lightttpd running on PC).

So, I tried creating a .strm file with the http url for a problematic file, and ATV2 played it perfectly. No buffering. Seeking/FF works. Tried a harder file (8GB h264 movie) and it played fine.

Now it looks like I can use the the http path when I add a source, and the file view definitely works, and it looks like library mode will work (I'm currently rebuilding library).

Seems worth investigating, as a lot of people are having buffering issues.
Wow! Can you please elaborate? What is the spec of a .strm file? I'm already running apache so this solution would be great. I'll do some digging on my own, but if you can offer some pointers it would be very helpful. I was in the process of looking for a good IOS hacking community to see if there is a way to insert the nfs kext into the prelinked IOS kernel, but http is much much easier.


[UPDATE]
2 seconds worth of RTFM:
http://wiki.xbmc.org/index.php?title=HOW...io_streams
Question about the .strm files. Do you need to create one file per media file on the nas? Can you provide more details?
The suggestion was to try it with one .strm file to see if it helps.

My test .strm file looked like:
Code:
http://192.168.4.9:8001/Videos/Movies/Movies/The%20Dark%20Knight%20(2008)/temp/The.Dark.Knight%5b2008%5dBluRay-HD-iNFAMOUS.mkv

And it worked. The next thing I tried was a path substitution to map smb:// addresses to http:// addresses.

In /private/var/mobile/Library/Preferences/XBMC/userdata/advancedsettings.xml
Code:
<advancedsettings>
   ...
  <pathsubstitution>
    <substitute>
      <from>smb://192.168.4.9/Public/</from>
      <to>http://192.168.4.9:8001/</to>
    </substitute>
  </pathsubstitution>
</advancedsettings>
which made my while system use http:// paths, but only file mode worked. It seemed to break library mode.

Possibly removing database and rescanning now would work.
What I tried next was to edit my sources.xml and replace smb:// paths with http:// paths. It appears to be rescanning now, but is not complete.
I use FTP on my NAS for streaming and it works fine for the most part. There are a few limitations that I would like to see fixed at some point, but for the most part it works fine. I find it performs much better and more reliably than SMB, although I'm not sure why.

Main advantage is that it is fully routable. If you want to stream to remote devices SMB and uPnp are not realistic options. Granted not many people do this yet, but with iPhones/iPads and what not it is nice to be able to stream from your home while on the go. Of course you have to carefully secure it if you want to do that, but if you just use it in your home you shouldn't have to worry about it. Good part is you don't need .strm files or anything special, it more or less just works like smb, but with a few caveats:

1. You FTP server needs to support REST to allow byte range requests or seeking won't work. Most do nowadays.
2. Support for .nfos when scanning over FTP seems to come and go. It has both worked and not worked at different times through the history of XBMC. I'm not sure at this point whether it works or not, as I have stopped using them.
3. Same for picking up fanart and thumbs in file mode, not sure if it works currently or not - haven't used it in ages.
4. I don't know for sure, but I don't think XBMC can write to FTP, so library exports may not work.

If you strictly use XBMC to manage your library (as opposed to an external media manager) it works well.
@popcornmix, so you do not need a strm file for each file? Just one to point to the root of your media? I'll try this once I get home.

@galvanash, thanks for the info. I would totally expect ftp to be faster than smb. However anyone with a packet sniffer can get your password. SMB is more secure since it does not send clear-text passwords over the network.

I'll report back tonight.

Thanks again
vagabondking Wrote:@popcornmix, so you do not need a strm file for each file? Just one to point to the root of your media? I'll try this once I get home.

Each .strm file will only allow you to play one file. The suggestion is to pick a file that buffers with CIFS and test if it is better over http.

Assuming it helps, you can convert your whole library to http using the advancedsettings pathsubstitution option.
vagabondking Wrote:@galvanash, thanks for the info. I would totally expect ftp to be faster than smb. However anyone with a packet sniffer can get your password. SMB is more secure since it does not send clear-text passwords over the network.

I don't use passwords at all - my ftp server is anonymous so anything on my local lan can access it (you may not be able to allow that - this is my home so I don't have any issues with doing this).

I do, however, block everything at my perimeter firewall but I have a script written for my router that lets me open holes up for a limited time (which IS password protected, but is accessed over https). So all I have to do is hit the script from a browser over https, supply my credentials, and it opens a hole for me for 24 hours from my current MAC Address/IP Address combination, allowing that machine to access my FTP server. This works for my purposes, is relatively secure, and is completely under my control. Granted the _traffic_ is not encrypted, but nothing is perfect...
At the moment, I have no issues with buffering with cifs/smb. I just haven't enabled it yet. I'm just looking for a better solution.
I setup webdav at the moment. Now to figure out how to tell if it's any better than smb.
Pages: 1 2 3