Fix: Transform Manager ignoring media files added to watch folders

I’ve been puzzled for some days now with the IIS Transform Manager installation we have at ClipFlair for automating the conversion of media files (for example using Microsoft Expression Encoder) into IIS Smooth Streams.

The watch folder I’ve set up for this task was ignoring some of the media files I was dropping in for no apparent reason (e.g. it was picking up some .MP4 files but not other .MP4 ones).

Eventually I realized that the files it wasn’t picking up didn’t have at their Properties/Security tab access rights for the user account that has been assigned to the Transform Manager service, while the processed files (it keeps them at the “WorkQueue/Finished” subfolder” under the watch folder for the respective job [e.g. “Smooth (VC1)”]) had full access rights for that account.

Obviously by dropping them in the watch folder that had those rights assigned they also got the same rights, but not all the filed did. Maybe it is some Windows Server 2008 R2 bug when dropping multiple files together into a folder, not sure though. Adding the needed rights to each of those files, Transform Manager watch folder task immediately pulled them for processing (and soon put them into the “WorkQueue/Running”)

Another thing I noted was that at the Watch Folder task’s (say the “Video files to VC-1 Smooth Streams” ) “Scheduler” tab, at “Concurrent Jobs”, the default setting was set to 1. If you control how many files are placed in the watch folder (e.g. users aren’t uploading files there themselves) you can even check the value “Unlimited” there to process all the dropped files in parallel.

HowTo: Use DotNetZip (Ionic.Zip) library in Silverlight

If you want to use the latest DotNetZip library (version 1.9.1.8) with Silverlight, you should get a patched version from http://dotnetzip.codeplex.com/workitem/14049, instead of the official download for Silverlight.

It seems the Silverlight build in 1.9.1.8 official download doesn’t work correctly, since it tries to get IBM437 Encoding (as the original ZIP spec required) from Silverlight, but that encoding is not available via Encoding.GetEncoding method in Silverlight (neither encoder and decoder fallbacks for GetEncoding are available as in .NET 4.5).

So the patched version uses Unicode encoding instead (only UTF-8 and Unicode [UTF-16] Encodings are available in Silverlight), although it could have also used a text encoding class generator for the missing encoding and change the source code similar to how Mike Taulty had done with an older version of DotNetZip.

I do prefer the Unicode approach, since using the IBM437 codepage would have issues with Unicode filenames. ZIPs with such filenames are supported fine by most modern ZIP viewers, including Windows Explorer’s Compressed Folders views in recent versions of Windows.