Archives for the month of: March, 2013

Bitcasa; the service that I struggle with supporting…

In theory, everything sounds good, and the end result is so tantalizing

One of the usage mistakes I made early on was to use Bitcasa for a ‘temp’ folder; the TV Shows – Downloaded folder.
The main use of this folder is to hold currently running shows that are not going to be archived, meaning it goes through a lot of usage in a week as episodes are filled in, watched, and deleted.

But, forces were conspiring

Bitcasa pulled the Ubuntu client, claiming data loss when used with any other client, and all talk of a headless version has died out.
Also, Plex and Bitcasa are not super friendly towards each other, with issues scanning in new episodes (among other minor quirks).

I personally think that this issue with new episodes is because of the way Bitcasa handles ‘infinite’ drives in linux: basically mounting a folder ‘on top’ of the old one, leaving all the old content there to wait for the day that you deactivate and remove it from Bitcasa (I did this today and had to bring the folder back up to date).

 

Some lessons to move forward with:

  1. If you plan on using the current Ubuntu client (if you can find it), plan on only using that and the read-only clients like the mobile app or website.
  2. If you really want an infinite folder, create a new, empty one and transfer data in to it: Do not turn an existing folder infinite, it’s just confusing and a waste of space.
  3. If you want to use Bitcasa and Plex, start with the free plan, and get seriously involved in both forums.
    There are things Bitcasa should be doing, and there might be things that Plex can do to work around what Bitcasa should be doing.

 

I’m still not giving giving up, of course

The idea of paying $20/month + $10/month for all this:

  • automatically handle all the downloading,
  • transcoding,
  • and serving to
    • RasPis,
    • Rokus,
    • iPhones,
    • iPads,
    • Friend’s AppleTVs (through AirPlay),
    • and every other device the Plex supports
  • never having to worry about bandwidth complaints
  • or content notices that the ISP has cooperated on
  • keeping the home FTTH connection super responsive by keeping the concurrent connections as low as possible

as well as the ability to stop maintaining an in-home server if I choose to…

is just so much better than the old way.

Advertisements

As I mentioned last time, one of the things to be aware of when running RasPlex for the first time is how very slow the UI is before the cache is built..

With our larger library, it took a few days to cache everything properly.

Note: Based on the speed of development, this is going to be outdated information VERY quickly.

I’ve been doing a bunch of other projects, so now need to update, and want to preserve the cache (of course).

So, since I have to go through the process anyway, it’s sharing time.

  1. ssh in to the Raspberry (default username/password: “plexuser” / “rasplex” (no quotes) )
  2. Transfer the ‘/storage/.plexht’ folder to your local computer
    (I would normally suggest using gzip, but that would involve the tiny CPU, so I personally just transferred the whole folder with rsync. SCP and other SFTP programs are good choices too)
  3. Use the GUI Installer to update RasPlex (which is a nice choice that only means pressing a couple buttons)
  4. Boot up the updated version
  5. Transfer everything back, overwriting the updated ‘/storage/.plexht’ folder

And, a pleasant bonus:

This process keeps the myPlex login info, and all other Plex personalizations.

Honestly, it’s been a little bit since researching and trying new HTPC software has pulled me in, and recently I’ve been shown

just how wrong it was….

In previous posts, I talked about how the dream setup was to have a lightweight Plex client installed on the RasPi, so that it would just be a matter of the well-established Plex server serving content to any number of RasPis automatically.

Recent work, however, has blown this entirely out of the water!

In what seems like the blink of an eye, RasPlex has sprung up, bringing a complete port of the new codebase of Plex/HT to the RasPI version of OpenELEC.

Seriously; the entire (Next generation) Plex desktop  client is now on the Raspberry.

Even the site is flash, yet looks like it works with it’s hands – very nice.

Initial impressions: Fantastic.

One caveat: The FAQ warning at the bottom of this page mentions having to ‘warm up’ the cache in order to have a responsive UI, but it’s not a well-known fact, and the first boot of RasPlex had me thinking that my Raspberry was slacking – 3-4 second response times to the plex remote, taking over 7 seconds to start a video, grinding to a halt when AirPlay was tested…

With with size of our Plex library, it was still caching 30 minutes later, and was still fairly sluggish before getting up to this speed a while later (left it on all night).

TADA! Raspberry Pi and Plex; together in the future at last!

After having used Bitcasa for the past two months, the potential is obvious.

There are still a few things to work out, however…

First and foremost: there is no ‘headless’ client.

Using the Ubuntu client on a headless server requires installing the X Libraries, a window manager, and a VNC server so that it runs in it’s own (networked) GUI.

The client itself feels unpolished, and moving a large folder from a ‘backup’ folder to an ‘endless’ folder requires re-uploading the files.

Moving forward,

thinking towards having a cloud server downloading files and serving them through Plex to all the different devices, including Raspberrys (Raspberries?); something like Bitcasa makes more and more sense: Download to an infinite drive, and you can move servers at will, or scale up/down on the fly without having to worry about shuffling terabytes of files between instances…