When Scanning Pre-defined Muliplex's,.. Freqid is not entered.

[mark@…]

When Scanning/tuning Pre-defined Multiplex's,.. Freqid information is not entered into the database.

Although if a "full scan" and retune is performed Freqid information is entered correctly.

[Mark Hamblin <mark@…>]

Just some more back ground,.. I tune to my local transmitter ( oxford ) which brings in most of the local Mux's,.. plus some other remote Mux's. Once all these are tuned and loaded into Myth, ( including resolving the 238 conflicts,.. ) I can remove the unwanted Mux's and add the missing one.

Once I have the required Mux's I would like to periodiclly just retune/re-scan existing mux's, unfortunately when I do an existing Mux's retune,.. all freqID info is lost,.. and FreView? channels fail.

[J.Pilk@…]

I don't want to intrude here, but I do this 'quite often', although now usually with a DVB-T2-capable tuner and a recent 0.28-pre build. Have you seen Ticket #10217, which now extends back several years? It might suggest something. Otherwise details of Myth-version and tuner type might help.

[Mark Hamblin <mark@…>]

Intrude all you like,.. no probs,... my s/w is 27.5+ ( the latest release build ) I have looked at your old ticket,.. and it does have some similarities,.. the key issue to me,.. that I notice,.. is that FreqID is missed of the database tables, ( as observed from mythWeb )... so I am unable to run my SQL script to sort my channels. ( Which looks at SourceID and FreqID )

If this issue is out of scope of myth I could live with that if during the final tuning stages myth could offer a "Suggest all", for any conflicts,.. as during a retune a few days ago I had to reconcile 238 conflicts,.. each taking four key presses,.. which really puts me off doing any retunes... but they are just necessities of life with myth and TV in general.

[J.Pilk@…]

In each of the three places that I have set up Myth I have had good reception from only one transmitter, so I've never had more than eight transports to consider - here 5*dvb-t and 3*dvb-t2. I know people in the Oxford region often detect stuff from more transmitters, but how many do you really need? Surely you can use the transport editor, the links between muxes, and perhaps published transmitter data, to eliminate some transports from your repeat scans? I'm afraid I don't understand the reason for your 'conflicts' - but good luck :-)

[J.Pilk@…]

I suspect that your script, if you really need it, isn't looking in a table appropriate for digital tv.

​https://www.mythtv.org/wiki/Channel_table

​https://www.mythtv.org/wiki/Dtv_multiplex_table

[Karl Egly]

I'm not sure what it is that breaks due to freqid being null (as it should for DVB-T channels IMHO).

FreqID is for analogue channels containing the id/name of the channel. E.g. "21" when the transmission has a center frequency of 306 + 8 * 21 MHz / 474 MHz.

See ​http://stakeholders.ofcom.org.uk/broadcasting/guidance/tech-guidance/transmitter-frequency/

The easiest way forward for your script appears to be to use the mplex id or the frequency from dtv_multiplex instead of freqid.

For your use case the way to channel scan appears to be to just keep the 8 relevant transports and rescan only these known transports. (thus losing the freqid)

Can you confirm, that these two suggestions lead to a working setup?

More schema documentation at ​https://code.mythtv.org/doxygen/group__db__schema.html

[Mark Hamblin <mark@…>]

Just realised I have lost 2 replies here,.. ( forgot to hit modify Ticket). So to play catch-up in breif,...

I use a simple sql script as follows

set @chancnt := 100; -- BBC One, 101 set @chancnt := @chancnt+1; UPDATE channel SET channum=@chancnt, visible=1, xmltvid="oxfordshire.bbc1.bbc.co.uk", callsign='BBC One' WHERE name='BBC ONE Oxford' and freqid='53'; -- FV100% BBC 1 oxf UPDATE channel SET channum=@chancnt+1000, visible=1, xmltvid="oxfordshire.bbc1.bbc.co.uk", callsign='BBC One' WHERE name='BBC One Oxford' and sourceid='1'; -- FS BBC One --

I run this script once I have tuned both FreeView? and FreeSAT sources,... but because FreqID is a NUL field,.. following a Mux re-scan,.. things fail.

Now this imho,.. is nothing to do with the script,.. as I can go into MythWeb,.. set BBC Oxford as visible and the try to tune/lock it via the front end,.. it fails needless to say,.. as do ALL FreeView? channels,.. rescanned following a Mux only rescan..

Does that clarify things a little more...

[Mark Hamblin <mark@…>]

Just realised I have lost 2 replies here,.. ( forgot to hit modify Ticket). So to play catch-up in breif,...

I use a simple sql script as follows

