Messages

I made this diagram about a year ago.  It attempts to explain the various places that padding can be added and their related priorities.
https://forum.icetv.com.au/iceforum/index.php?topic=7572.0

Unfortunately it may not go out via AusPost until Monday.

Plugging in a spare USB keyboard into the IceBox could be a workaround until the new RCU arrives.

@Delta Mike Charlie (DMC), you have experimented with using Topfield RCU with LibreELEC, can you change the channel by entering the LCN?

Yes.  I use a different after-market RCU on my IceBox (not the Topfield) and using the number pad whilst watching live TV changes channel to the selected number.

Also, if you want to get LCNs:  After the Ice Wizard runs, just manually change to one channel on each network missing LCNs.  The LCNs should be populated and you can go on with your viewing.

and are just added on for Australia

As far as I can tell, UK, Europe & NZ all have LCNs too.

[Proposed Solution:]

Perhaps I should try that out on my test LE system, see if there is a pattern to missing LCNs with .5 vs .625.

With a self-compiled bleeding-edge TVH on Ubuntu using the TVH Wizard, .5 vs .625 did not make a difference to the LCN.  All 'services' ended up with an LCN, however, not all 'channels' got an LCN.

I thought that this was too convenient, so I did it all again, this time keeping a keen eye on the services.  As it turned out, the 'services' for the 3 commercial networks all lacked LCNs at the start.  However, as the OTA EPG grabber ran on each mux, I could see the LCNs being learned in real time as the service list was updated.  Once the LCNs on the services were updated, they were also automagically updated on the channels as well.

The LCNs are not part of the standard service table and are instead provided by descriptor 0x83.

https://www.freetv.com.au/wp-content/uploads/2019/08/OP-41-LCN-Descriptor-Issue-8-July-2016.pdf

I need to dig a lot deeper into the TVH code, but I think that TVH is not waiting long enough during the tuning process to see if any LCN descriptors turn up.  Whilst TVH is doing the OTA EPG grab, it sees the LCN descriptors and updates the services/channels accordingly.

Because ICETV does not use the OTA EPG grabber, I wondered if simply the act of tuning to one of the channels on the mux would be enough for TVH to learn the LCNs.

I reset my system once more, disabled the OTA EPG grabber and then ran another scan.  This time, I was still missing LCNs, but on different muxes.  Once the scan was complete, using my browser, I tried to view one of the channels that lacked an LCN and then bingo!  The LCNs for that entire mux turned up in my services list.

Proposed Solution:  For every mux that has channels without an LCN, tune to a single channel on that mux for a few seconds.

If I recall correctly, with the TRF 2100 there was a problem that it did not pick up one of the LCNs in Hobart because it was .625 rather than .5. Had to update the firmware for it. It was a secondary transmitter (if I recall correctly). At one time there was two or three secondary transmitters for Hobart ABC. Mount Wellington the main one, with I think Sorrel, New Norfolk and cannot remember where else. Is it possible that  at .625 is used for secondary transmitters.

That sounds interesting.  Perhaps I should try that out on my test LE system, see if there is a pattern to missing LCNs with .5 vs .625.

This was because the normal (included in the base tvheadend install) scanning file for "Australia/General" has two versions for each mux, one at '.5' and one at '.625' as Ian mentioned. In the IceBox we have a custom mux list for scanning within TVHeadEnd that only has the entries at '.5' as after checking it looks like all of Australia uses that format.

Yes, that is what I found.  Apparently the scan files are out of date.  The TVH team have been trying to contact the owner of the source scan file repository to address the issue, however, I am not certain what the outcome was.

On my Topfield, all tuned channels are .5 except RF CH 8 which is .625.

Where I am I am fortunate that I only get one "duplicate" mux for C31 (channel 44); but in my case they are both correctly identified.

I found that I could get duplicate services/channels when the scan file contained two muxes that technically had different frequencies, but the frequencies were close enough together for the adapter to be able to successfully tune to both muxes.

If I recall correctly, on a vanilla TVH, if I selected 'Australia/Sydney' I got only one, but if I selected 'Australia/General' (or similar), I ended up with duplicates.

All,
I tried the Force Scan option and after a quick flash of a message (too quick to read) nothing happened.
It was all over in less than 1/2 a second.
I would have expected an extended delay while all the frequencies were scanned. So what it scans is outside my limited knowledge.

The remapping of the services was similar.  I tried both the Selected service and Map all to no avail.

You could try going into Config->DVB Inputs->Muxes and changing the 'Scan Status' to "ACTIVE' and then saving the mux one by one for the muxes in your area.  See if any new services turn up or missing LCNs appear.

I suspect the Channel scan with the update may need a slightly longer sample period for each frequency to be more reliable at capturing the all the channels and the related channel numbers. i.e. it would take longer, but return more data.

I recently wrote an addon for LibreELEC that touches on scanning channels.

During the channel scanning process, I found that two possible errors could occur.  The most common error was no LCNs, but also less frequently, no service name.

My solution was to not take the TVH scan return status at face value.  If the scan 'passed', I still looked to see if there were any LCNs found on that mux, if not, I would rescan until I either got LCNs or exceeded and arbitrary number of scan attempts.

From what I can see from the DVB specs, the LCNs are broadcast separately to the central channel definitions.  Perhaps the TVH scanning process is not waiting long enough and may need some further investigation.

So, straight to batteries in it, and replace with fresh ones. Back working again.

Did you try temporarily reinstalling the old batteries to see if the problem returned?

I wonder if it is related to the SMB version.

In order to get my EPG working properly, I ended up having to do a soft reset and in the process destroying all of my custom configuration.

For the next iteration of the upgrade process, I'd recommend deleting the TVH and Kodi EPG databases and let them get repopulated from scratch.

My after-market RCU has stopped working.

I had the after-market RCU connected via a USB hub and before the update it was working correctly.
If I plug the RCU directly into a USB port on the IceBox, it works, it is only through the USB hub that it does not work.  There is a USB keyboard connected to the hub and that still works fine.  Perhaps the underlying LibreELEC has altered its drivers somehow.

I just noticed a lot of missing LCNs.  ABC, 10 & 7.

In the TVH WebUI, I went to the muxes and changed their scan status to 'Active' and the 7 & 10 LCNs showed up in services the first time, however, ABC turned up after a good dozen tries.

It also looks like my AutoRecs may have been deleted.