It sounds like you were able to solve your real problem at the root, by changing how EPG Collector saves the guide data, but for reference sake, I too have had this problem using the Toub.MediaCenter.Dvrms.dll corrupting metadata.
After some extensive research and reverse engineering of the WTV file format, I've been able to correct every single metadata corruption in my WTV files, without losing any metadata. I'll describe how, but it requires using a hex editor, so it may not be for the faint of heart. I prefer HxD, but there's plenty out there to choose from. I've also attached a quick and ugly program I've made to help pinpoint where the errors are to make it easier to update them.
Before you begin, you'll have to understand a bit about how WTV files are formed. Every WTV file is grouped into "Sectors". There are two types of Sectors, Header Sectors, and Data Sectors. Header Sectors are 0x1000 bytes each, and Data Sectors are 0x40000 each.
There are 4 areas we care about, for metadata: the Root Sector, the Table_Redirector.LegacyAttrib, Table_LegacyAttrib, and LegacyAttrib.
- Root Sector tells where all the lookup tables are located;
- Table_Redirector.LegacyAttrib shows the offset to each individual Metadata Entries starting point;
- Table_LegacyAttrib shows which sectors are allocated to Metadata; and
- LegacyAttrib is the actual Metadata itself.
The starting point is the Root Sector. That's sector 11 in standard WTV files. Inside there it will show the location and size of several lookup tables. For metadata purposes, we only care about the reference to
table.0.redirector.legacy_attrib. this says how large the Table.Redirector is. It will be 8 bytes per metadata entry. So, sometimes when adding metadata through Toub, it will neglect to update this value, even though everything else is correct. If that's the case, Toub will throw an error when trying to read the values.
Next, if the Metadata Redirector Table Length is correct, then we'll check the entries in the Metadata Redirector itself. Each value corresponds to the offset in the metadata sectors where the metadata starts. Note that the offset considers all metadata sectors as one entity. i.e. if your metadata is spread across 3 sectors: 12, 15, and 2D, and because each sector if 0x1000 bytes the full metadata will be between 0x2000 and 0x3000 bytes. A metadata offset of 0x1EBE means you'll want a file offset of 0x151EBE. My app calculates these offsets automatically, btw, so you'll only need to copy/paste (overwriting) the Redirector Map over the full Table_Redirector.LegacyAttrib sector.
The majority of metadata corruption issues will be fixed by those two actions, but there is another possibility. And to fix that, you'll need to understand how the metadata
data is stored (i.e. the LegacyAttrib sectors).
Each metadata entry starts with a GUID of {5A FE D7 6D C8 1D 8F 4A 99 22 FA B1 1C 38 14 53}; then 4 bytes to describe the type of data it is: 0=DWORD, 1=STRING, 2=BINARY, 3=BOOLEAN, 4=QWORD, 5=WORD, 6=GUID; then another 4 bytes describing how long the data is. Next is a UTF-16 encoded string for the metadata Property Name, ending in a null character (00 00). Because it's a UTF-16, each character uses 2 bytes, so practically speaking there's a 00 after each byte. Then after the Property Name is the data. And then it repeats again and again with the same initial GUID.
Sometimes the reported data length will not match where it expects it to, which will present the metadata as corrupted. My app will report which metadata offset is causing the problem, as well as the reported length and the expected length.
The last issue to be aware of, some data types
require a specific data length, by definition. i.e. DWORD must be 4 bytes, QWORD must be 8 bytes, GUID must be 16 bytes (0x10). I think these lengths must be minimums, for Toub not to cause errors reading, but I'm not sure -- I haven't tested that part extensively.
And those steps will correct all the errors I've ever come across in corrupted metadata from using Toub.
Note there are several differences if you're creating WTV files via FFMPEG. It uses 0x1000 sized for both Header and Data sectors for instance, and it will place sectors in different locations that WMC7.