Missing DVB-T channels on KIII Pro

Some addendum. While digging in the system log files I found many errors like these ones:

2018-06-15 11:45:30.678 [ ERROR] linuxdvb: Availink avl6862 #0 : DVB-T #0 - failed to config dmx for pid 1151 [e=Operation not permitted]

Jun 15 11:52:18 CoreELEC tvheadend[2939]: linuxdvb: Availink avl6862 #0 : DVB-T #0 - failed to config dmx for pid 850 [e=Operation not permitted]

Jun 15 11:52:18 CoreELEC kernel: DMX: too many channels

May be related to the problems I found?

Again, most important for proper mux scanning is ‘Delivery System’ - DVB-T or DVB-T2. Also for avl6862 driver limit Maximum PIDs to 26 in TV adapter settings. To force immediate scanning change in Edit Mux -> Scan status-> ACTIVE. Poll TIMEOUT is only informative message about long lasting scan, you can see there was another 3.5 sec attempt to scan data.

DVB-T2 isn’t operational yet in Italy, we’re still on DVB-T on all channels. BTW, I’ll try.

Sometimes Thvheadend simply hangs. No matter if I set PEND or ACTIVE it simply does nothing and it stays IDLE. I need to restart the service to make it work again. On occasions I have to power off the KIII completely to make things work again.

Tried right now with max pids set to 26 and using DVB-T2, both by living everything to auto, setting to QAM/64, QAM/256, and playing a bit also with the other parameters. It always fails. Always the same log:

2018-06-16 08:44:33.918 mpegts: 514MHz in DVB-T Network - tuning on Availink avl6862 #0 : DVB-T #0
2018-06-16 08:44:33.919 subscription: 0015: “epggrab” unsubscribing
2018-06-16 08:44:33.919 subscription: 0017: “scan” subscribing to mux “514MHz”, weight: 6, adapter: “Availink avl6862 #0 : DVB-T #0”, network: “DVB-T Network”, service: “Raw PID Subscription”
2018-06-16 08:44:38.918 mpegts: 514MHz in DVB-T Network - scan no data, failed
2018-06-16 08:44:38.918 subscription: 0017: “scan” unsubscribing

It shows the typical behaviour of channels with no signal. May be that it isn’t really tuning into 514 MHz? I.E. Tvheadhend ask for 514 MHz but beacause of something the tuner uses a different frequency? It’s weird that no matter what I set nothing ever changes, it makes me think I’m looking in the wrong direction.

If you are still on DVB-T you can use cheap dvb-t usb stick (10€).

Well, I set DVB-T2 as “Delivery system” on the Tvheadend interface. It looks like it ignores the setting. Tried again right now.

Buying an external stick isn’t an option. I want a self contained box. If there’s no way to make CoreELEC work I’ll stick to the Android software and wait until some new CoreELEC version. I already bothered you too much. Thank you very much for all your efforts.

Just FYI, tried the latest 8.90.5, and the problem persists.

Bye,

Denis Sbragion

As you say sounds like a driver issue but I guess it could also be some issue with the backend or combination of those. If you feel adventurous enough you could try a newer tvheadend version by running it in a docker container or possibly you could try some other backend.

I also have a KIII Pro but I’m in a cable household. As somebody mentioned earlier the signal strength you get via the tuner is quite poor.I had similar issues as you, were I could not find one mux but when I plugged in the antenna cable into my external USB tuner in the same system, the mux was found. I went ahead and bought the shortest possible antenna cable which made the mux appear but the picture was constantly freezing. I then bought a second cable as short as the first one but which was suppose to be of much better quality and now it works okay. I do get pixelation on occasion but it doesn’t bother me that much.

It works like a charm with the Android software, so it’s difficult to believe that it’s an hardware problem. Every symptom here points towards a software problem.

BTW, just to be sure, I moved the KIII to a different plug, with a different cable. Same exact behaviour.

