DVB-T HD NetID and TransportID not being set during channel scan

[J.Pilk@…]

Background is here: ​http://www.gossamer-threads.com/lists/mythtv/users/499078#499078

After deleting all cards, channels and transports and entering only the HD transport freq and modulation, QAM-256, the transport settings do not appear to be updated by the channel scan. Attempts to record show a partial lock. mythbackend -v channel shows that frequency tuning is successful but netid and tid are both passed as zero; no match is found and no recording is started.

DVBChan(1:/dev/dvb/adapter0/frontend0): New Params: 769666667 qam_256 a auto auto 8 a auto a v fec: aut o msys: UNDEFINED rolloff: 0.35

DTVSM(/dev/dvb/adapter0/frontend0)::SetDVBService(transport_id: 0, network_id: 0, service_id: 17540):

[J.Pilk@…]

Scanning, LiveTV, recording and EIT collection all work after direct update of the HD transportid and networkid in the dtv_multiplex table. It looks as if this used to be supported in the editor but I can't find it there now. Several other values for the same DB row are still null after doing this but are set for the SD transports; I don't know if this matters.

​http://www.gossamer-threads.com/lists/mythtv/users/499185#499185

[J.Pilk@…]

A milder version of this mythtvsetup/dtv_multiplex bug also affects the SD transports in 0.24-fixes; for more details see

​http://www.gossamer-threads.com/lists/mythtv/users/502394#502394

I understand that development of mythtvsetup has effectively stopped and I haven't examined the new scanning procedures, but it seems worth linking these reports.

[J.Pilk@…]

I just added an html version of my dtv_multiplex table for the Waltham transmitter. SD transports populated by mythtvsetup, HD transportid and networkid inserted as above. Output from mysql_workbench.

[dekarl@…]

Can you still reproduce this scanning error after #10054 got committed?

[Frankie Fisher <mythtv.org@…>]

I had a similar issue to this: mythtv wasn't downloading EIT data on UK dvb-t. I examined the dvb_multiplex database and I saw that no networkid was set. I performed several full rescans from myth-setup and nothing changed, even if I deleted all the existing channels first.

I then deleted the EIT source in mythtv-setup, which I noticed emptied the dvb_multiplex database. I then did a new scan from myth-setup: this time a network id was set and lo and behold within minutes the beautiful EIT data was flooding in.

So it seems that doing a new scan might not recreate or update the multiplex data if it already exists so you can get "stuck" with bad multiplex data.

The original EIT source and scans had been done in 0.24 from mythbuntu. The source deletation/recreation and channel scan was done with 0.25 on mythbuntu (MythTV Version : v0.25, MythTV Branch : fixes/0.25, Network Protocol : 72, Library API : 0.25.20120408-1)

[J.Pilk@…]

I've been away and then busy upgrading my production (o.24) box from f15 to f16; apologies for delay.

I can't now reproduce what I described above. Scanning after entering transport parameters from mythtvsetup always failed to achieve lock, and direct entry of netid, transportid didn't change that. Eventually I did a Full Scan with a blank Transports list, deleted unwanted transports, rescanned 'all known transports' with linking enabled, and have a system that seems, after brief testing, to be ok. It's a more cumbersome procedure than I have used before. This is on the current ATrpms build (1 May) of 0.25-fixes for SL6. The dates suggest that #10054 is in there, but I haven't checked the Git numbers.

I tried 'importing an earlier scan' too, but this apparently leaves the Transport table untouched. I can't see a use for it.

See also: ​http://www.gossamer-threads.com/lists/mythtv/users/520285#520285

[stuartm]

Fixed by [a32d5e31a] ?

[J.Pilk@…]

Still hoping for a new build from ATrpms, I'm afraid. Maybe I can do it myself, but don't count on it. The theory sounded plausible, though. Thanks.

[J.Pilk@…]

Now using 0.25.2 built from the tarball using ATrpms default settings. Starting from a blank Transports page in mythtvsetup I was able to get a full set of channels after entering only the frequency of the DVB-T2 mux, QAM-256 and BW 8Mhz, and performing a scan of that transport only with flags set to ignore timeout and search other transports. Terminal output showed that the AUTO BW param is unsupported by this driver (nanostick 290-e under SL6).

