[mythtv] Ticket #11399: EIT scanner causes unnecessary reschedules and prevents idle shutdown

[Roger James]

On 10/02/13 20:31, MythTV wrote:
> #11399: EIT scanner causes unnecessary reschedules and prevents idle shutdown
> -----------------------------------+----------------------------
>   Reporter:  Roger James <roger@…>  |          Owner:  stuarta
>       Type:  Patch - Bug Fix        |         Status:  new
>   Priority:  minor                  |      Milestone:  0.26.1
> Component:  MythTV - EIT           |        Version:  0.26-fixes
>   Severity:  medium                 |     Resolution:
>   Keywords:  eit idle               |  Ticket locked:  0
> -----------------------------------+----------------------------
>
> Comment (by stuarta):
>
>   I'm going to agree that Roger's interpretation of the specs appears
>   correct.
>   I will however side with Dekarl on the version number field being only a
>   5 bit field, and thus the part of the patch which touches the bitmask on
>   the
>   version appears incorrect.
>
>   Progress \o/ :)
>
And here I was, just about to throw my toys out of the cot :-)

The only reason I changed the mask was to give room to save an invalid 
version number marker (0x20). The actual version numbers have already 
been masked to 5 bits by the DVB parser by the time they reach eitcache. 
I admit I did not look at the database code very closely but it looked 
to me like the per channel eventid maps are read in as channels are 
encountered and remain in memory until mythbackend terminates. I thought 
it was safer just to ignore the version number in the database because 
it was probably way out of date anyway. Especially if we had had an idle 
shutdown in the interim! Thinking about it again I could have left the 
mask at 5 bits because I was going to ignore the value read in anyway! 
The logical conclusion then is that the version field could just be 
removed from the database table. But it is probably nice to have it for 
debugging.

I vaguely recollect seeing something in the specs about handling jumps 
in version number.

Roger