zwiller situation was a little unique I think. We know the vixen files are xml based. The idea I had was to ensure the xml was well-formed, meaning opening tags had closing tags, etc. You can do this via apps like XML Spy or even IE/Firefox.
Sams file was missing a few tags. The end of EventValues (the actual on/off/intensity values). I added that in there and an additional tag. It looked like that maybe either during the file save/copy that part of the file got lost (assumption).
But adding the tags wasn't the only problem here. Since the EventValues are in a Base64 encoded format, there are sometimes special characters at the end of the string to represent the "boundries". Typically that is either 1 or 2 equal signs "=".
So the process I followed...
1. Open the file up in an app that recognizes xml to verify well-formness (every start tag has an end tag).
2. Compared the file to an existing file to ensure all tags were present. In this case, in addition to the missing EventValues tag, there was another tag immediately following that was also missing. So at the point where the data may have been corrupted, verify no additional tags were removed.
3. Once, it is a proper xml file again, open in vixen. In this case Vixen complained about an "Invalid length for a Base64 char array". There is where I guessed and added an "=" to the end of the base64 event values data. This was only a guess because there could have been a lot of data missing. I just assumed the data wasn't affect. Sometimes you might have to put "==", it really depends on the size of the data you are writing out to disk. If that doesn't work, then you have to take it into a program that will convert the base64 into binary and find out where the data stops. This can be a little tricky.
I really think this was a unique situation. But in case someone else experiences the same type of problem... maybe these tips will help.
