Axcis Blog

Internally in the .NET framework strings are stored with 16 bit Unicode characters but when text is transferred to or from a file an encoding conversion takes place.  Files typically hold text as 16 bit Unicode (UTF16) or UTF8 which uses 8 bits for normal characters and an extended 16 bit code (or more) for extended characters.   Older files hold a simple 7 bit ASCII character set.  The framework provides encoding as standard for all these types.

Several times I have come across files and other device streams that use ASCII but utilise 8 bits with codes from 128 to 255.  The standard encoder for ASCII only handles characters from 0 to 127 and although the UTF8 format can deal with codes 160 and above, the range from 128 to 159 is not covered.  Googling for assistance here is not particularly useful with most comments stating that ASCII is only defined for 7 bit codes.  The solution I eventually discovered was that this 8 bit ASCII is probably ISO-8859-1 (or Western European ISO).  The character set is actually extended to the Windows-1252 standard.   An encoding can be performed using code page 28591, with a C# code snippet:

Encoding enc = Encoding.GetEncoding(28591);
StreamWriter sw = new StreamWriter(”Test.txt”, false, enc);

 With this you can handle characters such as ñ at code 241; I needed this for the spanish Español.

For some time I was getting problems with recording TV on VMC and I have now found a solution which I thought I would share.

The problem showed itself in a number of ways and got worse over time. Soon after starting VMC a message would popup saying a critical failure had occured in Media Center but it continued working OK. Sometimes recordings were split into several small chunks and would sometimes fail before the end. Sometimes a scheduled recording would not take place, although it would show as recording at the time (the red dot). When I tried deleting scheduled series from the list they would not delete. I even had a programme showing as recording even though it had finished recording the previous day and it still showed as recording after re-booting. Generally it seemed that the scheduled recording data was corrupted.

This can be fixed by closing VMC and renaming the file c:\ProgramData\Microsoft\eHome\Recordings\Recordings.xml (and also the Recordings.xml.bak).  Alternatively, just delete the files.  On restarting VMC, it will recreate these files but will obviously remove all scheduled recordings. The recordings will need to be manually added back into the schedule.

If you play a non-Microsoft format video from the VMC video library, the rewind and fast forward buttons don’t work.  I discovered a program called MediaControl that is supposed to fix this but I couldn’t get it to run so I thought I would add this feature to my MCIS Pro software.  It will be included in the next release shortly.

The reason that Microsoft format videos (WMV and DVR-MS) act differently is that they use the new Vista Media Foundation platform and other formats (AVI, MOV, etc) use the legacy DirectShow platform.

So to implement this feature I looked at the Media Center transport interface but this wouldn’t change the playback speed for these files.  Next I got hold of the DirectShow filter graph using the FFDShow filter and tried that.  It allowed setting playback speed up to 9x but in fact never went faster than 3x and reverse didn’t work.  It seems that DirectShow relies on the playback filter and these rarely include rewind capabilities due to the complexity with the compression format.  So that is why Microsoft do not implement this feature in VMC.  I also looked at the FFDShow API but that implements rewind and fast forward by jumping around.

So my current plan is to use DirectShow to set the first FF speed to 3x and then for faster speeds and for rewind will jump to a new position repeated every second.  Not an ideal solution but really the only way to achieve an adequate result.