drax

No, plex' main selling point is its client driven ability to transcode. The metadata it presents is pretty much the same as every other HTPC offering, XBMC, Media Browser etc. Although it shares some DNA with XBMC they're so apart now as to be separate products. XBMC supports live TV, series recording, EPG etc, Plex does none of this XBMC and all its plugins and skins are 100% free, always have been always will be. The Plex clients for tablets and phones cost money, as does the Plexpass subscription which is the only way to use the Plexsync functionality. The amount of addons for XBMC is mind boggling, Plex has a couple of hundred, it's like comparing the Android app store to the Blackberry app store. They are completely different animals. My msg was about using BTSync in conjunction with XBMC, I really couldn't give a toss about Plex.

XBMC Thumbnails I run XBox Media Center (XBMC) with a reasonably large network. There's one server (Win7) hosting 10TB of media and it does all the donkey work. There's six XBMC "clients", 3 laptops running Win7, another running Win8 and two Android devices, all of these clients are on WiFi but the server's on a wired connection. All the machines are running XBMC 12.0 - Frodo I've set it up so that the "server" is storing the metadata in a locally hosted MySql DB which the other clients access ala this method here, http://wiki.xbmc.org/index.php?title=HOW-TO:Sync_multiple_libraries That's saved me a ton of work, but each machine still has to download it's own local copy of the thumbnails for the TV shows and movies. (If you know XBMC then you probably also that path substitution is unreliable under Frodo and no longer supported) And this is where BT sync comes in. I've shared the Thumbnails folder (\XBMC\userdata\Thumbnails) from my server to the clients and it's worked like a charm. Instead of having to download 1.7GB of thumbnails from the internet they sync up across the lan in a matter of minutes. As the server is automatically downloading new shows and movies as they become available (with Sickbeard, CouchPotato and uTorrent) the thumbnails are now automatically repopulated from the server to the clients as well. Obviously the two Android devices can't join the party yet, heh-ho. One thing I checked before I started, the filenames for the thumbnails were consistent across the different devices, this was when they were all downloading their own copies from the internet. So I'm guessing this is the same for all clients. Everywhere. Think about it for a second. This could take a massive load away from the servers of TheTVDB and TMDB (the main providers of metadata for HTPC machines), If there's any XBMC users here who'd like to test this, ping me and I'll give you the secret to my thumbnails folder. For the record, and if the devs are interested, we're talking about some 32,000+ files typically about 70KB spread across 18 subfolders, 1.7GB in total, on my setup.

I haven't used that feature yet but from RTFM my understanding is the one-time secrets are exactly that, a secret that is used only one time by one client to do a one off sync. A single user secret, and it's a very a good idea IMO, would allow one user to sync as many times as they wanted but they'd be the only one able to use that secret.

Here's what I did to get it running. I'm on a Centos box running an x86 64 bit kernel. BTW, I did all the following as root. I downloaded the i386(64 bit) client directly from the link in the welcome email, which gave me a file btsync_x64.tar.gz Then ran tar xvfz btsync_x64.tar.gz Which gave me an executable file called btsync I then ran ./btsync Checked to see if it was running and listening on the correct port [root@ tmp]# ps -efa | grep btsync root 2391 1 1 15:32 ? 00:00:07 ./btsync root 3853 27981 0 15:42 pts/2 00:00:00 grep btsync [root@ tmp]# netstat -anlp | grep 8888 tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 2391/./btsync tcp 0 0 127.0.0.1:8888 127.0.0.1:35742 ESTABLISHED 2391/./btsync I then pointed a browser at it. I ran firefox on the linux box and entered http://localhost:8888 in the address bar. That's it job done From there you're interfacing with the GUI and it's very intuitive from there.

I thought it might be an idea if we shared some of the ways we're using BTSync. Apart from giving ideas to fellow users it'll also give the devs some idea of how BTSync is actually being used IRL, which might help prioritise feature requests and bug fixes. I'm using it to send torrents to my server at home. The server runs uTorrent which is set to monitor a particular directory for .torrent files, when it finds one it imports it, kicks off the download and deletes the .torrent file. I'm now syncing this folder with my laptop, so no matter where I am, if I come across an interesting torrent, I download it to my copy of that folder. It gets synced across to my home server where uTorrrent does its stuff and deletes it. I can tell it's worked when my laptops copy of the .torrent gets deleted. No mucking around with opening up ports in firewalls and exposing web interfaces that could get compromised, no relying on Dropbox or GDrive, this is all me and all secure and it works anywhere in the world.

Okay another brain fart on this subject. The problem is that the shares are pushed out to peers in plain text. Maybe the share mechanism should go something like this :- I create a share on my local drive and generate a secret as we do now. I then distribute that secret to the people I want to. They setup their local folder and paste the secret as they do now. Their client now sends a *request* to my client, which I can then manually approve or deny. Assuming approval, my client sends an encrypted secret to their client, this secret is unique to this particular peer bonding. The secret is only decrypted by their client when it requests access to that share. My client, being the client of origin, would need some way of ensuring that this particular encrypted secret is only used once. That's actually a lot more clunky than I initially thought it'd be. Ideas ?

I think this could be a major security flaw. If I share a Read/Write secret with someone, there's nothing to stop them passing that on is there ? I mean I have sight of who's using my shares in the Devices tab (I'm using the Windows client) but I have no control over them, I can't kick/ban them, throttle them or downgrade them to read-only. I think this is gonna be difficult to implement but I think it's gonna be a must-have. You need a "ripple effect" to your shares, so people can't reshare. I'd only want to grant read-write access to a certain group of people, and maybe read-only access to a larger group, I wouldn't want any of them to pass that access on. Basically we need to be able to control the ability to limit reshares or deny them altogether.

Hi Folks, I'm pretty darn impressed with the Windows BTSync client so far, I can think of a gazillion and one uses, thanks to the devs I can see there's an overall bandwidth control in the preferences, but is a more granular approach on the roadmap ? When BTSync goes mainstream I can see this sort of feature being requested. Basically what I can see a need for is a way to set the overall bandwidth (done already) and within those limits set slices of that bandwidth on a per folder basis and/or per device basis. Perhaps instead of setting hard / soft bandwidth limits, setting priorities on different folders / devices might be easier to implement ? Probably be more intuitive too. Given the mobile nature of our devices it might make sense to have the ability to setup different profiles, Home Lan, Work Lan, Public Wifi etc with predefined bandwidth limits and priorities. And I'm being greedy here, but maybe auto-detect whatever type of network we're on and run the appropriate profile. I suppose throwing in a scheduler would make sense too. I haven't been a dev for a long time but I have a feeling this is a lot to ask for, and like I said none of this is a deal breaker for me but I'd be willing to bet small, though vital parts of my anatomy that features like this will be a popular request.