search

ElvishArtisan / rivendell

A full-featured radio automation system targeted for use in professional broadcast and media environments
205 stars 64 forks source link

RDCatch: No mettering while recording but HUGE output to syslog. #842

Closed alexolivan closed 1 year ago

alexolivan commented 1 year ago

Hi.

Today I've tried some RDCatch event recordings and I've noticed that mettering on RDCatch GUI modules are dead while recording audio. Checking the recorded cut on RDLibrary clearly shows that it is no problem of lack of audio. So there was audio, it was recorded, but it was not shown.

Simultaneously, while monitoring syslog for events I realized that syslog goes crazy with an insane amount of entries being logged... I cannot avoid thinking that it appears as if every single mettering event results in one or more syslog entries. Here's an example of what I got (multiply that by orders of magnitude):

Nov 11 10:51:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 0:039F:0399" to 239.192.255.72:20539
Nov 11 10:51:59 tgnradio rdcatchd: sent catch event: CATCH tgnradio 8 0:0370:0360
Nov 11 10:51:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 0:0370:0360" to 239.192.255.72:20539
Nov 11 10:51:59 tgnradio rdcatchd: sent catch event: CATCH tgnradio 8 0:0368:0357
Nov 11 10:51:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 0:0368:0357" to 239.192.255.72:20539
Nov 11 10:51:59 tgnradio caed: UnloadRecord - Card: 0  Stream: 0, Length: 5269504

At first glance, I see that so much stuff in syslog makes it to grow inmense and very cluttered... but I'm also thinking that I/O could potentially cause problems in certain scenarios if some task do depend on extensive logging to keep up.

Cheers!

ElvishArtisan commented 1 year ago

Ugh! Silly typos on my part.

Fixed in 9e1c0a9, cf9d987 and 8f00a09. Please test!

alexolivan commented 1 year ago

Ok... updated to latest commit and I can confirm that meters in RDCatch GUI module do work again.

However, I'm noticing that while the amount of messages during the recording seem to have been cut by half, still syslog continues to be flooded with messages like this:

Nov 14 10:35:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 1:03E3:03E5" to 239.192.255.72:20539
Nov 14 10:35:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 1:03FC:03F3" to 239.192.255.72:20539
Nov 14 10:35:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 1:0411:0419" to 239.192.255.72:20539
Nov 14 10:35:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 1:040F:0413" to 239.192.255.72:20539
Nov 14 10:35:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 1:040F:0413" to 239.192.255.72:20539
Nov 14 10:35:59 tgnradio ripcd: sent catch event: "CATCH tgnradio 8 1:03EC:03F1" to 239.192.255.72:20539

Seems to me as if a similar fix than the one for 'rdcatchd' component (no syslog flood anymore) is needed for the 'ripcd' counterpart.

Cheers!

ElvishArtisan commented 1 year ago

Looks like you've got your syslog logging priority turned all the way up to LOG_DEBUG. You're going to get lots of probably uninteresting messages logged with that setting.

However, I agree that sending metering messages (even at LOG_DEBUG priority) by default is not a good idea, so I've committed code (c54d080) that will suppress sending those. Other catch event updates will still get logged though.

alexolivan commented 1 year ago

Yep... it's fixed... closing.

Thanks!