Unfortunately I don’t know what else I can do to diagnose the source of the problem. I even tried to take a look at the driver code, but I know too little about this kind of hardware to be of any help. I once fixed a soundcard driver, but apart from the ubiquitos I2C protocol this is quite a different beast.

Some update on this issue. After moving the KIII to its final place, near my main TV set, I soon discovered that when the KIII was turned on random muxes started to disappear on the TV, though not the same ones that were missing on the KIII itself. This happened even if the KIII was completely disconnected from the TV. It was enough for it to be in the neighborhood of the TV to cause problems.

Clearly the KIII emits massive amounts of RF interference. Don’t know if it’s bad design or it’s just my own sample that has some problems. BTW I opened the KIII and carefully shielded the plastic box by using some EMI copper tape. After that I tried again with CoreElec, and, guess what? Now it works with CoreElec too.

What’s weird is that the RF emitted is strong enough to cause problems to other devices and probably to get back to the KIII tuner through the antenna cable, but cause no troubles to the KIII tuner itself when sealed inside its own shielded box. May be this is because internally the tuner part is heavily shielded from the rest, don’t know.

Don’t know also why it was working with its own software. May be that the Android OS and software cause a different kind of load on the system and so a different kind of RF interference. Really weird. BTW I hope this information might be of help to others having this kind of troubles.

Bye, and thanks for all the kind help,

Denis Sbragion

1 Like

Hello Denis, seems my KIII pro is suffering the same issue as yours, I’m using it in Italy too.
Stock Android works fine in DVB-T scanning and streaming, while CoreElec 8.95.6 finds no channels in TvHeadend (nor VDR-PVR backend nor w_scan).
Instead, Availink avl6862 driver is loaded with no issues by the CoreElec kernel.
Please would you share some more detail or photo about how you shielded your device?
Thanks in advance.
Nicola

Some update here:

This device is just a complete waste of time.

Having a good shielded antenna cable with shielded connectors helps a LOT. The important bits for a stable DVB reception are Signal Strengh and SNR.

These are the ones I’m using. Never had a recepection or scanning problem since I switched to them.

https://www.televes.com/me/elbowed-proeasyf-iec-connector-with-class-a-shielded.html

Believe me, I tried everything. Cable isn’t the issue here. Every ohter DVB device in my home works prerfectly. Until I switch the KIII on near to one of them, even if it isn’t connected to anyhing. This device spits out massive amounts of RF interference, and no cable can deal with it.

Having made the same experience with DVB-T2, I still wonder why there are less or no problems with Android. This suggests that something is handled differently in CoreELEC (driver, CPU frequency, etc.).

Does your box emit the same amount of RF interference, when you boot Android?

Yes. No matter what the operating system as soon as I switch it on some channels on the TV stop working, even before the boot procedure completes.

I can only suggest that yours is a dud box since there are many users of this box, and other boxes using the same tuner chips, which are having no issues - including myself. There is no technical solution on the software side to overcome a dud box.

Shoog

May be, but it looks like I’m not the only one. Apart from this thread I found few other messages on the Internet complaining about the same problem. At least the quality control should be improved. For sure I’m not going to buy another sample just to check it out.

Hi!
I bought also a KIII Pro last month, I have the same problem on KI PRO but good news for me
Since 8.99.x update of CE, TVheadend could scan successfully the 618Mhz muxes On KI PRO & KIII Pro ! :slight_smile: Thanks a lot

Just for information, few weeks ago I discovered that the interference issue changes depending on the video card resolution and refresh rate settings. Depending on the settings the MUXes affected change. In my situation I got something usable by setting the video card at 1920x1080@50Hz, interlaced. The problem isn’t completely gone but at least most of the important MUXes work now.

This might explain the differences between Android and CoreELEC and also the different problems experienced by different peoples. Dependgin on the OS and the monitor attached to the video card different video settings might be automatically selected, causing different interfence patterns.

Hope it helps.