So I posted a while back looking for information on the recordings. My thanks to those who posted responses but I don't recall ever seeing anything from Uniden / UPMan.
http://forums.radioreference.com/uniden-scanners/283478-x36-recording-data-fields.html
I tried the program above and it does allow for loading and playing of recordings. However, it doesn't provide complete/accurate information that is stored in the header of the x36 recordings. Of the recordings I've reviewing, the TGID and Radio IDs are never shown.
The only other place I've been able to see some of the header fields was via the Windows data fields like "Title" and "Comments". Still that hasn't exposed (that I can tell) all of the textual/useful information from the header. Additionally, while looking at this information, it seems not only incomplete but also inaccurate. The best description I can give is that buffers data/field buffers are not cleared in many cases before the next recording is captured. Many times the talkgroup ID is carried from one recording into the next thus applying the wrong TGID to the recording.
Yesterday, I finally took the time to write a simple parser for the headers. The results were interesting in the nearly all of the fields are populated (which didn't seem possible). Then I noticed that the TGID and Radio IDs are clearly sometimes carried over from the previous recording. This is very obvious when the radio leaves one system and scans the next. In contrast, it appears that if/when I'm scanning a single system, the information looks more realistic (but could still be "carry over" from one transmission to the next).
I'm suspecting that the reason there has been no response from UPMan is because this is known to be a problem and maybe really isn't even supported. But it also makes me wonder - I had reported previously that the radio seems to work better when you monitor a single system (control channel) and misses alot of transmissions when scanning multiple systems (Note: I'm not talking about activity on one system when scanning a different system - this is about the radio failing to "lock on" and find active talkgroups when scanning through a system). Is there a possibility that the radio is "holding" characteristics of the "last" active system/control channel when it starts monitoring the "next" system causing the radio processing to be "confused"?
I'm really interested in getting this thing to work better -- and thus I am offering my observations. Some dialogue would be nice....