Exporting SRT file from an existing MP4 file

 I was wrestling with Handbrake to convert multiple large MP4 files into smaller, lower-resolution versions -- I would put the files to be processed into its queue, then specify that I wanted it to include the subtitle track as an option for the output file.

The method indicated in the documentation for Handbrake works so long as I'm doing it for one file at a time, but once I load up a queue and run multiple jobs the subtitle settings just don't seem to work -- the files video components are converted perfectly, but the subtitles don't come across in the new, smaller version of the file.

I gave it an hour trying every combination I could think of and had to give up and try something else.

The easier solution in my case was to process the video files using Handbrake but then to independently generate a SRT for each video file which the user (who'd be using VLC as their player) could load on their own if they wanted to view subtitles.

The answer lay with FFMPEG (again) -- this command would read the (single) subtitle track from my video file and then write it out to a "SRT" file:

ffmpeg -i myvideofile.mp4 -map 0:s:0 myvideofile.srt

I could see that this will get more complicated if the video file had multiple subtitle tracks (for different languages).  In that case you can try and wade through the full index of the video file looking for the correct track by using:

ffmpeg -i myvideofile.mp4

Or, if you're lazy like me, start the video file up in VLC and look for the listing of subtitle options.  You can then guess the correct track to use:

ffmpeg -i m.m4v -map 0:s:0 eng.srt
ffmpeg -i m.m4v -map 0:s:1 ita.srt
ffmpeg -i m.m4v -map 0:s:2 fre.srt

"Can't connect to FTP: (553) File name not allowed" error

I had a need to develop a small C# app to dynamically configure static webpages from a database (simple tables of phone numbers) and then push them to a webserver using FTP.

Using the new .NET 4.5 FTP tools in "System.Net" I coded the app (example in https://msdn.microsoft.com/en-us/library/ms229715%28v=vs.110%29.aspx) and I immediately ran into a problem pushing a file to a directory on the webserver where I knew I had rights. 

The error message was "Can't connect to FTP: (553) File name not allowed" on the line which creates the file on the remote server:           

FtpWebRequest request = (FtpWebRequest)WebRequest.Create(@"ftp://servername.albany.edu/www/prod/biology/phone_numbers/test1.html");

My mistake was forgetting that my target was a UNIX server and not a Microsoft IIS server -- after a UNIX servername you need a double-slash to indicate the server's root directory -- in my case, I needed to change it to:

FtpWebRequest request = (FtpWebRequest)WebRequest.Create(@"ftp://servername.albany.edu//www/prod/biology/phone_numbers/test1.html");

Sorting a C# Dictionary Collection

When working with Active Directory searches I often stream matches into a C# Dictionary object (e.g., using "samaccountname" as the key and ", ()" as the value).   Since it's searching a linked list the data comes in fast but unsorted.

Unfortunately the Dictionary object doesn't support a native sort() function, but it's easy to do using a LINQ function:

/// 
/// Sort Dictionary structure 
/// 

public static Dictionary SortDictionaryByValue(Dictionary data)
{
        List li = new List>(data);
        li.Sort((x, y) => x.Value.CompareTo(y.Value));
        return li.ToDictionary(p => p.Key, p => p.Value);
}

Thanks to mindfiresolutions for this function.

Dumping the org-unit structure of an Active Directory namespace

The utility required is "LDIFDE" and the syntax and explanation can be found at:

http://support.microsoft.com/kb/237677

The upshot is the statement:

ldifde -f exportOu.ldf -s Server1 -d "dc=Export,dc=com" -p subtree -r "(objectCategory=organizationalUnit)" -l "cn,objectclass,ou" 

Where 1) "exportOU.ldf" is the file you're outputting to; 2) "Server1" is a dc in the domain; 3) "dc=Export,dc=com" is the root of the area in the namespace you want to dump; 4) "subtree" is your search scope; 5) "(object...Unit)" is the search term; and 6) "cn ...ou" is the list of attributes in the search.

When you get it, you turn it around and import it with:

ldifde -i -f exportOu.ldf -s Server2


Where 1) "exportOu.ldf" is the file you output earlier; and 2) "Server" is a DC in the domain where you want to build the OU structure.

