[mythtv-users] Mythtv --- Tips on how to debug EIT?

Michael T. Dean mtdean at thirdcontact.com
Tue Jun 21 17:06:07 UTC 2011


<Moving to the -users list, where some users who use EIT or David Engel 
or Stuart Aucterlonie/Stuart Morgan might have some ideas.>


On 06/21/2011 08:35 AM, Håkon Alstadheim wrote:
> Saw your comment on Ticket #9775, where you changed the title to 
> "Holes in EIT data not always resolved properly".
>
> I'd like find out what causes oddities in my case,I am not sure your 
> assessment covers my issue. I am somewhat at a loss on how to proceed. 
> Probably I should enable logging for SOMETHING, and create a script to 
> monitor changes in EIT data and recording schedule. My problems with 
> EIT data revolve around a custom recording rule that records 
> everything with a specific keyword in the description. These things 
> very often end up being recorded several times in parallell, wasting 
> space and crowding out other recordings.

That sounds like it's happening because at the time when the show was 
originally scheduled to start, we kick off a recording.  Then, the EIT 
changes the start time (and possibly end time) of the listing (after 
we're already in the period where it was originally listed to air--so 
after we've started recording that program).  So, now, we have a /new/ 
program in the listings (channel ID + start time + end time determines 
uniqueness of programs) that we're not currently recording, but that 
matches your recording rule.  Therefore, when we hit its (new, later) 
start time, MythTV starts to record it, also (even though in the real 
world, it's already recording it).  This may continue a couple times as 
the EIT data changes start times and dependent upon where your 
every-5-minute EIT reschedule occurs.

> Do you have any tips on exactly which SOMETHINGs i should log, and how 
> to sift through the output to find the glitches ? I'm reasonably 
> proficient with perl, so I could probably run a perl process to watch 
> for tell-tales in the logs, and grab the relevant parts of the 
> database at the critical moment. Suggestions for which tell-tales to 
> look for in the logs, an which parts of the database to grab would be 
> extremely welcome. My SQL-fu is NOT very good, so an example on how to 
> get at the show before and after the problematic one in the database 
> would be welcome. I'm pretty sure I need both EIT and recording 
> schedule data to work this out, but that is as far as my thinking goes 
> right now.
>
> Hopeful greetings Håkon Alstadheim.

Probably the best debug logging you could do would be to run dvbsnoop to 
watch the EIT data in real time and record each EIT event to a log 
filie.  Then, you should be able to dig through those logs to see if the 
situation I described, above, is occurring.

If you can get such logs to prove this is what's happening, we may be 
able to modify MythTV to handle this better.  While David Engel is the 
scheduler guru and the Stuarts are EIT gurus (so their opinions/analyses 
are far more imporant than mine), it sounds like in your case, it's the 
start time's being pushed out to a later time after we're already inside 
the originally scheduled air time (after we've already started a 
recording) that's causing the issue, and this is probably what we don't 
properly handle (I'm guessing we handle end time changes much better).

In fact, (guessing, without having looked at any of the EIT code) the 
fix may be as easy as just having our EIT collector refuse to modify 
times in the past.  Or, really, if it's the start time's changing that's 
causing the problem, it's also possible that the fix for 
http://code.mythtv.org/trac/ticket/4879 will fix the issue for you.

Then again, if we don't modify times in the past, that would mean that 
it's not the changing start time, but the modified end time is causing 
the problem and (even though we're past the scheduled start time) MythTV 
is deciding to do a "partial" recording of the "new" program since the 
same episode doesn't air again within the listings period.  If that's 
the case, we need to better identify "same showing" so we know we're 
actually recording the show already or have the EIT collector properly 
submit modifications to the recorder so we know we're already recording 
the show (and the behavior may actually be affected by the fix for 
http://code.mythtv.org/trac/ticket/9775 ).

However, to really know what's happening, we need to see what EIT events 
you're getting that are messing with your schedule.  And, once we have 
that, the scheduler and EIT experts can weigh in with better ideas.

Mike



More information about the mythtv-users mailing list