[mythtv-users] mythbackend leaking file descriptors/sockets?

[Joel]

Michael T. Dean wrote:
> On 08/27/2009 12:12 PM, Joel wrote:
>> Michael T. Dean wrote:
>>> Mixing "Internet" (Schedules Direct or XMLTV) listings and EIT on the 
>>> same channel is not supported.  If you enable EIT on a channel for 
>>> which you have Internet listings, the EIT will stomp all over the 
>>> data, breaking duplicate matching and possibly more (including 
>>> scheduling).  In the future, we may have a "safe update" approach 
>>> that allows mixing them, but we don't now.
>>
>> Maybe we're talking about something different then.  When I select 
>> SchedulesDirect as my listings grabber in mythtv-setup, an options 
>> called "Perform EIT Scan" shows up.  It appears as a sub-option, only 
>> visible when SchedulesDirect is selected.  If this option were somehow 
>> incompatible with having SchedulesDirect selected, it's in entirely 
>> the wrong place in the UI, and also completely invisible at any time 
>> it might otherwise be useful, if it is at all useful.  Under what 
>> context should the Perform EIT Scan option be checked if 
>> SchedulesDirect is used?  If the answer is "never", then why is it there?
> 
> The "on the same channel" portion of my comment is the important 
> distinction.  Note that it's quite possible that you may have a video 
> source for which you wish to use Schedules Direct.  However, some, for 
> example, small-time channel in the area may not provide its listings to 
> TMS/Schedules Direct; therefore, you may choose to enable EIT on the 
> specific channel for which you have no listings data from Schedules Direct.
> 
> The Video Sources "Perform EIT scan" setting /allows/ you to use EIT on 
> the video source.  However, each channel within that source also has a 
> setting, "Use on air guide," which you enable or disable to specify 
> whether to use EIT for that particular channel.  (Note that it defaults 
> to true, so you'll need to disable it for all channels for which you're 
> using Schedules Direct to retrieve listings.)
> 
> Therefore, since many fewer users actually have video sources where they 
> need to use SD/XMLTV on some channel and EIT on others, Myth is designed 
> to allow easy configuration for using EIT on some or none of the 
> channels (and takes more work for the "corner case" of using different 
> ones on different channels within the source).  If you want to use EIT 
> for all channels, simply enable the "Perform EIT Scan" setting and, 
> since the channels all default to true for "Use on air guide," EIT will 
> be used on all channels.  If you want to use SD/XMLTV on all channels, 
> simply disable the "Perform EIT Scan" setting and, even though the 
> channels default to true for "Use on air guide," EIT will not be used on 
> the channel in the video source since EIT is not allowed on the video 
> source.

That makes sense.  Thanks for the explanation.  I do have a few local 
channels with no SD data.  I may try enabling EIT out of curiosity to 
see if the fd leaks still happen only on those channels.

> 
>> Also, if EIT scanning and SchedulesDirect data are incompatible, wy 
>> doesn't the EIT scanner to a check to see if SchedulesDirect data 
>> exists, and if so, exit?
> 
> Patches welcomed.  :)  (Though, really, the time would probably be 
> better spent working on a proper fix for 
> http://svn.mythtv.org/trac/ticket/1770 .  If interested, you should 
> mention your proposed changes (or ask for design recommendations) on the 
> -dev list as a couple of the developers already have an idea of how it 
> should be implemented.)

We'll see if I get the time and determination to look into it any 
further.  I'm rather swamped at the moment, and was only forced to look 
into this problem as far as I did because mythbackend was needing to be 
restarted every 42 hours, which got annoying.  That bug is interesting 
though,  I remember seeing behavior like that at some point in the past 
as well.  I probably disabled EIT scanning at the time to fix it and 
forgot about it.

> 
>>   The failure mode of leaking file descriptors at a rate that breaks 
>> the backend in two days seems an odd choice.
> 
> That's unrelated to the mixing of EIT and SD--however, the lack of 
> support for mixing means you won't lose anything (and will actually gain 
> a better-working system) by disabling EIT.

I'll start by re-enabling EIT just on channels without SD data.  If I 
still see it leaking fd's I'll try to dig a little deeper.

Thanks,
Joel