Gaps in IceTV EPG

prl · Post by **prl** » Tue Sep 12, 2017 18:24

There have been occasional but unresolved problems with gaps showing in the IceTV EPG on Beyonwiz and not on other devices using the new IceTV servers (e.g. here, here and here on the IceTV forum. Those links are relatively recent, but it's a long-standing problem.

With some help from Danial Hall at IceTV, especially in providing dumps of some region's EPGs at times that show the problem, I've found a cause of the problem in the Beyonwiz IceTV plugin.

It boils down to the Birthday Problem (and is similar to the Birthday Attack).

The Beyonwiz EPG is in DVB EIT format, and allows only 16 bits (strictly a subrange of that, from 0x0001-0xfff7) for event ids. IceTV uses much larger event ids, 11 decimal digits. To reduce the range of the IceTV event ids, the Beyonwiz IceTV plugin reduces the event id range with:

eit_id = icetv_id % 0xfff7 + 1

With a 16-bit hash used to reduce the IceTV event ids to EIT event id size, and about 200 events/channel in the EPG (the problem only occurs when the same short event id is used for two different programs on the same channel), there's about a 25% probability that at least two different events will have the same hash, if the hashes are uniformly distributed. If that seems an unreasonably high probability, that's why the Birthday Problem is also called the Birthday Paradox.

When a collision occurs, the event already in the EPG with that EIT event id is removed, and the event that collided is added to the EPG. The EPG allows lookup of an event by its EIT event id, so multiple events with the same EIT event id can't co-exist in the EPG.

The IceTV event ids are not uniformly distributed, they tend to run in sequences, and the simple modulo hash used in the Beyonwiz IceTV plugin tends to preserve those sequences (e.g, a modulo 10 hash of 25, 26, 27 will be 5, 6, 7; even a prime modulo of 11 will preserve the run - 3, 4, 5). That means that the collisions tend to cluster: if one collision occurs in a channel, there's a fairly high probability that a run of several collisions will occur, and that removes a block of entries from the EPG on the Beyonwiz side, even though all the data has been correctly sent and received. However, there seems to be about the same overall probability that collisions occur as in the uniform distribution case.

I have experimented with re-hashing the IceTV event id to remove runs (e.g. by using the IceTV event id's MD5 hash) before reducing it by the modulo hash. That stops blocks of missing entries in the EPG from happening, but it doesn't significantly change the total number of collisions and missing entries in the EPG. They're just scattered over more channels and are less obtrusive.

The problem can be fixed by avoiding assigning colliding hashes. That can be done either on the IceTV server side by avoiding assigning ids that hash to the same Beyonwiz hash as some other id in the current EPG, or on the Beyonwiz side by detecting and re-hashing collisions.

Neither option seems attractive. An IceTV server fix would complicate the assignment of event ids from the simple and natural scheme currently used. A Beyonwiz-side fix would require a non-volatile lookup table over current IceTV ids that map to the assigned Beyonwiz ids. That table would be in the order of ~10000 entries.

Changing the length of the EIT event id in he Beyonwiz EPG doesn't appeal, because it would have a lot of side-effects.

I'm open to suggestions.

IanSav · Post by **IanSav** » Tue Sep 12, 2017 20:38

Hi Prl,

What is the scale of overlapped IDs?

I was wondering if you can slightly reduce the hashed ID table/pool size so as to create space for a separate "clash" buffer of spare IDs that you could assign when the normal algorithm results in an ID clash. I appreciate that reducing the hash table size will increase the number of clashes but this may be a workable if there aren't too many overlapped IDs.

Regards,
Ian.

prl · Post by **prl** » Tue Sep 12, 2017 21:37

The problem with any hash reassignment is in storing the state somewhere.

peteru · Post by **peteru** » Tue Sep 12, 2017 23:46

This is a problem that I highlighted to IceTV way back in 2006 (or was it 2005?). The underlying problem is that their content database was designed without any regard to DVB standards. I tried to address the issue with DVB interoperability when I designed the PIMP protocol for IceTV, however the content backend was not fixed at that point in time. The new IceTV protocol has gone the wrong way and DVB interoperability is a series of incomplete hacks, rather than a core feature of the protocol.

If you want to use the IceTV ID to generate EIT ID, then there's not much that can be done, short of having a database that stores a mapping between IceTV ids and the DVB EIT addressing scheme. The other option is to use some other data to generate the EIT ID.

Changes to the enigma2 EPG database format are not a feasible option.

By far the best approach is for IceTV to understand the EIT event addressing mechanism and either use it to generate their IDs or even better, provide EIT event ids as part of the data feed.

Altimes · Post by **Altimes** » Wed Sep 13, 2017 10:01

Knowing *absolutely* nothing of creating plugins....

Is the problem the storage of the state for the plugin or the size of the stored state ?

If the memory footprint of the stored state is the concern (the reference to ~10000 ids), could a bit map be used to persist/check for a clash?

If we look at the eit_id as 16 bits, that gives us a 65K bit bitmap, which looks to be about 8K bytes.

Doesn't address the issue of dealing with the clash, just detecting it.

Just a thought.

Alan.

prl · Post by **prl** » Wed Sep 13, 2017 11:45

IanSav wrote: ↑
Tue Sep 12, 2017 20:38
...
What is the scale of overlapped IDs?

Any scheme needs to cope with the worst case. The absolute worst case (which is extremely unlikely, given the way that IceTV ids are generated) is that all IceTV ids hash to the same hash slot. A more likely worst case is that there are two runs of IceTV ids separated by the modulus, in which case half of the hashes would collide. There are typically about 200 EPG entries per channel, and equal hashes in different channels don't collide.

It the sample data that Daniel sent me, the worst two channels for collisions had 19 and 13 collisions respectively. They correspond to runs separated by a gap that approximately equals the modulus.

IanSav wrote: ↑
Tue Sep 12, 2017 20:38
I was wondering if you can slightly reduce the hashed ID table/pool size so as to create space for a separate "clash" buffer of spare IDs that you could assign when the normal algorithm results in an ID clash. I appreciate that reducing the hash table size will increase the number of clashes but this may be a workable if there aren't too many overlapped IDs.
...

I can't see a reason to do that rather than using a normal open addressing/closed hash algorithm. Unfortunately, because the current hash modulus is not prime, quadratic probing and double hashing (which are good for cases where there are runs in the original hashes) won't always probe all slots before returning to the original hash. That would leave linear probing using an interval that's relatively prime to the hash (0xFFF7 (65527) which has factors 7, 11, 23, 37). I was planning to use open addressing with linear probing if the problem was to be attacked on the Beyonwiz end.

I'd be open to changing the hash modulus to 0xFFF1 (65521), the largest prime less than the current hash, but changing the hash function would change all the EIT ids in the EPG, and they'd no longer match existing timers (and because of runs, the timer EIT ids would often match the wrong EPG entry, and would mark the wrong entry in the EPG screens as being recorded.

However, neither open addressing or your suggested "reserve pool" can work without a map of all IceTV ids to the hashed ids (as I and peteru have posted).

That's because both schemes need to be able to compare the actual keys (the IceTV ids) to know whether two keys that hash to the same value are the same full key or not.

Consider an implementation of either scheme without that map. An update for an EPG entry is received from IceTV, and when its IceTV id is hashed to an EIT id using the primary hash function (icetv_id mod 0xFFF7 + 1) that hash value is found in the EPG. Now, how do you tell whether the update entry with that hashed id is a new EPG entry or an update for the existing entry with that hashed EIT id? Even if it's a replacement for the existing entry, there's no guarantee that any of the fields will be the same as the existing entry. If it's for a new entry, there's no guarantee that any of the fields except, perhaps, the start & end times) will be different from the existing entries (news and current affairs programs often have the same subtitle and description texts).

prl · Post by **prl** » Wed Sep 13, 2017 12:00

peteru wrote: ↑
Tue Sep 12, 2017 23:46
...
If you want to use the IceTV ID to generate EIT ID, then there's not much that can be done, short of having a database that stores a mapping between IceTV ids and the DVB EIT addressing scheme. The other option is to use some other data to generate the EIT ID.

I think that for efficient removal of unused hash entries, two maps are needed, icetv_id ->eit_id and eit_id->icetv_id. The latter would be needed to efficiently remove map entries when the EPG does its periodical scan to remove old EPG entries. If there isn't a map eit_id->icetv_id, then each removal of an old EPG entry is O(N) on the size of the channel data.

peteru wrote: ↑
Tue Sep 12, 2017 23:46
Changes to the enigma2 EPG database format are not a feasible option.

I completely agree.

peteru wrote: ↑
Tue Sep 12, 2017 23:46
By far the best approach is for IceTV to understand the EIT event addressing mechanism and either use it to generate their IDs or even better, provide EIT event ids as part of the data feed.

At the moment, the IceTV event ids are the primary key in a database table. I'm not sure whether that table is over "all events" or just the visible 7 days. The IceTV event ids themselves are unique over all events.

Daniel seems reluctant to change those ids, and I can understand why. I hadn't thought of an additional eit_id in the IceTV data, which could be generated per channel and be implemented as a per-channel database counter incremented per new event in the channel, and which is reduced by (counter mod 0xFFF7 + 1) for the eit_id.

I can run that suggestion past Daniel, if he's not following this discussion (I let him know about it).

prl · Post by **prl** » Wed Sep 13, 2017 12:20

Altimes wrote: ↑
Wed Sep 13, 2017 10:01
Knowing *absolutely* nothing of creating plugins....

That's OK. The fact that IceTV is implemented on the Beyonwiz as a plugin isn't relevant to the problem

Altimes wrote: ↑
Wed Sep 13, 2017 10:01
Is the problem the storage of the state for the plugin or the size of the stored state ?

For me, the problem of the non-volatile state is its existence, and especially ensuring that it always matches what's in the stored EPG data, and especially in case of crashes and unexpected powerdowns (e.g. mains power outage).

I think that problem can be solved by putting the extra data in the EPG code rather than in the plugin, so that the additional data is always saved when the EPG is saved to file.

Altimes wrote: ↑
Wed Sep 13, 2017 10:01
If the memory footprint of the stored state is the concern (the reference to ~10000 ids), could a bit map be used to persist/check for a clash?

The memory footprint isn't the main issue for me. There would be one entry in the hash allocation table for each EPG event entry, but each EPG event entry would be much bigger than its hash allocation table entry.

Altimes wrote: ↑
Wed Sep 13, 2017 10:01
If we look at the eit_id as 16 bits, that gives us a 65K bit bitmap, which looks to be about 8K bytes.

EIT ids are assigned per channel and only need be unique within that channel. There are up to about 40 channels in a region's EPG data. That would mean around 40 such bitmaps, or about 320kB. That's about the same order of magnitude as the 10000 table entries (spread over ~40 lookup tables).

Altimes wrote: ↑
Wed Sep 13, 2017 10:01
Doesn't address the issue of dealing with the clash, just detecting it.

It doesn't even actually do that. Similarly to my question in response to IanSav's post above, say an update arrives for an EPG entry. Its IceTV id is hashed and looked up in the bitmap, and the bit is set to indicate that that hash has been used. But is the update's IceTV id for an event that's already in the EPG (i.e. it's an update for an existing EPG entry) and therefore isn't a collision, or is it a new EPG entry whose IceTV id happens to has to the same value as an existing entry, in which case it is a collision? The bitmap can't answer that question.

And, of course, detection isn't enough. The collision needs to be dealt with, otherwise we're back to the current situation.

prl · Post by **prl** » Thu Sep 14, 2017 16:09

Bug #603: Gaps in IceTV EPG.

simoncasey · Post by **simoncasey** » Fri Sep 15, 2017 00:05

Assuming you know what is causing it, I assume there's no more need for me to post when there are gaps.

I do wonder if there is something non random about it, as it almost always occurs over the weekend.

prl · Post by **prl** » Fri Sep 15, 2017 10:59

simoncasey wrote: ↑
Fri Sep 15, 2017 00:05
...
I do wonder if there is something non random about it, as it almost always occurs over the weekend.

It depends on what you mean by "random". The runs of missing shows are caused by the generation of a run of new event entries in the EPG whose IceTV show ids are different by about 0xFFF7 from a run of existing events in the same channel. That's perfectly deterministic, but it depends on exactly how new entries are added to the IceTV database, and that may have some random, or at least not easily determined, factors.

prl · Post by **prl** » Fri Sep 15, 2017 11:02

I am working with Daniel Hall on a fix for this bug. Daniel has mentioned it on the IceTV forum (I was waiting for him to mention it publicly before posting about it here).

The currently proposed fix will need changes at both the IceTV server end and in the Beyonwiz plugin, but the major part of the work will be done by IceTV (probably by Daniel).

The fix for this bug should also fix the problem that sometimes short shows set by IceTV receive the wrong event id.

IanSav · Post by **IanSav** » Fri Sep 15, 2017 12:14

Hi Prl,

Will IceTV be allowing for or adding EIT IDs to the data? It would be good if the work is to provide a permanent fix rather than a work around.

Regards,
Ian.

prl · Post by **prl** » Fri Sep 15, 2017 14:23

IanSav wrote: ↑
Fri Sep 15, 2017 12:14
...
Will IceTV be allowing for or adding EIT IDs to the data?
...

That's the current intention, but there isn't an implementation yet. That's why most of the implementation effort is at the server end.

simoncasey · Post by **simoncasey** » Fri Sep 15, 2017 14:42

prl wrote: ↑
Fri Sep 15, 2017 10:59

simoncasey wrote: ↑
Fri Sep 15, 2017 00:05
...
I do wonder if there is something non random about it, as it almost always occurs over the weekend.

It depends on what you mean by "random". The runs of missing shows are caused by the generation of a run of new event entries in the EPG whose IceTV show ids are different by about 0xFFF7 from a run of existing events in the same channel. That's perfectly deterministic, but it depends on exactly how new entries are added to the IceTV database, and that may have some random, or at least not easily determined, factors.

My thoughts were that if it isn't random and is therefore predictable, it may be possible for icetv to have some procedural method to either stop it happening or to identify the problem and resend the data in a different format.

peteru · Post by **peteru** » Fri Sep 15, 2017 15:04

The problem is well understood and has been on the radar for at least a decade now. The solution isn't all that difficult, but it needs to be implemented at the IceTV end.

danielicetv · Post by **danielicetv** » Fri Sep 15, 2017 16:48

While this has been a known it has not been an issue until the T series Beyonwiz's so there has not been a need to modify our entire system for it.

This problem does not exist with any of the other PVR manufacturer's that we have worked with (not even when the integration was done for the DP series of Beyonwiz PVR's).

As this is an issue with the way the current T series works we will put a workaround in place on our server to solve it.

prl · Post by **prl** » Fri Nov 03, 2017 10:36

I have given what I hope is the final alpha of the Beyonwiz side of the fix for this to Daniel Hall @ IceTV. I've also installed the fix on our in-use T4.

If our testing doesn't turn up any problems, I'll make it available for some user alpha testing before I submit it to the repository.

As a bonus it also implements:
Request #23: Fill in timer name from EPG

and fixes
Bug #174: Graphical EPG highlights active timers, but does not offer to allow you to change them
for once-off timers, and for the first run of repeat timers. The repeated timer issue, while related, needs a fix in a different place.

The implementation of #23 fixes some of #174, and having a usable event id in the IceTV timer request helps with it, too.

prl · Post by **prl** » Sun Nov 05, 2017 10:36

Here's an alpha patch of the fix for Bug #603: Gaps in IceTV EPG. It will also implement Request #23: Fill in timer name from EPG and fixes some instances that cause Bug #174: Graphical EPG highlights active timers, but does not offer to allow you to change them.

The patch has been tested with firmware version 20171029beta. It will probably work well with any beta from 20170828.

To apply the patches, download the linked .ZIP file, and extract it. It will create a new directory/folder called missingicetv4-installer, which contains two files, installer.sh and uninstaller.sh.

Make sure you uninstall before doing an upgrade. Use the detailed uninstall instructions below. Don't run the installer if you've already installed & don't run the uninstaller if you've already uninstalled.

Uninstall any previous version of this patch using the instructions below before installing a new version.

Copy the two files somewhere convenient on a T series box (like /home/root), then log into the box using telnet or ssh, change directory to the place you put the installer.sh/uninstaller.sh files. If you put the files in /home/root you'll be in the right place as soon as you log in.

Unfortunately, the installation and uninstall for this patch is a little complicated, but failing to follow it could result in unexpected behaviour, including the failure of AutoTimer-generated timers to be updated.

To install the patches:

Disable IceTV (from live TV, MENU>IceTV>Disable IceTV).
If you use AutoTimer timers:
1. Disable AutoTimer auto poll: from live TV, MENU>AutoTimer, MENU>Setup>Poll automatically.
2. Restart the GUI (MENU>Power>Restart GUI from live TV). This ensures that auto polling is disabled (yes, I know).
3. In the timer list (TIMER from live TV), delete all timers generated by AutoTimer (round green icon with double-headed white arrow).
In the Beyonwiz's command-line interface run: sh installer.sh
Restart the GUI (from live TV, MENU>Power>Restart GUI).
Enable IceTV (MENU>IceTV>Enable IceTV).
Re-load IceTV data (from live TV, MENU>IceTV>Fetch EPG and update timers now).
When that completes, examine the IceTV log (from live TV, MENU>IceTV>Show log). There should be a "Update timer details from EPG" message with the timer's name for each IceTV timer that's in the IceTV Web page as a Series Recording or Single Recording (i.e, sent to the PVR, not just queued).
If you use AutoTimer timers:
1. Enable AutoTimer auto poll: from live TV, MENU>AutoTimer, MENU>Setup>Poll automatically.
2. When you return back to the AutoTimer list from its Setup screen, press GREEN Save. This will re-scan the AutoTimers and re-generate the timers controlled by AutoTimer.
3. Restart the GUI (MENU>Power>Restart GUI from live TV). This ensures that auto polling is properly re-enabled (yes, I know).
Check that the timers are all present in the timer list and that they are visible in the EPG.

To uninstall the patches, repeat the above procedure, but run

sh uninstaller.sh

instead of

sh installer.sh

in step 3 above.

You can check whether the patches are installed by logging in and running this on the box:

find /usr/lib/enigma2 /usr/bin -name \*.bak

It should print nothing if the patch isn't installed, and it should print

/usr/lib/enigma2/python/RecordTimer.pyo.bak
/usr/lib/enigma2/python/Screens/TimerEntry.pyo.bak
/usr/lib/enigma2/python/timer.pyo.bak
/usr/lib/enigma2/python/Plugins/SystemPlugins/IceTV/API.pyo.bak
/usr/lib/enigma2/python/Plugins/SystemPlugins/IceTV/plugin.pyo.bak

if the patch is installed.

Comments welcome!

Paul_oz53 · Post by **Paul_oz53** » Sun Nov 05, 2017 12:34

Clear enough prl but one question if I may: between steps 5&6 do I need to resend all timers?
Paul

prl · Post by **prl** » Sun Nov 05, 2017 13:25

Paul_oz53 wrote: ↑
Sun Nov 05, 2017 12:34
Clear enough prl but one question if I may: between steps 5&6 do I need to resend all timers?
...

I don't think so, but I'll check.

Paul_oz53 · Post by **Paul_oz53** » Sun Nov 05, 2017 14:31

prl wrote: ↑
Sun Nov 05, 2017 13:25

Paul_oz53 wrote: ↑
Sun Nov 05, 2017 12:34
Clear enough prl but one question if I may: between steps 5&6 do I need to resend all timers?
...
I don't think so, but I'll check.

Not a big issue by any means - we're recording at the moment so I'll find out soon enough.

prl · Post by **prl** » Sun Nov 05, 2017 14:38

Paul_oz53 wrote: ↑
Sun Nov 05, 2017 14:31

prl wrote: ↑
Sun Nov 05, 2017 13:25

Paul_oz53 wrote: ↑
Sun Nov 05, 2017 12:34
Clear enough prl but one question if I may: between steps 5&6 do I need to resend all timers?
...
I don't think so, but I'll check.
Not a big issue by any means - we're recording at the moment so I'll find out soon enough.

It's not necessary. All the timers appear to be sent anyway. If you want to do it, then it shouldn't cause any problems, though.

The reason for all the complication is that the code new uses a different event id in the timers and in the EPG, and the timers need to be updated to have the event ids that match the new EPG event ids..

Paul_oz53 · Post by **Paul_oz53** » Sun Nov 05, 2017 16:04

Confirmed. It reloaded all the timers without a resend. All looks good Peter.

prl · Post by **prl** » Sun Nov 05, 2017 16:36

Paul_oz53 wrote: ↑
Sun Nov 05, 2017 16:04
Confirmed. It reloaded all the timers without a resend. All looks good Peter.

Thanks.

Paul_oz53 · Post by **Paul_oz53** » Tue Nov 07, 2017 00:45

Hi prl.

Whilst pondering whether to turn show EIT Now/Next back on, I noticed that none of the programs in the EPG showed the [R] flag. I attach screenshots of the T4 (with patch) and T3 (without the patch) for illustration.

Checking the Ice TV website, I discovered the "Custom repeat flag" was no longer ticked. It had been previously set to "end of the title" field on all four recorders, including the T4. Only the T4 had changed. I re-enabled it and resent all timers. I then disabled and re-enabled the plugin, then fetched the EPG. The flags have been restored, as per the T3.

Only a minor glitch - none of the IceTV timers were affected. It may have affected an autotimer but I only have one set and that program (Car Crash Global) was not in the affected time span. Wasn't expecting this change to the IceTV settings so curious if it is an effect of the patch or is it a random event?

Regarding Now/Next - what is the current recommended setting to get accurate flags for the start and end of recorded events?

Cheers,
Paul

peteru · Post by **peteru** » Tue Nov 07, 2017 01:23

AFAIK there is no API that the IceTV plugin could use to make changes to the REPEAT flag setting at IceTV.

It must have come about via some other change.

Paul_oz53 · Post by **Paul_oz53** » Tue Nov 07, 2017 03:43

Thanks peteru - that's as I would have expected.

I did re-enter my IceTV credentials when I did the USB update a few days back so it must be associated with that but not noticed sooner.

prl · Post by **prl** » Tue Nov 07, 2017 09:06

That shouldn't change the setting of repeat flagging in the EPG either. It never has for me.

If you don't go to shutdown, changes in that setting will only affect new EPG data sent to the PVR. The change may not have happened earlier and went unnoticed for a few days.

prl · Post by **prl** » Tue Nov 07, 2017 10:44

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 00:45
...
Regarding Now/Next - what is the current recommended setting to get accurate flags for the start and end of recorded events?
...

There aren't any settings that I know of that affect the now/next transition marking in recordings. In particular they aren't affected by the setting of MENU>Setup>TV>EPG settings>Show EIT now/next in infobar.

If you're having specific problems with the markings, I suggest you start a new topic in T2 / T3 / T4 General Topics or in Bug Reporting and Feature Requests. The code for those markings should be unaffected the changes made to fix the gaps in the IceTV EPG and it doesn't involve IceTV data or the IceTV plugin.

Note that for channels that show ads or promos between shows, the marks can't indicate both accurate starts and ends of the programs, because the only data they have to work on the the transition of the "now" program start time, which happens just once, usually at the start of the program material of the next program.

Sometimes there are no transitions, especially when two episodes of the same series are run together. For example, when 7TWO shows two Murdoch Mysteries episodes back-to-back, there's no now/next start time transition between the episodes, because Seven schedules them as a single program block. If you record them using IceTV, IceTV has them as separate episodes, so the recording of the first episode has no end mark and the recording of the second episode has no start mark.

Paul_oz53 · Post by **Paul_oz53** » Tue Nov 07, 2017 11:17

Thanks prl. I don't have any specific issue to report.
Start marks are generally accurate now on stuff I record. The missing marks in double episodes are as you describe.

I seem to recall having read something to suggest that turning Now/Next on could cause a clash with the guide. Seems I am mistaken.

The patch has had no gaps in the guide at all.
Paul.

prl · Post by **prl** » Tue Nov 07, 2017 12:56

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 11:17
...
I seem to recall having read something to suggest that turning Now/Next on could cause a clash with the guide. Seems I am mistaken.
...

There are some issues with enabling Show EIT now/next in infobar if IceTV is enabled (enabling IceTV disables Show EIT now/next by default), but I can't remember exactly what they are. You will get different titles sometimes if you use EIT now/next and IceTV EPG. In particular, if you use EIT now/next you won't see IceTV repeat markup in the titles in the infobar. However, if you use Show EIT now/next, you should get more accurate switches of the now/next information in the infobar.

prl · Post by **prl** » Tue Nov 07, 2017 13:01

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 11:17
... The patch has had no gaps in the guide at all. ...

Good to hear, but "absence of evidence is not evidence of absence", unfortunately. I have had one instance while testing where I know that the old code had a gap and the new code didn't, and that's really the only way to see whether the code is doing what it should. Unless you have a box running the old code and one running the new code, it's cumbersome to switch between them.

MrQuade · Post by **MrQuade** » Tue Nov 07, 2017 13:02

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 11:17
I seem to recall having read something to suggest that turning Now/Next on could cause a clash with the guide. Seems I am mistaken.

The only EIT now/next issue I am aware of, are that EPG "similar" searches on the current event will not work properly since the EPG entries will not match the now/next entry.

The other problem that I recently encountered was having IceTV enabled, but also accidentally having EIT EPG (not now/next) enabled at the same time. Every time you zap, the Ice EPG data gets overwritten by the EIT EPG data (until Ice refreshes again). You end up losing event data for events that are currently showing and past events.

Grumpy_Geoff · Post by **Grumpy_Geoff** » Tue Nov 07, 2017 13:04

prl wrote: ↑
Tue Nov 07, 2017 12:56

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 11:17
...
I seem to recall having read something to suggest that turning Now/Next on could cause a clash with the guide. Seems I am mistaken.
...

There are some issues with enabling Show EIT now/next in infobar if IceTV is enabled (enabling IceTV disables Show EIT now/next by default), but I can't remember exactly what they are. ...

Likely this -
A slight broadcast transmission gitch will result in a new tiny timeshift buffer created and named as per the EIT event and then seconds later another one created and named as per the EPG.
Yes?

prl · Post by **prl** » Tue Nov 07, 2017 13:07

Grumpy_Geoff wrote: ↑
Tue Nov 07, 2017 13:04
...
Likely this -
A slight broadcast transmission gitch will result in a new tiny timeshift buffer created and named as per the EIT event and then seconds later another one created and named as per the EPG.
Yes?

Yes. I was in the middle of posting that, prompted by what MrQuade had posted, when I saw that you'd remembered what it was

Paul_oz53 · Post by **Paul_oz53** » Tue Nov 07, 2017 13:32

prl wrote: ↑
Tue Nov 07, 2017 13:01
... Unless you have a box running the old code and one running the new code, it's cumbersome to switch between them.

Aah, but I do! Still, gaps are not an everyday event. As you observed, not conclusive evidence that the fix is perfect.

Paul_oz53 · Post by **Paul_oz53** » Tue Nov 07, 2017 13:53

I don't use the EPG search function so I wouldn't notice the effect on searches. Similarly, the timeshift glitch is not a problem since upgrading the aerial.

So the tradeoff comes down to an accurate epg with repeat flag vs better time marks. No real reason to change the default values IMO.

Thanks all, Paul

prl · Post by **prl** » Tue Nov 07, 2017 15:27

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 13:53
... Similarly, the timeshift glitch is not a problem since upgrading the aerial. ...

The glitching that Grumpy_Geoff and I were talking about has nothing to do with reception quality. The problems with timeshift recordings and start/end marks that were caused by reception dropouts will be helped by better reception, but have also been addressed by firmware improvements.

Paul_oz53 wrote: ↑
Tue Nov 07, 2017 13:53
So the tradeoff comes down to an accurate epg with repeat flag vs better time marks. No real reason to change the default values IMO.
...

There are no settings tradeoffs regarding start/end marks. They are, AFIK, unaffected by any user settings.

Paul_oz53 · Post by **Paul_oz53** » Tue Nov 07, 2017 18:25

OK. I'm guilty of conflating unrelated issues. It's actually the effect on the guide and not the start /end marks that I am meant to avoid by not changing the defaults.

I don't think we see the specific glitch you've mentioned but I suspect that is a function of how we use our machines. A glitch just now doesn't appear to have had any effect on the timeshift files.

Paul

Paul_oz53 · Post by **Paul_oz53** » Thu Nov 09, 2017 00:23

Sorry to say, I have crashed the T4 twice tonight, attempting to record HDMI IN via pressing RED and attempting to set an instant recording. Both crash logs attached. Was in LiveTV immediately prior. A recording was also running on 9HD at the same time. T4 was set to HDMI IN.

I'll be away from home today so can't do much until late tonight.

peteru · Post by **peteru** » Thu Nov 09, 2017 00:33

Does the crash happen only with IceTV enabled, but not when IceTV is disabled?

If this is independent of IceTV, then this is not the correct place to raise the issue.

peteru · Post by **peteru** » Thu Nov 09, 2017 00:36

Oh, never mind me...

I just looked at the standard Beyonwiz enigma2 code and there is nothing that seems to correspond to that crash - it must be something new in the IceTV related patch.

Paul_oz53 · Post by **Paul_oz53** » Thu Nov 09, 2017 00:43

peteru wrote: ↑
Thu Nov 09, 2017 00:36
Oh, never mind me...

I just looked at the standard Beyonwiz enigma2 code and there is nothing that seems to correspond to that crash - it must be something new in the IceTV related patch.

No worries Peter. Yes, I reported here because I'm testing the alpha patch. Ice TV is enabled.

prl · Post by **prl** » Thu Nov 09, 2017 09:39

The bug is specific to the IceTV gaps fix and to creating a recording on the Beyonwiz side for a service that has no EPG (like HDMI IN).

prl · Post by **prl** » Thu Nov 09, 2017 09:50

The fix should be straight-forward. I'll try to make a fixed version available today.

prl · Post by **prl** » Thu Nov 09, 2017 16:25

Paul_oz53 wrote: ↑
Thu Nov 09, 2017 00:23
Sorry to say, I have crashed the T4 twice tonight, attempting to record HDMI IN via pressing RED and attempting to set an instant recording. Both crash logs attached. Was in LiveTV immediately prior. A recording was also running on 9HD at the same time. T4 was set to HDMI IN.

I'll be away from home today so can't do much until late tonight.

I've posted a fix for this problem (and another minor problem associated with timers that don't have an event id) as a new patch missingicetv4-installer.zip in its original post in the topic, replacing the older one, missingicetv3-installer.zip.

To switch to the new version, you can either do the full uninstall/install detailed in that post, or this abbreviated install/uninstall, that doesn't run the unpatched firmware:

If you have any AutoTimers:
1. Disable AutoTimer updates (disable MENU>AutoTimer, MENU>Setup>Poll automatically).
2. Restart the GUI (long-POWER>Restart GUI) or reboot (long-POWER>Reboot).
Disable IceTV (MENU>IceTV>Disable IceTV).
Run the uninstaller script from the original patch ZIP file that was used to install it
sh uninstaller.sh
Do not restart the GUI or reboot.
Unpack the attached installer/uninstaller and copy the installer.sh and uninstaller.sh files in the new ZIP file to the PVR.
Run the new installer
sh installer.sh
on the PVR.
Restart the GUI (long-POWER>Restart GUI) or reboot (long-POWER>Reboot).
Enable IceTV (MENU>IceTV>Enable IceTV).
Update IceTV EPG and timers (MENU>IceTV>Fetch EPG and update timers now.
If you have any AutoTimers:
1. Enable AutoTimer updates (enable MENU>AutoTimer, MENU>Setup>Poll automatically).
2. Restart the GUI (long-POWER>Restart GUI) or reboot (long-POWER>Reboot).
The IceTV plugin version (heading in MENU>IceTV) should now be 20171109 and should be ready to test.

Paul_oz53 · Post by **Paul_oz53** » Thu Nov 09, 2017 17:21

OK. Should be able to do it late tonight.
Paul
Update: Done and all working ok. HDMI IN instant recording is fully functional once more.

prl · Post by **prl** » Sun Nov 12, 2017 09:30

Paul_oz53 wrote: ↑
Thu Nov 09, 2017 17:21
OK. Should be able to do it late tonight.
Paul
Update: Done and all working ok. HDMI IN instant recording is fully functional once more.

Sorry, I missed the update. Thanks.

I'll submit the changes today.

Thanks for your help.

About the Forum

Join us