Way easier than writing it oneself.

How to determine which NT groups I am in

So useful for debugging security problems but so forgettable ...

The easy one:

whoami /groups

The really detailed one:

gpresult /V

Visual Studio error: "Unable to delete folder . This function is not supported on this system."

This is a problem I've had when using VS2010 and am trying to get rid of service references so I can re-add them. 

It seems like a rights issue:  The answer is to go to the folder in question using Explorer and delete it manually, then go back into VS2010 and delete it.

WCF error: "Custom tool warning: Cannot import wsdl.portType"

An error that comes up when moving code which calls a WCF service from development to production:

"Custom tool warning:  Cannot import wsdl:portType"

It also details a number of "custom tool" errors.

The problem stems from when I pull some Visual Studio Solution code over from my development lab, delete the service references in the projects in the solution (which point to the WCF service in the devlab) and re-add them as service references pointing to the WCF service in the production lab.

Evidently a lot is going on during the creation of these service references -- when Googling for information on it other users recommend completely shutting down and restarting Visual Studio; the best recommendation comes from stackoverflow and recommends re-adding these references while specifying not to reuse types in reference assemblies:

http://stackoverflow.com/questions/1872865/what-does-this-wcf-error-mean-custom-tool-warning-cannot-import-wsdlporttype

http://www.lukepuplett.com/2010/07/note-to-self-don-let-wcf-svcutil-reuse.html

"The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element."

This happened when I was sending large chunks of data through a WCF service -- by default it seems that the service is configured not accept anything over a certain size, probably as a security measure.

Overriding it is done by adding a "readerQuotas" section:

<bindings>
  <basicHttpBinding>
    <binding maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
</binding>
  </basicHttpBinding>
</bindings>

Drawn from this blog:

http://www.megustaulises.com/2012/04/wcf-common-error-messages-tips-and.html?_escaped_fragment_="

