Windows Media Player (wmp) not monitoring folders locally or over network (solution!)

One of the more prominent reasons I use Windows Media Player is for its seemingly unique monitor folders tool. After recently moving all of my media onto a centralized location on my network, I was hoping this feature would continue to work seamlessly, i.e. keep ‘monitoring folders’ for file updates, removals, or whatever. Long behold, after adding the network share to the associated ‘locations to monitor’ list, a wmp directory scan found all of the media files and iterated through each and every one of them without actually adding anything to the library. Weird.

After a few days of craziness, I finally ran into a solution at: http://weblogs.asp.net/chuckop/archive/2005/03/18/395139.aspx

Essentially the fix entails declaratively removing the “system” attribute from your media files since, apparently, wmp doesn’t like adding file/attribute pairs like that into its monitor routine (although you can add them to the library manually). In my case I’m not sure how the attribute ever got there to begin with (it definitely wasn’t there originally), but I suspect it had something to do with me transferring files through a device controller running linux/samba. 

I’m still on the fence as to whether or not this was a viable programming or business decision on wmp development’s part (I suppose one could contest to the fact that true ‘system’ files need not be monitored), but nevertheless there are loads of people having issues with this.

For more info on modifying the system attribute, visit: http://support.microsoft.com/kb/326549

asp.net: Handle comments in xml files

A small point, but asp.net’s XmlDocument doesn’t seamlessly handle xml comments when iterating through sub elements of an XmlNodeList. It’d be nice if XmlDocument didn’t read comments in the first place (I’d venture to say that xml comments aren’t meant to be read by compiled code), but I suppose it might be useful on some occasions to have the Load() method return everything in an xml doc. 

Not a big deal, but remember to handle comments explicitly any time an editable data file is consumed using the XmlDocument object.

For example, if expecting an xml document such as:

<?xml version="1.0" encoding="utf-8" ?>
<items>
  <item>
    <itemValue>value1</itemValue>
    <!--<itemValue>value2</itemValue>-->
    <itemValue>value3</itemValue>
  </item>
  <item>
    <!--<itemValue>value1</itemValue>-->
    <itemValue>value2</itemValue>
    <itemValue>value3</itemValue>
  </item>
</items>

The following approach (or similar) would need to be used in order to prevent the commented areas from being processed as bona fide elements:

    XmlDocument xmlDoc = new XmlDocument(); 
    xmlDoc.Load(HttpContext.Current.Server.MapPath(@"~\App_Data\file.xml"));

    XmlNodeList nodeRoot = xmlDoc.GetElementsByTagName("item");

    for (int i = 0; i < nodeRoot.Count; i++)
    {
      XmlNodeList objNodes = nodeRoot[i].ChildNodes;

      foreach (XmlNode node in objNodes)
      {
        if (node.NodeType == XmlNodeType.Comment)
          continue;

        // Do something.
      }      
    }

In this case, “objNodes” actually contains 3 elements for each item – 2 elements with NodeType Element and 1 element with NodeType Comment. If this is not handled properly in the iterations, it is possible for the code (or general routine) to fail supposing that an element is commented out with the intention for it to not be processed.

For more information: http://msdn.microsoft.com/en-us/library/system.xml.xmlreader.value.aspx