[mythtv-users] Leading zeros in freqid field

[Tom Collins]

I recently updated MythTV to v31.0-166-gbb507cf183-dirty on Arch Linux, and
have encountered a new problem.  Using an older tuner card to tune Analog
on cable TV, recordings on that input would fail, with a error in the log
like this:

Nov 16 23:42:19 myth1 mythbackend[12581]: 2021-11-16 23:42:19.727553 I
 V4LChannel[5](/dev/video0): SetInputAndFormat(5, NTSC) (v4l v2)
input_switch: 0 mode_switch: 0
Nov 16 23:42:19 myth1 mythbackend[12581]: 2021-11-16 23:42:19.729150 E
 V4LChannel[5](/dev/video0): GetCurrentChannelNum(004): Failed to find
Channel
Nov 16 23:42:19 myth1 mythbackend[12581]: 2021-11-16 23:42:19.729158 E
 Channel(/dev/video0)::Tune(004): Error, failed to find channel

After digging around, I found that the problem is that the freqid field in
the channel database table is always 3 digits, and includes leading zeros.
The "004" above is an example of that.

The channels were inserted automatically by mythfilldatabase from Schedules
Direct, using the tv_grab_zz_sdjson grabber.

In my case, I was able to make this work with some SQL:

UPDATE channel SET freqid = TRIM(LEADING '0' FROM freqid) WHERE sourceid=2;

and by forever using the --only-update-guide argument to mythfilldatabase,
but both of these steps are a workaround for some kind of fundamental
problem.  Seems like either Schedules Direct is inserting leading zeros
where they shouldn't be, or mythfilldatabase or the grabber is doing it.

Anyone have any thoughts on where the real problem might be so we can get
this fixed?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20211121/1b65c9ab/attachment.htm>