WAWZ Undocumented ServiceDataType and MIMEType

[markjfine]

Searching the bands in NJ this week and came across 99.1 WAWZ, a gospel-oriented station with 3 audio services and a data service:

15:38:55 SIG Service: type=audio number=1 name=HD1 
15:38:55   Audio component: id=0 port=0000 type=0 mime=4DC66C5A
15:38:55   Data component: id=1 port=1000 service_data_type=265 type=3 mime=BE4B7536
15:38:55   Data component: id=2 port=1001 service_data_type=265 type=3 mime=D9C72536
15:38:55 SIG Service: type=audio number=2 name=HD2
15:38:55   Audio component: id=0 port=0001 type=0 mime=4DC66C5A
15:38:55   Data component: id=1 port=1002 service_data_type=265 type=3 mime=BE4B7536
15:38:55   Data component: id=2 port=1003 service_data_type=265 type=3 mime=D9C72536
15:38:55 SIG Service: type=audio number=3 name=HD3
15:38:55   Audio component: id=0 port=0002 type=0 mime=4DC66C5A
15:38:55   Data component: id=1 port=1004 service_data_type=265 type=3 mime=BE4B7536
15:38:55   Data component: id=2 port=1005 service_data_type=265 type=3 mime=D9C72536
15:38:55 SIG Service: type=data number=38 name=TEST_STR_E
15:38:55   Data component: id=0 port=2001 service_data_type=511 type=0 mime=B81FFAA8

Currently investigating what this data service could be. Neither code is something listed within nrsc5.py.

[argilo]

Interesting! The spec says that service data type 511 means "Reserved for Special Tests".

Are there any stream packets showing up on port 2001? If so, it would be great if you could save them for analysis.

[markjfine]

Unfortunately, no. In fact they have some cover art and/or logos with evt.name == "", causing other crash-worthy problems. That makes me think more like a situation where an engineer went rogue, just setting things and forgetting to put them back.

[argilo]

In fact they have some cover art and/or logos with evt.name == "

If you're seeing that in nrsc5-gui, you probably need to copy over nrsc5.py from nrsc5 itself, since the API has changed.

[argilo]

I could maybe solve that API backwards compatibility issue by reordering the C structs so the new items are at the end.

[markjfine]

Am using the new nrsc5.py (with 511 and B81FFAA8 added). Was saving the aas stuff yesterday in Virginia, so it's got to be the station.

[argilo]

I opened #320 to add the service data type to the API.

The MIME type is undocumented, so I'm still thinking about what to do with that. I've also seen a MIME type of 0xFFFFFFFF in XHDR tags on one station, which causes trouble for the Python API.

[argilo]

And #321 fixes the inadvertent API breakage with LOT files.

[argilo]

Am using the new nrsc5.py (with 511 and B81FFAA8 added).

But did it also have the new expires_utc field added? I suspect that was the cause of the problem. #321 should fix things so that nrsc5-gui will still work without changes.

[markjfine]

Ah. I should have looked at the actual LOT status message. It's possible the new output confused the regex.

[argilo]

It's possible the new output confused the regex.

nrsc5-gui doesn't actually use regexes anymore. It uses the C API, through the Python wrapper. But #310 broke binary compatibility in the C API because it added a new field in the middle of the lot structure (right before the LOT name field, in fact, which would have prevented nrsc5-gui from getting the LOT filename).

[markjfine]

I may have confused myself there. You're correct. nrsc5-dui still uses the regex array, not nrsc5-gui.

[argilo]

Perhaps we should leave this open until we decide what to do with the new MIME type. We might also want to think about how to handle unknown values more gracefully in the Python API wrapper. (E.g. instead of throwing an exception, the wrapper could just pass a raw integer value instead of an enum object.)

[markjfine]

Good idea.