2012-05-20, 18:19
I've made some progress in reconnecting control and mysql connections after they have been disconnected. I will push my changes to my fork after some more testing.
In the meantime I've re-installed my server running MythTV backend meaning I'm now also running 0.25... well in fact, 0.25 has some serious IPTV bugs, so I'm running a 'special' fixes/0.25+rtp version, which is basically 0.25 with fixes RTP/UDP IPTV recording.
I notice that during start-up libcmyth receives RECORDING_LIST_CHANGE UPDATE more than 350 times resulting in equal number of updates to the complete recording list. As I have over 300 recordings (less than 350 though) it gives a pretty high load during startup and makes the log file grow very very fast... I rely on the log for debugging, so disabling it is not always an option. I've not observed this behavior on 0.23+fixes. Sounds familiar to anyone?
I see that libcmyth already receives a proginfo structure, but not using it yet. Are there plans to use the structure instead of updating the complete list when this message is received?
In the meantime I've re-installed my server running MythTV backend meaning I'm now also running 0.25... well in fact, 0.25 has some serious IPTV bugs, so I'm running a 'special' fixes/0.25+rtp version, which is basically 0.25 with fixes RTP/UDP IPTV recording.
I notice that during start-up libcmyth receives RECORDING_LIST_CHANGE UPDATE more than 350 times resulting in equal number of updates to the complete recording list. As I have over 300 recordings (less than 350 though) it gives a pretty high load during startup and makes the log file grow very very fast... I rely on the log for debugging, so disabling it is not always an option. I've not observed this behavior on 0.23+fixes. Sounds familiar to anyone?
I see that libcmyth already receives a proginfo structure, but not using it yet. Are there plans to use the structure instead of updating the complete list when this message is received?