Cinesend

[Harold Hallikainen]

Thanks! Looking at the wget manual at https://www.gnu.org/software/wget/manual/wget.html , I see "Wget has been designed for robustness over slow or unstable network connections; if a download fails due to a network problem, it will keep retrying until the whole file has been retrieved. If the server supports regetting, it will instruct the server to continue the download from where it left off."

Aspera claims to be faster than HTTP or FTP and appears to be based on UDP. I think of HTTP as a layer on top of TCP which is a layer on top of UDP.

Bit Torrent is also interesting since it spreads the "server side" around.

Harold

[Marcel Birgelen]

UDP and TCP are both layers on top of IP. TCP is a bi-directional transmission protocol that includes error-checking, balancing/throttling mechanisms, etc. UDP is just a datagram protocol. HTTP works on top of TCP and wget primarily uses HTTP(s), but can also use FTP (a troublesome protocol using multiple TCP ports, one for signalling and a separate port per transfer, especially active FTP (the classic version) often wreaks havoc on modern firewalls).

Yes, you can resume downloads if the server on the other side supports it. What's more problematic though, is error checking. You can create a separate hash of a file, e.g. a "zipped" DCP, but if you conclude at the end of the transfer it doesn't match, you don't know where it went wrong. So, you need to transfer the whole file again.

More modern data-transfer protocols divide files into chunks and use more elaborate hashing (lile Merkle trees), they can detect where the transfer went bad and you only need to re-send the affected chunk or chunks instead of the entire file.

Also, a modern download protocol can use multiple TCP sessions or implement their own "balancing" using e.g. UDP. The problem of a single TCP stream is that it often performs bad over links with high latency due to the TCP window size. That's the size of the buffer that the other side keeps on sending, until it receives an ACK from the other side. While there are possibilities to increase the TCP window size, today's internet is a difficult stack of all kinds of devices like firewalls that might interfere with that. So, opening multiple TCP streams can often increase transfer speeds.

Personally, I have my doubts with some implementations using UDP. There are lots of people out there that don't understand the fabric of the Internet and the way TCP works and how it more or less keeps the Internet together. As long as we keep building on top of TCP, the internet is "safe" so to say, from most stupid mistakes developers tend to make. UDP can be a dangerous tool in the wrong hands. It doesn't "self balance", if used incorrectly, it will fill all bandwidth it can get, even if it's supposed to share it with other users...

But you don't need to invest all the work into developing the most ideal transfer protocol. The bit-torrent protocol, even if employed as a point-to-point transfer protocol, for example, is as efficient and fast as it can get, checks all the checkboxes mentioned above and the protocol is open-source and implementations exist for all kinds of platforms. Maybe, marketing-wise, you may call it differently, because the movie industry might be afraid of the name...

[Scott Jentsch]

Using the BitTorrent or similar protocol among trusted devices would be an incredible way to provide distribution, in my opinion. However, with the close association of BitTorrent and piracy, I can't imagine anyone in a board room approving such a thing. A clever engineer would have to call it a "secure distributed mesh network protocol" or something equally buzzword-worthy to prevent the aneurysms that would happen with the mention of BitTorrent.

If the system can limit the bandwidth consumption so that it doesn't overwhelm the connection, that would also be ideal. An intelligent system would see when a file was needed and give it priority over other files to be transferred and how much bandwidth it could consume in order to meet its target. I wonder if this box does that?

[Frank Cox]

I've installed the Cinesend gadget into my projector pedestal, got it wired, and turned it on to see the pretty lights flash.

They're supposed to get back to me with what the next steps are after this.

There are at least five fans in that thing, so it runs fairly loud. My UPS tells me that it draws 40 watts doing nothing in particular.

They told me that I can shut it off if I'm not expecting to receive any content, but there's no obvious way to do that short of pulling the plug or removing the face plate to access a power switch. And a lot of equipment doesn't like to be crash stopped that way, so I've sent them a question about that as well.

[Carsten Kurz]

What type of internet connection do you have?

[Frank Cox]

Right at this moment I have a 25mbps DSL connection and a 10mbps cable connection. I can get much faster service when I need it. I told the Cinesend guy that I'll get the faster service when there's something to download; no need to pay for a higher speed service that I have no current use for.

Their minimum required speed is 50mbps according to the email that I got from them.

[Harold Hallikainen]

DSL has gotten a lot better over the years. When I first got it, 6 Mbps down was high speed. Now at home I have 120 Mbps down, 20 Mbps up using two pairs.

[Carsten Kurz]

Okay, as a single screen, 25MBit/s may actually be a starting point. Depends a bit on how long you book in advance. I know some cinemas using these services with a 16MBit/s connection. It can take one or two days to receive a feature that way. We use a 200MBIt/s cable connection, as we use three different services, and they may transmit overlapping. In general, most companies consider 50MBIt/s good enough. Occasionally, this services saved our ass a few times, when we received a bad hard disc, or a disc didn't arrive as scheduled. Sometimes, we received an emergency transmission within two hours after we reported a problem. Sometimes, when we book a new title, we see the transmission starting a few seconds after we hang up the phone with the booker.

[Leo Enticknap]

A day or two to receive a feature is not a problem if you only play 2-3 features a week.

[Marcel Birgelen]

For a single screen, 25 mbit/s might be OK, but I'd consider the upgrade to 50 mbit/s. It will save you about half-a-day per feature, which can be elemental if you get a late delivery.
We've got a 1 gbit and 500 mbit symetric connection and even then, getting a DCP in last-minute can still be challenging, often also because the other side can't really push at a full gigabit/s... Then again, we often deal with indie stuff, that almost never arrives on-time or in the format you expect.

[Frank Cox]

The new gizmo is now installed and working. It shows up on the cinema server as another source to ingest from.

Here it is in all its.... glory?

20200429_135902.jpg
Now all I need is a movie to play and an audience to play it for...

[Marcel Birgelen]

Wow, flashy

I wonder why all "modern" equipment comes with those intriguing blue leds. What was wrong with red and green and not burning your retina in the process of flickering at you?

[Carsten Kurz]

Blue is the new green... an analogy to well known astronomical phenomena, 'blueshift' is more a technological-sociological phenomenon. Light wavelength compressed by the human attention-field.

[Frank Cox]

I am now receiving my first movie through the Cinesend gadget. I've had it turned off since I got it at the end of April, but tonight I received an email telling me to crank it up so they can send me https://www.imdb.com/title/tt8976696/

It's going to be interesting to see how long it takes to finish downloading.

[Frank Cox]

It finished downloading sometime last night, so that wasn't too bad at all.

I wouldn't mind if more of the movie companies started sending me movies that way. A guy could save quite few bucks on the ol' freight bill that way.