General
1. Try not to switch projects without exiting the application. This is a recent feature and our initial experience it is OK to do this occasionally but doing so frequently can cause problems. Exiting the application and restarting with a different project, always re-initializes all hardware and software subsystems correctly. This allows the application to carry out its own house keeping checking the frame-store, clips, libraries etc.
2. If your facility has unstable mains power supply we recommended you shut down the PC, or use a UPS. It is possible that power loss can corrupt the frame-store even if the application is exited to the desktop and the CPU is on.
3. With Linux based systems, not using the Autodesk supplied keyboard, mouse and tablet extenders can cause problems with tablet performance and/or graphics. Getting support for these problems will be difficult, if not impossible if you’re are not using the supported configuration. A flashing Nvidia screen is indicative of a tablet that has failed to be recognized.
4. The more projects you keep on the system at once, the longer VIC will take to check the system at boot up and when running the application. This is true even if you have removed the footage but keep the project. The application is trying to do its housekeeping and is looking for the clips, as the libraries are still active.
5. If working on very big complex projects which fill up the framestore it is best to archive and remake the framestore (sw_config) when the project is finished to get rid of any potential framestore errors. This is destructive and will remove footage and libraries. Once this is done the application needs to be run for the first time with ‘–v’ eg ‘smoke –v’. To remove ALL project, clip and desk information, start the application with –vir
6. Try not to leave Auto Connect enabled on networked framestores. It means you’ve always got a lock on somebody else’s framestore even though you may not be using it. Disconnect from remote framestores after wire transfers to prevent possible framestore locks. Vic will fail to run if a framestore is locked by another application.
7. If you use your local disk to archive to or drop files onto, take extra care not to fill it up. If the disk becomes full the system cannot write any clip data and your project will become corrupted. The only solution is to free up space and roll back older clip data.
Archive
1. Keep a copy of all the files in the /usr/discreet/archive directory. These will help you recover archives in the event of corrupted headers. They won’t give you all the information that was in the header, but will let you bring in all the material.
2. Don’t use huge tapes for small projects. This is because the header gets re-written every time the archive is appended to. If you have a large number of jobs and the headers get corrupted then the entire tape will not work. This is the case for video or data archives.
3. Archive regularly. Don’t wait for the stone to fill up before finding out there’s an archiving issue that needs resolving. If there’s a problem with a project and/or clips, resolve it ASAP – don’t let it fester on the system potentially getting worse.
4. By all means archive to an external disk or array but a hard copy of that ought to exist somewhere safe because that disk can get corrupted. E.g. by someone accidentally pulling the power on it – a big problem with external firewire/USB drives.
5. Archiving is not 100% completely reliable so having a plan B or several copies of data wouldn’t be a bad thing. Always back up the OTOC files as a last resort for recovering from corrupted headers.
6. If archiving as a data file – set the file size to be small e.g. use the default 1024MB (1GB) file size. The software will then archive across multiple files. You can then save these files individually onto the storage medium of your choice (e.g. DVD). You’ll have to format the second file as it’s needed but there’s an option box to enable to making all the file segments the same from then on.
7. Archiving and back-ups need to be checked that they have worked. I.e. it is worth checking that your archiving strategy is working BEFORE you need to use it in anger!
8. In our experience it is always better to split a huge project into manageable chunks and archive those separately than have a single enormous archive that requires equally enormous system resource overheads. With file archiving, the [default] segment size of 1024MB (1GB) will get around pretty much all filesystem limitations on all media.
9. Unfinished burn render jobs in the library may stop the project from archiving. Delete any clips ‘pending render’ and do an sw_purge before archiving. This appears to clear up the project.
Stone and wire
Don’t fill the stone up completely. The applications need spare room to create and store archive data. If there’s no room for that then you have a full framestore that can’t be archived. Stone disk arrays are guaranteed to playback in real time. Standardfs introduced in v2008 can use any disk space for media storage but real time playback will be at the mercy of the hardware and performance issues will not be supported by Autodesk or XTFX.
1. If the stone fails to mount it is often due to an intermittent connection between PC and array. Stone filesystem can only mark disks as dead if it can see some others to write to. These hold the real config of the array. Use sw_config on your working framestore to discover how many disks are normally there and make a note of their adaptor numbers. Call XTFX if the number of disks has changed.
2. The volume integrity check (VIC) MUST run regularly. This point is of MAJOR importance to the performance and integrity of your data. If it doesn’t run then the reason should be found and rectified. The recommended way to check if VIC has run is to view the vic log. This is ‘/usr/discreet/sw/vic.stonefs.log’
3. VIC tries to run every time the machine reboots. On systems with large numbers of projects this may take some time. Nothing can be done about this save for extensive housekeeping. Never ignore vic warnings when the application starts. Find out the cause and rectify it before potential corruption occurs.
4. Do NOT use Auto Connect (A/C) to connect to remote stones if you have 3 or so more systems. Vic can’t run if another system has automatically locked onto the framestore. The more systems involved the worse this gets. Connect only while you need to.
5. Xstoner and other wiretap 3rd party products can lock the framestore and prevent VIC from gaining exclusive access, so if you use xstoner on your flame/smoke then turn it off regularly (using ‘service xstoner stop’) and run VIC manually.
6. To fix black frame corruption use cmtool – it is best to get an engineer to do this.
1. In a shell, go to /usr/discreet/io/bin
2. cmtool
3. open volume <which volume you are using, usually it's stonefs>
4. ls
---> a list of partitions and projects is printed. Locate the resolution of the clip you have problem with
5. open partition <AFFECTED_PARTITION_NAME>
6. regen rsvd 7
7. quit
7. Framestore purging:
Problem:
After deleting the library in the application, exiting and then restarting, the LOST+ FOUND still remains with the same content - it seems to be impossible to get rid it.
Even deleting it from the shell, doing a sw_purge and restarting the application stills shows that the LOST+ FOUND is back with the same content.
Solution:
First, make sure that the VIC can run without errors.
If VIC runs with errors – and you’re an advanced user refer to the ‘stone and wire guide’ If not contact XTFX for resolution of errors. Once finished, try to purge the undo buffer
To summarize, the steps to follow should be:
o Start the software
o Delete the Lost+ Found
o Purge the undo buffer (button available from the Preferences menu)
o Exit the software
o Do an 'sw_purge'
o Run: /usr/discreet/io/bin/vic -v stonefs (make sure there is no lock)
Now restart the software.
8. Proxy regeneration after corrupt frames have been fixed:
The easy way is to delete the proxies and re-create them.
To do this go to project management and change the project so there are no proxies.
Confirm deletion, and once complete, then go back to project management and reset the project so it now has proxies, the software will then re-generate the proxies in foreground.
Hangs and crashes
1. If the software dies unexpectedly this is because the operating system killed the application in order to prevent the operating system from crashing. Because the software was killed by the operating system the application was unable to spend time writing logs as to why the exit to desktop happened. If the software dies regularly while performing an action, make a detailed note of what you were doing and create a debug log so that we can escalate it with Autodesk. XTFX cannot escalate any problems to Autodesk if an operator just says it’s ‘unstable’. Repeatable steps that lead to the exit to the desktop will help XTFX and Autodesk to resolve the issue and provide a fix.
2. To generate a debug log, open a shell as the normal user and type
bin/DEBUG_INFO
Answer the questions that come up then email the debug.log file to us.
3. If large projects complain about not enough memory, try changing the MemoryApplication keyword in the init.conf file.
# MEMORY KEYWORD
# --------------
# The memory keywords enable additional buffers to be used by certain modules
# such as Play and Action or DVE. The amount of memory that can be enabled
# depends on the amount of installed system memory. The MemoryApplication
# keyword specifies how much memory we want to allocate for frame buffers
# in the application.
#
# When commented out, the application will automatically compute a default
# amount of memory depending on the physical memory installed on the system.
#
# Syntax: MemoryApplication <MegaBytes>
#
#MemoryApplication 700
Look to see if the MemoryApplication line has been uncommented. The default is 700 on current flints and if you’re having issues, try incrementing it 100 at a time until they’re resolved. When commented out the program tries to manage memory itself but doesn't always configure it properly on big projects.
4. The MaxLibrarySize keyword in init.cfg determines how much memory is put aside for library storage. If more is needed then it’ll get allocated but it’s better to have the correct amount allocated from the start. If you use a large single library with a lot of clips in it, it’d be worth extending the figure to 80 or so.
# MAXLIBRARYSIZE KEYWORD
# ----------------------
# The MaxLibrarySize token is a hint to the system about the maximum
# size any one of the libraries will have (megabytes). This helps
# managing the library memory efficiently. A higher value will increase
# memory used by the application but reduce memory fragmentation thus
# increasing memory utilization. As a rule of thumb, you can make this
# token at least the size of the largest library you plan on using plus
# some room for adding more clips to it. The size of your libraries
# can be obtained with this command in the unix shell:
# ls -l /usr/discreet/clip/*/*/*.000.clib
# The default size is 30 megabytes.
#
# Syntax: MaxLibrarySize <size>
#
MaxLibrarySize 30
5. Smoke and Flame save their desktop every few minutes as a backup. If the application crashes every so often, this could be the cause. The hard disk may be full or there could be corrupted data on the desktop. Try making a new project with a new user and see if the problem goes away.
6. Every time you start smoke or flame a backup is made of the clips from the last time it was run. If the project crashes we can try to restore those backups. Bear in mind that if the application is restarted too many times, then you just end up with a backup copy of a corrupted project, so it would be impossible to recover.
General gotchas
Clip History
Since the introduction of clip history the amount of clip metadata has increased considerably. Bear in mind that the system is keeping all clip changes. As such the maximum library size keyword may need to be set higher (as above). You’ll also find that the amount of clip use on the stone will increase hugely and archives become much bigger. If you’re not going to roll back over hundreds of changes then trim the clip history before archiving. See the manual entry below:
Illegal video
The systems do not legalise video output. Basically the only way to check output is to buy a scope and fit it to the output. There is no software legaliser available to check what has physically been output, bar scoping the output. The products work in RGB colourspace hence it is entirely possible to generate out of range (illegal) colours when converted to YCrCb for output. There is a spark you can use to process your clip through and this will legalize the colours.
In the spark browser, navigate to /usr/discreet/[current software version]/sparks/
Inside this directory you will find a few sparks that come bundled with the system.
The one you need to load is sparkBroadcast and when applied to the clip, you should be able to choose options to legalize the clip. |
