|
This topic comprises 2 pages: 1 2
|
Author
|
Topic: DSS200 FTP Oddness
|
Steve Kraus
Film God
Posts: 4094
From: Chicago, IL, USA
Registered: May 2000
|
posted 08-05-2018 11:50 PM
So this happened today; hopefully it's just "one of those things."
Dolby DSS200 with internal medial block (Cat.862) running 4.3.5.13 Server stays on all the time. I reboot it every couple of months; the last time was a couple of weeks ago.
Projector is turned off when not in use. Was off at the time. (In case it matters it's an NEC NC1200C.)
There is no library server.
I usually load keys from home. I do not make the server (or projector) accessible from outside so what I do is use "desktop sharing software" to connect to the booth PC, upload the key(s) to that computer's HD, and then run Core FTP on the PC to connect to the server and transfer the key. I look at the server via a VNC program on the booth PC.
Today I went to load a key and the transfer from booth PC to Dolby server, normally a second or two, would just hang. After about 4 minutes it would complete but variously showed the file name with 0 bytes or sometimes 28K on the server. But, as seen over VNC, even when it was 28K there was no key recognized by the server.
So I traveled to the booth in person and brought along a couple of keys on a thumb drive. The one I need and also, as test, one for another version of the movie which I had not ingested.
Thumbdrive was recognized and keys loaded normally. On the Existing keys page both were shown with the unneeded one marked UNKNOWN instead of FEATURE as it did not match any content.
I had a couple of movies to ingest so I put one drive in the CRU bay, it was recognized, and I clicked to start the transfer. Progress bar showed nothing happening. I tried to cancel but that did nothing nor did pulling the drive out.
I rebooted, pulling power cords and waiting 45 seconds.
After reboot, things seem back to normal though I have not yet tried loading a key via FTP. The ingest ran but it just seemed slower than normal though that could be my imagination.
Hoping it was just an odd glitch put to rest with the reboot.
| IP: Logged
|
|
Leo Enticknap
Film God
Posts: 7474
From: Loma Linda, CA
Registered: Jul 2000
|
posted 08-06-2018 10:20 PM
I've occasionally had DSS and DSL servers go a bit buggerish when it comes to FTP, and, unless the cause was a LAN problem outside the server, a reboot has almost always fixed it. You can do this through the remote access PC using a SSH client (e.g. PuTTY). Log in using the administrator username and password (you can find these in the DSS manual), and then enter the command "reboot." Wait about 10 minutes, then reconnect via FTP, VNC, or whatever.
If you're uploading actual DCPs into it via the route described above, as well as KDMs, though, you should get a speed boost by putting an extra NIC in the remote access PC, with a crossover cable going from it directly into the theatre network jack of the DSS (assuming that the theatre network NIC on the server is unused, as it normally would be in a single screen setup). Call the extra NIC in the PC 192.168.241.X, where X is something other than 3, and you're good to go.
This will have the advantage that, when uploading, say, a 100GB feature from your remote access PC into the server, it won't be trying to send it through the same NIC as you're connecting to it from the internet through, and so both processes should gain a significant speed advantage.
| IP: Logged
|
|
|
Leo Enticknap
Film God
Posts: 7474
From: Loma Linda, CA
Registered: Jul 2000
|
posted 08-08-2018 04:28 PM
You're on version 4.3, which is pre-DCI. If you're using it with a cat862 and a Series 1 projector, I'd suggest checking that the projector will accept Cinelink I or Cinelink II TLS link encryption before updating the cat862 to a DCI-compliant firmware. You can't downgrade it back again if the projector can only use Cinelink II DH (the cat862, on post-4.3 firmware versions, cannot use DH).
As for FTP ingests, it certainly does some sort of verification, because if any of the files are corrupt, the content tab will show the CPL with a red X in the content type icon during the ingestion: if the red X doesn't go away shortly after the incoming FTP transfer is complete, either one or more of the DCP files has been found to be bad, or the server cannot play that DCP (for example, because you've ingested it into a DSS/DSP100, and the frame rate is not 24).
If you copy everything on the transport drive, that will work. Deluxe Technicolor have an annoying habit of putting everything in the root folder, even when multiple CPLs are present on the same drive. So unless you go through the individual files (which are often named by UUID rather than the CPL name) and just copy the ones you want, you will end up ingesting everything on the drive that way. But you can always delete the CPLs you don't want afterwards.
| IP: Logged
|
|
|
Leo Enticknap
Film God
Posts: 7474
From: Loma Linda, CA
Registered: Jul 2000
|
posted 08-08-2018 10:54 PM
If you have a Dolby DSS running version 4.9, or any flavor of Doremi server, the easiest way is to ingest from the Deluxe/Technicolor, drive and then outgest just the CPL you want to archive onto another external drive.
If you have a Dolby DSS running an earlier version than 4.9, you can outgest via FTP from the generatedPackages folder. Find the UUID of the DCP you want (right-click > properties in Show Manager), then FTP the folder named with that UUID string out of the server. If you outgest using the Show Manager GUI on a pre-4.9 version, it won't copy all the files, with the result that you will only be able to reingest it into another DSS server.
You may be able to outgest from other models of server and IMS, but I couldn't advise on this (at least, not without hitting the manuals first).
| IP: Logged
|
|
|
|
|
|
|
|
|
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 2 pages: 1 2
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|