set @chancnt := 100; -- BBC One, 101 set @chancnt := @chancnt+1; UPDATE channel SET channum=@chancnt, visible=1, xmltvid="oxfordshire.bbc1.bbc.co.uk", callsign='BBC One' WHERE name='BBC ONE Oxford' and freqid='53'; -- FV100% BBC 1 oxf UPDATE channel SET channum=@chancnt+1000, visible=1, xmltvid="oxfordshire.bbc1.bbc.co.uk", callsign='BBC One' WHERE name='BBC One Oxford' and sourceid='1'; -- FS BBC One --

I run this script once I have tuned both FreeView? and FreeSAT sources,... but because FreqID is a NUL field,.. following a Mux re-scan,.. things fail.

Now this imho,.. is nothing to do with the script,.. as I can go into MythWeb,.. set BBC Oxford as visible and the try to tune/lock it via the front end,.. it fails needless to say,.. as do ALL FreeView? channels,.. rescanned following a Mux only rescan..

Does that clarify things a little more...

[Mark Hamblin <mark@…>]

Just following up on some more points raised,.. in the UK,... TV tuners still refer to the "Channels" in the range 21-68,... and some ( Sony ) do actually display the frequency,... and they all tune Digital broadcasts, the analogue stuff has been switched off ... ( this we all know ).

Now when Myth does a full Scan,.. the FreqID field is populated with the channel frequency that locked/tuned that particular channel, including several unwanted transport Mux's,.. ( which granted can be deleted and conflicts reconciled),.. but following a "channel scan with the 8 relevant transports",.. the system fails to populate the FreqID field,... ( as displayed in MythWeb )

[J.Pilk@…]

I haven't yet examined it in detail but what you coyly call 'your script' and its rationale is a lot easier to grasp at:

​https://www.mythtv.org/wiki/UK_Channel_Assignments#Combined_FreeView_and_FreeSat_HD_channel_assignment

[Mark Hamblin <mark@…>]

