Tech Forum

The next LDSTech Broadcast is this Friday at 12pm MST. The topic is Getting Digital Media into Meetinghouses. Read more details here: http://bit.ly/RtIYbi

(If this thread is intended only for announcements and not for discussion, please feel free to delete this post.)

The featured article says the "wireless Internet" bandwidth is not sufficient. On the off chance it hasn't already been considered, my suggestion would be a caching proxy in each meetinghouse.

There should be much higher intra-meetinghouse bandwidth than the thin pipe to the outside world. A caching proxy should be able to support at least several simultaneous streams, perhaps dozens with multiple access points. The caching proxy could hold the most popular content locally and even be push-loaded in advance of any local pulling of new content. Hardware as low-end as a Raspberry Pi with a couple hundred GB of storage wouldn't cost much. A volunteer project ought to be able to lash together enough open source software to do the job.

rmrichesjr wrote:The featured article says the "wireless Internet" bandwidth is not sufficient. On the off chance it hasn't already been considered, my suggestion would be a caching proxy in each meetinghouse.

We've discussed that in the forum, but I'd like to see CHQ get on board with the idea.

Russell, I'm not the right one to pitch this idea to. I'll forward your post on to one of the meetinghouse tech leads.

This is a concept that we've been spending a lot of time on for a while now. There is the potential that we will eventually move toward this type of solution, but there are some fairly significant challenges when you think just beyond youth curriculum in the English language. How do we keep content updated? How do we distribute media in the local language to the appropriate meetinghouse without downloading every video in every language to everyone? Once it's on the server/cache, how do you make it easily accessible for users without creating a huge support burden? I'm certainly not saying that these issues can't be resolved, because they certainly can; it comes down to cost/benefit, time and resources required vs. other priorities, etc.

But rest assured we have been spending time on this topic for quite some time now and continue to work on potential solutions. But definitely nothing to announce right now.

This is what we've done in my stake, it has taken a great deal of time and effort, but so far reaction has been pretty positive. Though just in our first few weeks, the ongoing maintenance, as it's been automated will prove to be the largest issue.

The skill sets require someone experienced in networking, systems, audio/video/image streaming and content management though metadata, cloud based apps and content distribution, caching services, auto-discovery, personal desktop firewalls, and IOS/Android/Windows, etc web browsing. I happen to have all of these skill-sets in varying degrees, and have found that most people can catch on to a 'Netflix' like menu system. My stake is composed of affluent white-collar families very conversant with technology to farmers and small town members not too technically sophisticated. I think we'll make a pretty decent experiment for the team.

That said, Kurt points out the very real issues out there, I'm in an english-only area, and I'm the one supporting it, but I also have other things like a family and a job. The pro/con would need to be what does it take to support a caching server at a meetinghouse vs budgeting for greater Internet Speeds in our meetinghouses? Greater Internet Speeds + Roku (media streaming device) Mormon Channel may be cheaper and easier, centrally control the content, but allow for greater internet speeds. Maybe I could stop spending $50 per month on Internet and instead spend $150 a month or $200 a month.... I could trade the cost of physical phones for voip and likely SAVE money.

Kurt, I hope these are all considerations.

John - sounds like you've done some pretty cool things! You do a very good job at pointing out the support issues, and of course anything we roll out from Church HQ has to be supportable worldwide.

I'm not sure that just increasing bandwidth is ever going to be the solution. I think there will always be too much competition for live streaming of videos to ever work well, which is why we are pushing hard on the message that users should ensure that the content is available beforehand - either on your mobile device, or on a USB stick, or perhaps someday in the future on a media server. One of the big issues is the way the player behaves - how well it can buffer, etc.

In an ideal world, a media server in a meetinghouse would "sip" content from Church HQ servers during off-peak hours (middle of the night, etc.), and could keep updated without requiring huge bandwidth pipes.

But I hear you - always nice to have more speed in the meetinghouse in general.

ksolsen wrote:This is a concept that we've been spending a lot of time on for a while now. There is the potential that we will eventually move toward this type of solution, but there are some fairly significant challenges when you think just beyond youth curriculum in the English language. How do we keep content updated? How do we distribute media in the local language to the appropriate meetinghouse without downloading every video in every language to everyone? Once it's on the server/cache, how do you make it easily accessible for users without creating a huge support burden? I'm certainly not saying that these issues can't be resolved, because they certainly can; it comes down to cost/benefit, time and resources required vs. other priorities, etc.

But rest assured we have been spending time on this topic for quite some time now and continue to work on potential solutions. But definitely nothing to announce right now.

