Tweet
Can anyone explain what exactly is GDC's CineCache storage? I'm familiar with HDDs and SSDs. Is the CineCache just an embedded SSD or something entirely different? Does it have any redundancy like a RAID? I see they have a 4TB option now. I had always assumed a cache was a volatile memory source like RAM.
-
-
CineCache uses an embedded NVMe SSD as cache device for local content, which can also be distributed to other screens. There is no RAID-like redundancy in this "cache memory". -
CineCache has some advantages- No external storage.
- Content transfers at normal speed, even while the movie is playing.
- Lower Cost.
Don't confuse CineCache with their new PSD systems that use SSD drives...they are new PSDs (PSD-4000)...not just the old PSDs with SSDs in them. The new PSD-4000s can go up to 6TB, at the moment and do offer RAID redundancy. They still have Enterprise Storage up to 16TB using conventional 3.5" drives.
CineCache is also used with GDC's streaming TMS/LMS whereby the TMS/LMS (aka SCL) has all of the content and the content is streamed to each server in real-time. The local server will cache content during the stream so, in the event, there is a problem with the stream, the server will have the last 2TB of content, locally, to continue playback.Comment
-
As I have understood it during our implementations, Cine Cache can be used as rather fast on board memory for content, limited to 2 TD. But that wouldn't explain the Cache wording.
The SR 1000 can be used with external storage boxes (Enterprise Storage) and networked storage and library systems. In this case the local server will use the NVMe as local storage to cache during playout, which would explain the denomination.
Comment
-
It seems to me that the streaming TMS and CineCache combination is, in the vast majority of cases, a solution looking for a problem.
If I understand it correctly, the idea of the overall system is that DCPs play directly from the TMS, streamed to the media block, most of the time, with CineCache on the SMS being a fallback for use in case of network disruption.
Why do it this way? Compared to a traditional TMS and SMS storage/transfer system (DCP transfer does not have to happen in real time, and SMS storage is a local RAID5 of SATA spinning rust or SSD drives), I can't see that it offers any advantages for all but a tiny minority of theaters, and it adds cost and reliability risks. Maybe if you have, say, a 50-plex of tiny auditoria that need to be able to play any one of 500 movies at almost zero notice (as in, less than the time it would take to transfer a DCP from the TMS to the SMS at 50-100 MBPS), that could be a justifiable use case, but I'm struggling to think of any other.Comment
-
Leo,
There is a theatre in Ocean City, Maryland, that using this system. The reason that they use it is because 6 of the 7 auditoriums are located in "pods", fairly inaccessible unless you have a large ladder. It's been is in use since 2019. The only disadvantage to the streaming system that I see is that NO ingestion can take place while ANY films are running. Using this system with GDC's automated setup has proven very useful. It eliminates most of the "user error" that other theatres have. I personally like the system.Comment
-
The advantages of the streaming system seem fairly obvious to me, Leo. Ingest once, play wherever. Since most servers choke while trying to transfer while playing content (run incredibly slow FTPs)...the only solution theatres have come up with is to run the projectors/servers 24/7. What a horrible waste of electricity plus it pumps dirt through the projector at, roughly, double the rate needed. This is even more slanted for cinemas that don't run matinees (during the off-seasons).
We have even smaller plexes where they have to schedule around moving all content to all screens so they can have it there incase they shuffle theatres. This also affects the size of the drives you need on each screen. With a streaming system, you don't need large local storage anymore so it can be more cost efficient. I agree with you on the concerns for reliability and probably cost though you'd really need to weigh the cost of the super TMS system versus having all of that storage out at SMS servers.
Remember too, for QSYS (audio), I, often, opt for using a pair of cores to service the complex rather than separate cores on each screen. I do use dual networks and dual cores...The system needs dual failures to go down...thus far...none have. Even on 2-screens, I prefer doing a dual-core that serve both screens...why? When configured this way, both theatres get backed up because both cores would have to go down. In a separate core per theatre, if either core goes down, one theatre went down.Comment
-
And tell each studio to send you 50 keys for every movie?Ingest once, play wherever.Comment
-
The easiest way to look at it is that it is like having a permanent M.2 type NVME SSD built right on to the motherboard. The makeup of that sort of drive and small parts count allows that to be done. There are 2 tb drives that fit in the palm of your hand, so very little real estate is used.Comment
-
Frank...if only 50...The studios will send every key imaginable for every title...open cap, closed cap, 5.1, 7.1, IAB, 2D, 3D...and every permutation. Plexes get flooded with keys constantly. Most of them have KDM email client to allow the ingest to happen in the background. The TMS then sends the keys out the appropriate server. Those with manual KDM ingest often just get a ZIP file with all keys for the site on a title...ingest the ZIP file to the TMS and let it send them where they need to go.Originally posted by Frank Cox View PostComment
-
It's pretty amazing! I've got two of these little CRUCIAL mini-SSD drives that I often useOriginally posted by Mark Gulbrandsen View Post
to move content between home and the theater. I have one 4tb and one 2tb- - they're
externally identical, and as you can see, they are about as square in size as a box of AA
Batteries - - only the drives are about ½ as thick!
MiniDrv.jpg
I've also got one of these more or less 'permanently' connected and velcro'd to the back of
my i-mac which I use to increase the Mac's storage capacity without having to open it up
& replace the internal SSD. The Crucial's 1050 Mb/s read-write works good enuf for me !Last edited by Jim Cassedy; 11-07-2023, 07:08 PM.Comment
-
CineCache is like a built-in non-volatile storage for cinema servers—stores movies for playback, more permanent than RAM. No standard RAID, but still keeps films safe.Comment
-
That's not been my experience, if the media LAN is set up right: figure 20-30 minutes to transfer a feature, which the server can handle while also playing. Point taken that the GDC approach is a better fit if you want to shut down everything in your booth overnight to save power. As against which, the media LAN requirements for the GDC system are nontrivial, likely requiring new switches and architectural cable runs if installed in an existing site. In addition to that, CineCache essentially requires you to keep your SR-1000 in warranty or to be prepared to cough up in the high four figures at any moment for a new one, because the flash memory cannot be replaced independently from the rest of the server/media block.Originally posted by Steve GuttagComment
-
Which server, Leo? Certainly not a GDC or Dolby/Doremi. The DSS servers could transfer at full speed while a show is running, but I've yet to see the others do it. The IMS3000 seems to do better. Not the older IMS or any box-server. Pray tell, what magical media settings are you applying to that NIC beyond specifying the IP and subnet mask?Comment
-
with cinedigital TMS our transfers between screens run 20-30 minComment
Comment