tvheadend currently hosts its own dvb-scan files and until this is fixed [1] there is an optional configure flag, that either uses the build in list or the 'official' files from the dvb-apps package. If i'm not mistaken, the dvb-apps package is pulled in when the DVB use flag is set, and thus, --disable-dvbscan shouldn't be disabled when said flag is set and /usr/share/dvb is available with initial scan files. Changing this will make that even an somewhat out of date tvheadend installation, can still have up to date scan files, if those files where updated. The user can thus decide whether he wants to use internal or external dvb scan files by using the dvb flag. Also, tvheadend installed its data not into /usr/share/tvheadend but into /usr/share/tvheadend/tvheadend which seems a little sloppy. [1] https://github.com/tvheadend/tvheadend/pull/168 Reproducible: Always
In https://bugs.gentoo.org/show_bug.cgi?id=433024#c14 I was told that pulling data from an external source is against ebuild rules. I agree that outdated data could be a problem, but IMO this is better fixed/worked-around in dvb-apps.
This bug is about two different problems...
media-tv/linuxtv-dvb-apps should be added as a dep and controlled via a dvb use flag. It will provide the necessary dvb scan files, although they might be outdated. Currently no dvb scan files are provided on a new install of tvheadend.
/usr/share/tvheadend problem seems to be addressed in bug 442418
I've started to take up maintainace of the dtv-scan-tables and tvheadend pulls data from there at install. Ideally, we'd have a dtv-scan-tables ebuild and have tvheadend depend on it so we can keep these better in sync. Anyhow, this bug can be closed because of that.