If it's a pure caching proxy, then there are almost no management/administrative challenges. The language(s) that is/are used at the meetinghouse will be captured the first time for each title, then served by the caching proxy thereafter. Simply maintain one global list of URLs (or better, regular expressions for URLs) of what the proxy is allowed to cache. Then, to paraphrase Brother Joseph, let the caching proxy govern itself.

If it's a managed caching proxy, an automated monitor of access logs should be able to maintain a database with a list of languages downloaded by each meetinghouse. Then, for each meetinghouse, stock it with any language that accounts for some threshold fraction (maybe 10%) of its traffic. I would imagine it would be relatively rare for a meetinghouse to have substantial traffic for more than three or four languages.

With either a pure caching proxy or a managed caching proxy, user access would be transparent. When a user tries to access an URL that is cached, the proxy simply serves that URL's content from local cache. If the content is not local, then the proxy downloads it from the central servers and stores it for next time.

If it's anything other than a transparent caching proxy, it sounds like JohnShaw has some good ideas.

My consern about a proxy server is that the content won't be there the first time it's needed. If it doesn't work the first time, I'm not sure as anyone will trust it later. Possibly a managed proxy server.

ksolsen wrote:How do we distribute media in the local language to the appropriate meetinghouse without downloading every video in every language to everyone?.

May I suggest a setting under the control of the STS? The reason I say that is that there is no database that contains all the information. The languages of the wards in that meetinghouse might be a good start, and you can use that when initializing the device for the first time. But, a ward may well offer a Sunday School class in another language and that may not be reported anywhere beyond the local leaders.

All I ask is to not try and not get too fancy with the automation. It's the "automagic" part of the recent projects that seems to be the most problematic. So I'd say automate the grunge work, but as far as the configuration, keep it simple. It's easier to teach people how to do what they need then it is to tell them "nothing you can do until they fix it".

ksolsen wrote:Once it's on the server/cache, how do you make it easily accessible for users without creating a huge support burden? .

If it's a proxy, then it's transparent. But it does undermine the current message of "don't expect the Internet to work for streaming". I'd suggest a standard local name. Perhaps the Firewall can catch that name and route it to a locally configured static IP.

I have tried several solutions and spent quite a bit of money trying to buy cables to support all configurations (hdmi/vga/composite/crt). I had training meetings but members left with "deer in the headlights" eyes.

I have a prototype of a solution that simplifies everything - using RaspberryPi devices ($35 each). The short description is this:

-one device acts as a file server (ArchLinux ARM distro) with an attached external usb drive for local storage (1.5TB+) of the church media that provides a network share (samba). This is so we didn't have to open shares on clerk computers w/ MLS installed.

-each TV has it's own RaspPi device (RaspBMC as a media center) attached via hdmi or video/headphone jack (old CRT). And a cheap $6 usb remote control is attached. Also required is a small usb wireless dongle so memebers don't have to plug into an ethernet port (considering using a usb expansion port so users don't have to unplug wireless to attach their own usb drive).

This provides several simple options. Members can:

-browse for videos on LAN share using remote control
-bring video on USB drive, then browse for it using remote control
-stream it wirelessly from iOS (Airplay - built-in support) / Android (UPnP - requires free app)

I wrote a script that monitors (scrapes) mormonchannel.org for video content. When it finds new videos it submits the download url to a bittorrent site (burnbit.com) which gives me a url for the resulting torrent file. I then build an RSS feed (here's one of the feeds: http://admin.platinumvipcard.com/api/rss/1) from the torrent urls and the file server I mentioned above has a set of programs (Transmission + FlexGet) that can read a torrent feed and download the files. So when a new torrent is added to the feed all the file servers in each building automatically download it. The result is anything I can add to the feed (scraping or manually) can be downloaded to each building so members can access it over the local lan and it's there the first time they need it.

I also had the idea that the file server could host a media streaming solution so users with tablets could simply use their built-in web browser and play videos on their devices w/o needing the RaspBMC devices (works well in small classrooms).

The details are unorganized, but they're all here: https://docs.google.com/document/d/1Lwd ... vzYVs/edit

But here's the downside. I only got as far as a prototype - works at my home. Then I just got called to the bishopbric and I don't have the time now to finish it up. My hope had been to get it polished so I could host two image files (ISO) for the file server and media center that would require as little setup as possible and provide a web page with clear & easy setup directions.

I'm now hoping there's someone with some time who could pick up where I left off - most of the work is done, just needs some polish and cleaning up the documentation. Feel free to PM me directly.