A word of caution, though -- in most examples I found in Google there was an admonition to add a "name" attribute to the "binding" element (e.g., http://stackoverflow.com/questions/3068076/wcf-service-the-maximum-array-length-quota-16384-has-been-exceeded) and if you use the "Edit WCF Configuration" utility in Visual Studio 2010 it'll actually say there's an error when it senses that the "name" attribute is missing.

This has confused more people than just me -- see https://go4answers.webhost4life.com/Example/maximum-array-length-quota-16384-36456.aspx, especially "Answer 6".  It seems that if the "name" attribute is left out then the change is made to the global binding definition if the WCF project is .NET 4.0+.

The confusion would seem to come from an improvement in the structure of WCF config files introduced in .NET 4.0/4.5 as a "simplification" feature, documented in http://msdn.microsoft.com/en-us/library/hh309266.aspx

WCF Error: "This collection already contains an address with scheme http"

This comes when pushing a new WCF service up from development to production -- it'll work fine in dev, then fail with this message in production:

"This collection already contains an address with scheme http"

The solution is to update the web.config section of the IIS hosted WCF service and the app.config section of the library used by WCF and is described in a couple different links:

http://social.msdn.microsoft.com/Forums/en/adodotnetdataservices/thread/e028cea6-5b40-4a43-b395-d966bc93ffd5

http://stackoverflow.com/questions/561823/wcf-error-this-collection-already-contains-an-address-with-scheme-http#561975

In my case, I put this code right after the <servicemodel> tag:

<servicemodel>
  <serviceHostingEnvironment>
    <baseAddressPrefixFilters>
        <add prefix=http://mignysm95bakpv.nysemail.nyenet"/>
    <baseAddressPrefixFilters>
  </serviceHostingEnvironment>
....
etc. etc. etc. ....
</servicemodel>

I wish I knew WCF well enough to say what the fix is actually doing but at present I can't quite say what's going on -- I'm still learning it and, once I find out what my problem is, I'll add to this post.  In the meantime, I've just got to get this running.

"Could not find endpoint element with name ..." WCF error

I developed a windows service which periodically polls a WCF server for information -- I added a service reference to the project which provided a proxy for a "ProvisioningClient" object.  The could would instantiate this object and then perform tasks:

using (ProvisioningClient client = new ProvisioningClient("basic")
{
   // Do stuff
}

The way I create windows services is to first create a DLL that performs all of the work and then load and call it from a C# windows project.

For debugging, though, I put together a simple Windows form test harness (just a single form in a project called "Service Impersonator") with a single "Start DLL" button which loads the DLL and lets me interactively debug the DLL code.

The program would consistently fail on the "using" statement above, though, with a message:

Could not find endpoint element with the name 'basic' and contract 'ExchangeProvisioningServiceReference.IExchangeProvisioning' in the ServiceModel client configuration section...

I'd check the APP.CONFIG file in the DLL and there was indeed an endpoint element called 'basic' following that very contract; reviewing the WEB.CONFIG file of the WCF service showed that the syntax matched perfectly.

Since the code failed in the DLL and the error pointed to the APP.CONFIG file, that's where I kept looking and puzzling.  The problem was not there but in the Winform test harness project:  it was a very simple project which just called the DLL but for some reason the DLL looked for an APP.CONFIG file in the .EXE file calling it and, not finding one, gave me that message.

Adding a service reference to the Winform test harness project that called the DLL resolved the problem.  I don't understand why the DLL doesn't look at its own APP.CONFIG file but that's the way it is.

Oddity when working with event logs

During development I often create then delete custom Windows event logs for my applications.

A problem arises when I do something like delete and then recreate an event log and event source in order to correct a spelling or something like that ... I'm able to delete the old log and the source but when I recreate the new (correctly spelled) log and source I will see the new log appears but I can't seem to write to it anymore.

There's a peculiarity with Windows event logs -- if you delete them and then recreate them, you need to reboot the computer for writing to the event log to begin behaving correctly again.  See:

http://stackoverflow.com/questions/1901312/eventlog-createeventsource-is-not-creating-a-custom-log

and

http://msdn.microsoft.com/en-us/library/2awhba7a.aspx (about half way down the page)

Exchange 2007 Admin in C# on W2008R2 using Visual Studio 2010

I wrote a service which performed Exchange 2007 administration tasks which performed successfully for years running on a Windows 2003 R2 server.  Recently we went through an upgrade to W2008R2 and Exchange 2010 and I began upgrading the service to use the new and very different PowerShell snap-in for Exchange 2010.

Suddenly we partially reversed course, however, and decided to stay with Exchange 2007 while continuing the upgrade to W2008R2 for the server OS.

So I am having to rewrite my original windows service code to run on 64-bit W2008R2 machines.  I remembered that when I initially wrote the service I had several issues getting Visual Studio (then VS2005, now VS2010), the PowerShell runspace, the Exchange 2007 Administration PSSnapin, and the bit-iness of the machine to agree and to let me do what I needed to do.  I remembered that these problems took days to resolve.

I would run into persistent problems getting my C# code to recognize the snap-in, to use the correct version of the System.Management.Automation tools, etc. which would be evidenced with errors like:

"No snap-ins have been registered for Windows PowerShell version 2"

"Could not load file or assembly 'Microsoft.Exchange.PowerShell.Configuration, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified."

"MSCorlib.dll is compiled for wrong processor"

Googling around it is clear that this is a common problem and is a bit-iness issue between all the different entities and all of them must be lined up in the right way to make things work.

I established a set of steps that worked for me in a virgin test environment on a virtual machine; I then took it into my production environment (which had suffered installs and uninstalls of the Exchange 2007 and 2010 management tools) and tried it again and it worked.

The steps I followed to get it to work were:

01) Install the Exchange 2007 management tools from the Exchange 2007 SP1 distribution DVD onto the server
02) Update the management tools to service pack 3 (by downloading the Exchange 2007 SP3 download from Microsoft)
03) Start Visual Studio 2010 and create a console application. 
04) Create a class in the console app to hold the Exchange 2007 Admin PowerShell wrapper written by Nick Smith (at http://knicksmith.blogspot.com/2007/03/managing-exchange-2007-recipients-with.html)
05) Have the main() method of the program.cs file call Nick Smith's exchange wrapper, e.g.:

  static void main(string[] args)
  {

    // Do a simple dump of mailbox names
    ExchangeManagementShellWrapper ems = ExchangeManagementShellWrapper.Instance;
        ICollection results;
        results = ems.Runsp
aceInvoke("Get-Mailbox");
        foreach (PSObject item in results)
        {
              Console.WriteLine(item.Members["Name"].Value.ToString());
        } 
  }

