Messages

This is a feature/limitation of TVHeadend.

When creating a timer on a Topfield PVR, the firmware would look ahead at the existing timers to predict conflicts and prevent the user from proceeding when a conflict is detected.  However, there was also a bug in this process that could miss timers that had been modified in a certain manner.  Topfield PVRs only had 2 physical tuners and therefore could only record from 2 networks simultaneously.

With TVH, it accepts all recording scheduling requests and only identifies and 'resolves' conflicts at recording time using a set of priorities.  TVH can also address all the tuners that the Linux OS can see, up to about 16, if I recall correctly.

I have written a Python script that can detect these conflicts and one day I plan to turn this into a Kodi addon that can alert the user as a new recording is scheduled that will result int a conflict.

The script takes into account the number of tuners, the muxes required, scheduled recordings and future 'timer' records (In TVH, 'timers' and 'scheduled recordings' are different).  The script can not take into account 'AutoRec' recordings until a match has been found and it becomes a scheduled recording.

Is it possible to to run IceBox & Kodi in Ubuntu ?

No, not as it currently stands.

IceBox is based on LibreELEC.  LibreELEC is a minimal Linux distribution that has Kodi pre-installed and an easily installable TVHeadEnd module.

The IceBox bundles all of this, plus their own Kodi add-on that interfaces between the ICE TV servers and TVHeadEnd.

So, you can install Kodi and TVHEadend on Ubuntu, however, the ICE TV add-on expects to see a LibreELEC installation with certain pre-installed files in certain locations and will not run unmodified on a standard Ubuntu platform.

The Topfield had 5 physical slots (one for time shift), the Beyonwiz T2 has 6 and the U4 10

I always saw this as a limitation imposed by the resources of the PVR platform in question.  Each stream to be recorded will require some CPU ticks, RAM for caching, file descriptors, IO to the HDD, etc.  The PVR will also have to run the GUI for the user and whatever else is required.

On Topfield, you can see this resource shortage when the native ICE TV module is active.  Both CPU cores shoot up to 100% and the GUI lags.

I think that this is to do with the version of SMB that LibreELEC is using and Win-11 is expecting.

There is probably a registry hack or something to allow Win-11 to access older SMB shares.

You can browse to TVH on your IceBox and change the recording location there.

http://[IceBox IP]:9981

Go into Configuration -> Recording -> (Default Profile) and change the "Storage path" under the "Filesystem Settings" to the location of your external HDD.

If you don't see that option, go into Config->General and set your "Default view level" to 'Expert".

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.