Ah you have found my SQL script that I developed to create the channel ordering I desired.... but the only thing of interest here ( imho ) is that the script looks for the channel ( freqID ),.. of particular FreeView? channels,.. when selecting which FreeView? channel to allocate, ( to a particular slot in the EPG,..... And when this script is run following a "scan existing transports" ( having deleted the current channel data ),.. the FreqID field is not populated, so hence the script fails,.. as it cannot find an SQL match ( FreqID=Nul ),.. so no FreeView? channels are assigned the the EPG view range and actually set to visible.

Taking this to the next step,.. even if a known FreeView? channel is made visible, it still cannot be viewed as myth cannot obtain a lock,... I assume ( from my limited knowledge ) because FreqID=Nul,...

[paulh]

Isn't FreqID only be used for old analogue channels? I could be wrong but I would assume for digital channels we use the frequency from the dtv_multiplex table to tune.

[J.Pilk@…]

The problem appears to be that it is still inserted by a full scan, but not by the desired and quicker 'known transports' scan. I suspect that mplexid, also in the channels table, would work - but it would need a whole lot of new test values in the script.

[J.Pilk@…]

I'm still not sure when the NULLness of frequid becomes a problem, but you might be able to repopulate it post-scan by reading the frequency for mplexid from dvt_multiplex and doing a simple calculation. The frequency value might not be entirely accurate, and could have an offset from the analogue Channel value, but suitable integer arithmetic ought to be devisable.

Then your script could be used unchanged - provided that the frequid slot stays there! HTH.

[Mark Hamblin <mark@…>]

Guys,... I see lots of head scratching going on here and I think there's more to this than meets the eye.... Up until now,.. I have always performed my tuning as follows:-

---

Full Scan FreeSAT,... Shuffle Up Chan. Numbers 100,000+ Full Scan FreeView? reconcile conflicts and Shuffle up,... 50,000+

---

Sort Channels to Create my customised EPG listing ( Basically shift down channels as required) Everything works fine....

---

Then later Use exsisting FreeSAT tuning data Re-Scan FreeView? using existing transports...

---

No FreeView? FreqID data stored..... and FreeView? channels do not display/lock

NOW,... here's the funny:- With Renewed Gusto,.. I started some retunes and saved databases,.. to see where/what falls over

Initially I started to play just tuning FreeView?,... and to my disgust,.. it all started working,.. even with "scan existing transports",... ( but I had taken some shorts cuts to save some time),.. so hence back to drawing board, following EVERY step....

To cut a long story short,... ( and 1000's of key presses, and arm ache later,.. please please can someone add "Suggest all" to reconcile channels to be added),....

Now this is where I believe the route of my problems lie:-

---

If I perform No Channel Shift-up,.. transport only rescan works perfectly,.. as you guys expect However:- If I perform a channel number shift up,.. to 50K plus,.. and then do a transport only rescan,.. I actually get two sets of entries in my channel list as seen via mythWeb,.... a set of channels starting from one,.. with FreqID entered,.. and another set at 50K+ with no FreqID.

---

I thus propose that my re-scan "existing transports" fails.... because I have channel numbers in a range greater than is supported, somewhere in the code.

Does this have some validity,.. or am I barking up the wrong tree still....

[mark@…]

Ok,.. Sorry guys,.. I had thought this was sort of self inflicted as I shifted channels around to get a functional and logical arrangement for FreeView? and FreeSAT channels. I now perform channel shifting once tuning is complete for both FreeView? and FreeSAT. But having learnt more more about broadcasting standards,.. and more about Mythtv I am left thinking there maybe a problem when tuning. My "retune-Regime" for a VideoSource?,.. is to delete existing tuned channels,.. so hence I will delete all FreeView? channels, or all FreeSAT channels. If this is a 1st tune,.. as it was when I built a "new" 0.28 system I would do a Full scan,... this is a bit of a pain as it tunes many marginal channels,.. which are only duplicates of the proper transmitter,.. so hence I will delete the none required Mux's.... So,.. once I have a "proper" set of Mux's I prefer to re-scan existing Mux's,.. once the existing channels have been deleted. Once a re-scan of existing Mux's is complete,.. a review of scanned channels in mythweb reveals no fredID info has been written to the Dbase,.. and hence those channels cannot be viewed/locked in Mythtv. Am I missing the obvious?....

[J.Pilk@…]

Your scanning procedure sounds very similar to mine, and I often find that in a new location I will fail to get lock on some channels. But the travelling system runs a year-old build and current versions would probably not be the same. More than one rescan eventually provides a working system, but I haven't seen a pattern and have the impression that things vary from one transmitter to another. I use only DVB-T/T2.

But, as far as I know, freqID isn't used in Myth for digital channels, so I'm not convinced by your 'hence' :-) I have the impression that the 'full scan' best populates the dtv_multiplex table - but I haven't looked at its contents, or the code, recently.

[mark@…]

Humm,..Yes I had heard/read somewhere along the way that FreqID is not used,... However,.. all I can say is that when FreqID is Not populated,.. then channel no-works,... yes clearly FreqID might just be a symptom.... and the "end" result is that Myth fails to populate the freqid field. Part of my problem/frustration is that when I do a FULL re-tune,.. having both freeview/SAT inc S2/T2... So all available FREE,.. tune-able channels,.. when I do the final re-scan I get close to 200 duplicate channels,.. which all need manually allocating,.. ( thats 800+ key presses ). if there is a possibility of adding a menu option to Add channel Dups (Auto Allocate ),.. I would be very grateful,... Now,.. No-freqID,.. is there any debug code I can run,.. whilst tuning... I can do some table dumps if that would be useful,.. I am getting into sql table dumps at the moment,.. if that would help,.. So we can get to the bottom of this... One last question,... If I do database backup,... and a subsequent restore,.. does that bring back all the tuning info,.. I "believe" it does,.. is this a correct understanding?

[J.Pilk@…]

What happens if you do a full scan and then use the Transport Editor to delete your unwanted transports (d)? I can only do it one-at-a-time, but it's quicker than deleting channels. I would probably do an all-known-channels scan after that, but it might not be needed.

Maybe look at this specific comment: ​https://code.mythtv.org/trac/ticket/10217#comment:21

TTBOMK a DB restore will bring back the old configuration. Good luck!

[mark@…]

If I do a full re-scan and delete unwanted transports,.. that seems to works fine,... its just resolving the 200 duplicates clashes that causes hassle and my reluctance to do a full re-scan. hence my secondary question about auto add duplicates. I have used the "Look for linked transports",.. when doing re-scan existing transports,.. but can leave me with No-FreqID outcome. As an a-side it runs much quicker,... as only a limited number of frequencies need to be checked, rather than the whole spectrum, as one might expect. WRT to data not being copied to the various tables correctly,..I have instances of erroneous chan-numbers being set,... but have just fixed and moved on as they say.

[Klaas de Waal]

As discussed. the channel number in the freqid field is something from the analog days. It does not identify the channel, only the multiplex and that is already identified by field mplexid. The current implementation of filling the field when a Full Scan is done and not filling the field with other scans is inconsistent.

The plan is therefore to leave the freqid empty for all digital channels.

[Stuart Auchterlonie]

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] - ​https://github.com/MythTV/mythtv/issues