06)  Make sure the project's set to build using .NET framework 3.5.
07)  Make sure the project's set to build to the x64 platform
08)  Make sure there's a reference to "C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Management.dll"
09)  Make sure there's a reference to "C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll"

That should do it.  The Exchange 2007 PowerShell cmdlets are only installed as x64 and the System Automation dlls only seemed to work for me if the code is targeted towards .NET 3.5, not .NET 4.0 (which my VS editor defaulted to).

I'll include the source code for the project if there's any interest in that.

MS Active Directory "accountExpires" value -- getting and setting it

If you use ADSI to get a DirectoryEntry object from Active Directory you'll find that the "accountExpires" property is stored as a DateTime variable in a large integer format called the IADsLargeInteger format (http://msdn.microsoft.com/en-us/library/windows/desktop/aa706037%28v=vs.85%29.aspx).  The format represents a date as an 8 byte variable indicating the number of 100-nanosecond intervals since January 1, 1601 (look up the Wikipedia article for this date if you're curious as to why it's used).

Converting this format into a standard C# DateTime value requires a 2-step process of converting the IADsLargeInteger into a standard C# long value, then converting this long value into a C# date time.

I found several (incorrect) versions of functions to accomplish this on the Internet but the best functioning version (derived from MSDN's articles on accountExpires, IADsLargeInteger, and DateTime conversions) comes from Tobi's 'tips' 4 and 5 in his notes on Active Directory (http://www.fsmpi.uni-bayreuth.de/~dun3/archives/category/it/programming/active-directory):

First, convert the IADsLargeInteger into a long:

private static long ConvertLargeIntegerToLong(object largeInteger)
{
Type type = largeInteger.GetType();
int highPart = (int)type.InvokeMember("HighPart", BindingFlags.GetProperty, null, largeInteger, null);
int lowPart = (int)type.InvokeMember("LowPart", BindingFlags.GetProperty | BindingFlags.Public, null, largeInteger, null);

return (long)highPart <<32 lowpart="lowpart" p="p" uint="uint">}

Then use this to convert the long into a DateTime.  Note that the DateTime is stored in UTC format -- luckily .NET has the "FromFileTimeUTC()" method ready-made to handle this for us:

object accountExpires = DirectoryEntryHelper.GetAdObjectProperty(directoryEntry, "accountExpires");
var asLong = ConvertLargeIntegerToLong(accountExpires);
    
if (asLong == long.MaxValue || asLong <= 0 || 
DateTime.MaxValue.ToFileTime() <= asLong)
{
return DateTime.MaxValue;
}
else
{
return DateTime.FromFileTimeUtc(asLong);
}
   
Note 1:  "Magic values" in the accountExpires attribute

Two values in the accountExpires attribute indicate that the account is set to "Never Expires."  These are zero (0) and  9223372036854775807 (0x7FFFFFFFFFFFFFFF).
  
See http://msdn.microsoft.com/en-us/library/windows/desktop/ms675098%28v=vs.85%29.aspx

Note 2:  Getting the accountExpires attribute from an ADSI "DirectorySearcher" search result

This is very important (and delayed me quite a while when I didn't take it into account).

If you pull an account's DirectoryEntry using ADSI the 'accountExpires' property is returned as an IADsLargeInteger, but if you get it as a search result using "DirectorySearcher" the property will be presented as a standard long.  No translation from IADsLongInteger are required, you'll just need to do the translation from long to DateTime ("step 2" above).

See http://forums.asp.net/t/999913.aspx and comments by MVP "Dunry" for a useful discussion of this.

How to lock an Active Directory account with C#

There are a lot of answers out there to how to lock an account using ADSI -- some just wrong, others dangerously wrong.

This one works cleanly, transparently, and well:

private void LockAccount()
{
string _userAccountWithoutDomain = “test”;
string _domainName = “IND”;
string _userBadPassword = “yyyyy”; // password should be incorrect
int _passwordExpiryPolicy = 3;
string _connectionPrefix = “LDAP://” + _domainName;

for (int i = 0; i < _passwordExpiryPolicy; i++)
{
try {
new DirectoryEntry(_connectionPrefix, _userAccountWithoutDomain, _userBadPassword).RefreshCache(); }
catch (Exception)
{ }
}
}

Thanks to Sanjiv at http://sanjivblog.wordpress.com/2011/05/13/how-to-lock-the-ad-active-directory-account-programmatically-in-c/

Error message "Element 'link' cannot be nested within element "

I keep getting this wrong -- when the error message indicated in the title appears it's because I've stuck the link directive (used for bringing CSS files into an HTML document) in the wrong place.

Short answer:  The "link" directive can only be used inside the "head" tag of an HTML document.

jQuery error: "$ is undefined"

When using Visual Studio 2010 and coding in ASP.NET where I'm using one of the various jQuery plug-ins (a datepicker, the BlockUI page blocker utility, or the jQuery validation tools) I'll occasionally get the JavaScript error featured in the title -- it simply means that the page fired up and it couldn't resolve the "$" synonym for "jQuery."

Invariably I'll check and make sure that I've got the jQuery code "included" in the web page (which I do) but if I look at the page using Firefox "Firebug" I'll see that something will have hosed up the syntax of the include statement (based on the browser, whether I'm using master pages, nested master pages, etc.).

Being lazy I like to include files by dragging them from the "Solution Explorer" pane of Visual Studio right into the ASP.NET/HTML code.  I always hope that VS2010 will just "figure out" the right syntax for me, and so long as I'm not using master- or nested-master pages I'm generally right.

Once masterpages are introduced, though, things get screwed up.

Here's a syntax solution I've found that seems to work pretty well:

Rather than:

<script src='~/scripts/jquery-1.8.2.js' type="text/javascript"></script>

I use:

<script src='<%= ResolveUrl("~/scripts/jquery-1.8.2.js") %>' type="text/javascript"></script>

It seems to circumvent the path-naming-weirdness introduced by ASP.NET-masterpage-wrapping.

My persistent 500.24 error

Because of my client's NT trust relationships my websites need to use NT credentials impersonation quite frequently and I keep falling into the same trap when setting up impersonation in IIS7 (rather than IIS6, which I was kind-of used to).

I build and push out the website and then try to access a diagnostic page (which shows the current website's users credentials as understood by the web server) and get the error:

"HTTP Error 500.24 - Internal Server Error An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode"

A couple things will float up in my mind right then -- I know that in IIS6 and older versions of IIS I always put "impersonate=true" into the web.config file and this causes problems with the new pipeline mode of IIS7.  I'll knock this line out of the web.config file and it won't help -- the 500.24 error will disappear but impersonation is gone.

Then something will happen to throw me into a blind panic (usually a required demo in ten minutes or some other "show and tell" nonsense that means I've got to get this resolved fast) and I'll start flailing around trying to fix it.  I always do, but I want much less stress in my life -- so here are the basic steps again as a reminder so the experience can be shorter next time:

- Go into IIS7 manager and reset the website's application pool to use the "Classic" pipeline
- Modify the web.config file to include:

<system.webServer>

   <validation validateIntegratedModeConfiguration="false"/>

</system.webServer>

 

 See these links for more (and better) information:

http://allen-conway-dotnet.blogspot.com/2010/11/how-to-use-impersonation-in-aspnet.html

 

http://mvolo.com/breaking-changes-for-aspnet-20-applications-running-in-integrated-mode-on-iis-70 

(The latter has a nice section that explains this error very well.)

My persistent website 401 error

This is a reminder to myself.

I work in an NT environment with multiple domains (e.g. domainA, domainB, and domainC) where one domain ("domainC") trusts the other two domains.

I keep my IIS7 website in domainC and want users in any of the domains to be able to access it using their domain's credentials.

I make sure to disable anonymous access on my website and enable integrated windows authentication so that users will come into the website using their current credentials.  

The roadblock I experience each time is that I'll set up the website and test it using an account in domainC and all will be well.  During final testing I go over to domainB or domainA, log in, and try to get into the website and run into a "401" error. 

I always do this:  I'll go back to the website and try and reset permissions to the website's directory to allow "domainA\Everyone" and "domainB\Everyone" to have access, but for some reason I won't be able to.   I'll remark again that this works in my personal devlab but not in the client's environment.  I'll remember hearing that there's some sort of firewall blockage on LDAP calls between domains in this environment.

I'll try to create a domain local group in domainC and add the domainA\Everyone and domainB\Everyone groups into a local group I can give website rights to, but that won't work either.

I'll get frustrated here and start Googling and 4-5 hours will disappear as I learn how little I really know about security (and pursue several blind-alley solutions proposed by some other clueless bloggers).

I'll then spend another hour dicking around with every setting conceivable on my website, and then create a small sample "WhoAmI" website that just returns the current user's credentials.  Setting security on this test website, I'll turn off anonymous access, turn on nt authentication, and then give the local group WEBSERVERNAME\Users all rights to the website and discover that I can now access it from all the trusted domains.

The lesson here is to start by giving the WEBSERVERNAME\Users local group basic rights to the website just to get started.

This has cost me several hours to recreate twice -- Note to self:  don't do this again.

Searching a list<string> with case insensitivity

A lot of my web methods generate a list of strings from different sources that I want to quickly scan using the ".contains()" method.

Unfortunately the default method is case sensitive and, since I get information from different sources with differing casing-methods, my code will miss matches with slightly different casing.

string findMe = "String2Find"; 

List someStrings = new List{"one", "Two", "string2FIND", "Three"}; 

Console.WriteLine someStrings.contains(findMe);

 ==== Console === 

(false)

 ================ 

The bad solution is to go thru the list using .tolower() to lowercase all the members and compare each one against the comparator -- with the advent of LINQ there's a new overload for the method which allows comparisons without regard to case: 

string findMe = "String2Find"; 

List someStrings = new List{"one", "Two", "string2FIND", "Three"}; 

Console.WriteLine someStrings.contains(findMe, StringComparer.OrdinalIgnoreCase); 

==== Console === 

(true) 

================ 

I couldn't find this in the standard MSDN locations but it popped out at https://nickstips.wordpress.com/2010/08/24/c-ignore-case-on-list-contains-method/#comment-801

Learning WCF - Port contention issues during debugging

When working through exercises from the MSPress book on WCF for .NET 3.5 and from Bustamente's "Learning WCF" I ran into an issue when "self-hosting" WCF services in a console application.

One self-hosting example featured a solution with two projects:  1) a WCF service ("library") project and 2) a console app used to host the WCF service in the library project.   Each had an "app.config" file in it indicating that it wanted to use port 8080 under the local host URL:

... snip ...  <host> <baseAddresses> <add baseAddress="http://localhost:8080/NetStarCommandService" /> </baseAddresses> </host> ... snip ...

The solution built fine but when trying to run it presented this error message:

"HTTP could not register URL http://+:8080/NetStarCommandService/.  Another application has already registered this URL with HTTP.SYS"

If I changed the port number in either of the app.config files the code would run fine.

The problem turns out to be with a Visual Studio 2010 feature I was unaware of.  When you start a solution which has a WCF service in it Visual Studio will quietly start the WCF hosting service for the WCF service before running the code in the solution -- this causes the library project and the WCF hosting service to grab the port first and then prevent the self-hosting console code from running on that port.

The solution is very simple:  Right-click the WCF service project (the "library" project) in the solution, bring up its properties, and take a look at the "WCF Options" tab on the properties screen.  Uncheck the "Start WCF host when debugging another project in the same solution" checkbox and the project should run correctly.