LTC decoding inconsistent with other software and hardware

[charlyr82]

Environment

• OS: Windows 11
• Version 1.9.17

Using LTC input in Chataigne if the LTC packets include information in the userdata bits it affects the decoding of the timecode hh:mm:ss:ff value.

I have an LTC track, which can be found here https://drive.google.com/file/d/1fiiiV-HJrp0NwfWwR4cVzb1ajSeFPsfY/view?usp=sharing

Almost all of the software and hardware that I use decodes the above LTC audio as starting at a timecode of 02:00:00:01

Chataigne decodes it as 314:00:00:01 (it adds 312 hours, which is 13 days that I think it is taking from the userdata bits in the LTC packets)

I would expect the userdata bits to be ignored in the decoding of the actual timecode as the specification says that the maximum time is 23:59:59:59 and this seems to be how all of the other software and hardware that I use works.

It could be argued that I should be using cleaner LTC audio files which don't have any userdata in the packets (all of the files that I have where the user data is all zeros work perfectly), however I am not the person that creates or plays back the LTC in my environment, I have just been given copies of the actual LTC files that are used in the playback system for the show. Everybody else's systems are decoding the LTC as starting at the intended 02:00:00:01 (Lighting Consoles / Pyrotechnic Controllers / Media Servers etc) but Chataigne seems to be decoding the signal in a different way, so all of my timecode offsets are different.

[calebwest-SS]

This has been solved in 1.9.18b2 (released yesterday). There is now an option, off by default, to include the user bits as a date. Should solve your problem.

[charlyr82]

Thank you very much, it does indeed solve the problem.