Toub.MediaCenter.Dvrms.dll: WTV metadata corrupted when writing changes

Post Reply
mrsilver

Posts: 63
Joined: Mon Oct 20, 2014 5:01 pm
Location:

HTPC Specs: Show details

Toub.MediaCenter.Dvrms.dll: WTV metadata corrupted when writing changes

#1

Post by mrsilver » Wed May 12, 2021 8:21 am

Does anyone have any experience of renaming titles in recordings using Toub.MediaCenter.Dvrms.dll?

I'm trying to write something in c# which, when given the name of a wtv file, will remove "new:", "premier:" or "repeat:" from the title. The reason for this is because I add the recording to Plex and it fails to match the show because of the prefix.

My rough and ready code is as follows:

Code: Select all

using Toub.MediaCenter.Dvrms.Metadata;

static void Main(string[] args)
{
	// Load the file and create copy of metadata
	DvrmsMetadataEditor md = new DvrmsMetadataEditor(args[0]);
	Hashtable ht = (Hashtable)md.GetAttributes();

	string title = MetadataEditor.GetMetadataItemAsString(ht, "Title");
	if (!string.IsNullOrEmpty(title))
	{
		// Make a copy of the original title
		string newtitle = title;
		
		// Remove all the common prefixes
		string[] prefixes = { "new:", "repeat:", "premier:" };
		foreach (string prefix in prefixes)
			newtitle = newtitle.Replace(prefix, "", StringComparison.InvariantCultureIgnoreCase);

		// Remove any trailing space
		newtitle = newtitle.Trim();

		if (!String.Equals(title, newtitle))
		{
			// Write out updated title and save
			ht["Title"] = new MetadataItem("Title", newtitle, MetadataItemType.String);
			md.SetAttributes(ht);
		}
	}
}
My problem is that although the replacement is done, as soon as SetAttributes is called to save the changes, the metadata in the recording corrupts.

Does anyone know how to resolve this? Thanks.

Space

Posts: 2838
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#2

Post by Space » Wed May 12, 2021 3:24 pm

I don't know anything about the DLL, but none of my WMC recordings has any of those prefixes in the Title, how are they getting there in the first place?

mrsilver

Posts: 63
Joined: Mon Oct 20, 2014 5:01 pm
Location:

HTPC Specs: Show details

#3

Post by mrsilver » Thu May 13, 2021 12:56 pm

I'm using EPG Collector to grab Freeview HD OTA guide data and then load it into WMC.

Doing some further digging, it's looking like W7MC is prefixing my titles with "New:" even though the title in the EPG guide doesn't include it. I suspect it's the way that EPG Collector formats the MXF file which is then uploaded into W7MC - so I've asked on the EPG Collector forum.

Thanks for helping to narrow it down!

Charles

Posts: 5
Joined: Sun Jul 28, 2019 2:21 pm
Location:

HTPC Specs: Show details

#4

Post by Charles » Tue Jul 06, 2021 3:55 am

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.
Attachments
WtvBinaryInspector v1.0.0.0.zip
(135.85 KiB) Downloaded 46 times

Space

Posts: 2838
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#5

Post by Space » Tue Jul 06, 2021 5:20 am

Nice!

I've only had one WTV file have it's metadata get corrupted while trying to modify it over the network (it was on a shared drive). I just deleted the file, since I knew no way to fix it. Now, if it happens again, I'll at least have a nice toy to look at it with, and probably still not know how to fix it. But I have used a hex editor before, so maybe...

Thanks!

Post Reply