This scan still does not update the DB with networkid and transportid of the DVB-T2 transport. If they are not set the recorder status remains 'tuning' and no recording is made. I set them using the mysql commands quoted in the first gossamer-threads reference above. Line-breaks make cutting and pasting from that screen error-prone.

[J.Pilk@…]

I took my laptop running 0.25.2 to a site served by another dvb-t transmitter and used mythtvsetup in several modes to rescan after deleting all channels and transports. I got several 0-byte recordings with the tuner stuck on 'tuning'. All seemed ok after direct insertion of the networkid into the DB using the command linked in Comment 1.

This ticket was opened specifically for dvb-t2 HD, but this time dvb-t SD had the problem too.

v0.25.2-72-g1ecdb90 on SL6 for i686 from ATrpms.

[J.Pilk@…]

On return, a 'linked scan' starting with only HD freq, 8MHz Bw, QAM-256 found everything but didn't enter networkid and transportid for the HD mux. This is what I saw when the ticket was first opened, but then AFAIR I didn't preset the Bw. It differs from my Comment 6.

Two points may be significant:-

My 'home' transmitter is a hub carrying 5 SD and 1 HD muxes. The 'away' was a local relay carrying 2 SD and 1 HD.

Channel numbers were rearranged at source this week.

[Karl Dietz <dekarl@…>]

In 3c3dd7c5372aefe9b597f2fc0b3509a61e4f2e37/mythtv:

Handle EIT events of the active transport without looking at original_network_id or transport_id

Refs #8770 - ONID/TSID presumed missing in the OP's case
Refs #10217 - ONID/TSID did not get populated, should now work without
Fixes #10784

[J.Pilk@…]

Once again I have been away with my laptop, now running 0.26-fixes. The home and away sites are served by different main-chain DVB-T/T2 transmitters in the UK. With a DVB-T/T2 capable tuner, retuning was a few-minute job at each site.

Quit mythbackend. In mythtvsetup, go to Channel editor.

Delete all DVB-T and DVB-T2 channels. Delete all DVB-T and DVB-T2 transports.

Define a new Transport by entering frequency, modulation type, and bandwidth for the DVB-T2 transport. eg for Waltham (serving the East Midlands) 770000000 Hz, QAM 256, 8 MHz. For another transmitter probably only the frequency will need to be changed.

Scan this single transport for "All services" with "Look for linked transports" enabled.

This found around 120 channels. The Transport editor showed five QAM 64 (SD) transports and the single QAM 256 (HD) transport, each with 3 ID numbers.

Accept channels, download icons (or perhaps replace them, having moved them into a different folder before the scan). Quit mythtvsetup. Restart mythbackend...

[J.Pilk@…]

It's a long time since I opened this Ticket. I have re-tuned in places served by different DVB-T transmitters several times since then and am now running 0.28-pre. 'Recently' re-tuning has worked for me without needing direct entry to the DB, although sometimes more than one sequence has seemed necessary. Success probably hinges on the correctness of the DVB tables being broadcast from individual masts, and perhaps on the device driver.

I don't recall seeing recent posts related to this. Maybe it could be closed.

[jasonh@…]

I had the same problem after clearing all the transports and a full rescan. After that the channels tuned but never locked.

It turns out the netid is in the 'channel_scan' table but this value doesn't seem to make it reliably into the 'dtv_multiplex' which had NULL for networkid. Copying the netid data across into the 'dtv_multiplex' makes recordings work again.

This happened on Mythbuntu 14.04.1 and kernels 3.13 and 3.16 with Afatech 9013/9015 and RTL2382U/E4000 tuners.

[Karl Egly]

Reschedule all tickets planned for, but not solved in time for, 0.27.6 to 0.27.7.

[Stuart Auchterlonie]

Closing any remaining open tickets for 0.27

If the issue still persists, feel free to reopen and align to a current release (v29 or master)