Messages

I have had a look through this one, and it looks like there was a bug that was causing commercial detection to still trigger when it was disabled. This was also causing existing commercial detection files to not be removed (so for older recordings ads were still being skipped during playback)

An update is going out this afternoon that will fix this, so the post processor command can be left as is.

It looks like the update has resolved this issue. Thanks!

Thanks for the confirmation about the update.

An update is going out this afternoon that will fix this, so the post processor command can be left as is.

Did this update go out recently? I thought I saw my IceBox BYO processing an image on booting up today.

...I'll take a look at clearing out muxes and services in a test VM installation and see if resetting the offset carries through on a re-scan.

Clearing out muxes and services, resetting EIT offset to Local (server) time and Force Scan makes no difference to the behaviour. It is also manifest in Timer rules set in the Web UI, so looks like a TVHeadend rather than LibreELEC/Kodi issue.

Other than that I am out of ideas.

I am pleased someone else managed to verify the timer issue.

And no-one has found a solution, yet!

Are you using Timer Rule or timer rule (guide based)

Timer rule. It looks to me like there are similar issues with guide based timer rules. Maybe I'm doing something wrong.

Anyway, EIT offset in the Network config is currently set at UTC (i.e. UTC+0). Setting to UTC-10 or local (server) time makes no difference to the behaviour. It's been pointed out in the TVHeadend thread I referenced that it might be due the current setting (UTC+0) being set already in muxes and services. When I get some time I'll take a look at clearing out muxes and services in a test VM installation and see if resetting the offset carries through on a re-scan.

Is it all channels? or just some channels?

A reboot appear to have resolved the EPG one hour late issue, but not the timer rule issue which is still setting timers 10 hours later than they should be.

Is it all channels? or just some channels?

Without looking at all 25 channels I have enabled, I can confirm the one hour later issue is apparent on all primary SD channels as of now i.e. ABC1, SBS, 10, Prime7 and 9SD. A quick look at other channels suggests all.

It looks like my IceBox EPG is still showing program times one hour later than they should be. It's possible that a timer rule issue posted at https://forum.icetv.com.au/iceforum/index.php?topic=7932.0 is related.

There may be some clues as to what's happening in what is posted at https://tvheadend.org/d/5914-wrong-time-in-epg/3. Playing around with the EIT offset setting in Network config in the Web UI doesn't have any effect that I can see, as reported in this post, which also suggested no change in behaviour when running new network scan.

Since I got it working, it seems I have the same issue as before with the timers being wonky. Has something about the timers changed?

I don't know if anything changed, as I haven't used timer rules on IceBox before, but it looks to me like they are not working as expected now.

If I set a "Recording:Timer rule" for a block of time for every day on a channel, only one timer turns up in the timer list, and it is not the same time period as set in the rule. It looks like it is set for 10 hours later than what I set in the rule.

This discrepancy is reflected in the TVHeadend config UI and I can't see any obvious reason for it.

One for the technical gurus I think.

Interestingly something changed overnight. Timers have now been created in IceBox according to what is displayed on the My Week web page, but the IceBox EPG still shows those programs one hour later.

Looks like a daylight saving thing.

The one hour out could also be a symptom of daylight savings, there could be some weirdness until Sunday for the days after Sunday, but scheduled recordings will happen correctly as the guide data is updated.

That could account for it, although the T2 was able to self-correct. I'll just wait until after the weekend to see if everything lines up again on Icebox.

The ongoing issue with gaps in the EPG persists, particularly noticeable in my case with the Prime network, is probably being addressed, but doesn't appear to be fully fixed yet.

Today, with EPG unpopulated for many channels for Tuesday 9 April from midnight Monday 8 April was fixed by a reboot, but the EPG, at least on one channel, is one hour out.

I saw this as well on a Beyonwiz T2, but the issue was resolved by tuning to one of the affected channels, forcing an EPG update that fixed the time discrepancy.

Encouraged by this I went back to the IceBox, tuned to one of the affected channels, waited 5 minutes, then re-checked the EPG. It was still one hour out.

A repeated reboot of IceBox did not resolve the issue.

So with IceBox, a timer set for a program on one of the affected channels has not set, because the timer shown on the IceBox web TV Guide page is one hour earlier than the time slot for the program registered in the IceBox EPG.

Is it really important to you have "LCN's" available? Especially as they are not used for channel changing or really anything apart from channel ordering (if you go through additional hoops). Channel ordering can also be achieved by simply sorting by name as well.

Are we talking about Channel number as defined in the TVHeadend config as "The position the channel will appear on your EPG"? It looks like channel numbers there approximate to LCNs (in many cases) but many channels I need to see in Kodi are numbered 0. I don't know why that is, or if it's because I've played around renumbering channels in the past.

In any case I value the reconfigurable channel numbers in TVHeadend  because I like to see a particular channel order, not only in the EPG, but in the channel lineup in Kodi, by selecting channel numbers from back end in the Kodi PVR config. I wouldn't be totally dismayed if reconfigurable channel numbers were replaced by LCNs, I still think of TV channels that way, but I rather prefer things the way they are now.

Thanks for the update.