Project

General

Profile

Bug #5666

Bouquet interfering with Schedules Direct internal grabber.

Added by A L about 2 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
EPG - Grabbers
Target version:
-
Start date:
2019-06-24
Due date:
% Done:

0%

Estimated time:
Found in version:
4.2
Affected Versions:

Description

I am using the London HD Sky bouquet to keep all the channels on my system up-to-date.

I also have a Schedules Direct account, importing the EPG data with the tv_grab_az_sdjson_sqlite grabber.

Most of the Schedules Direct EPG channels are named exactly as that received by the bouquet and they automatically match up.

The rest will not automatically match and I have to manually assign them - for example, BBCONE and BBC One would have to be matched by hand.

I have set my system to use both the Schedules Direct grabber and the OTA OpenTV Sky scanner, with the SD grabber having a higher priority.

The effect of this is that all channels that are available on Schedules Direct get the best data and then any other channels have to make do with the EPG data provided by Sky.

The issue starts when I restart my system or when I have install an update - all the channels that I have manually assigned get deleted and re-added.

The problem with this is that I have to go back in manually assign the SD EPG data, again, as the newly added channel fall back to using OpenTV data.

The other downside of this is that if you have a timer set on a channel that gets removed and re-added, that timer gets permanently removed too.

I have tried the following, but nothing seems to permanently solve this:

1. Tried renaming the channel on TVH to match that of the Schedules Direct.
2. Adding the Schedules Direct channel to one of the alias names listed in TVHeadend.
3. Removing the automatically assign EPG check box.

It seems that if the bouquet senses that anything at all has changed to the channel, it deletes it and re-adds it.

History

#1

Updated by Jaroslav Kysela about 2 years ago

The question is another. How can we identify the identical channel. DVB uses unique 16-bit value (SID - service identification) which we use as the unique identifier, but if broadcaster changes this value, tvh handles the service as new.

Perhaps, there is something in the DVB specification or the private broadcaster extension for the SI (system information) tables which can identify the service migration. But someone must read the specification, analyze the MPEG-TS stream and add the proper code to tvheadend to get this working properly.

#2

Updated by Pablo R. about 2 years ago

Jaroslav Kysela wrote:

[...] But someone must read the specification, analyze the MPEG-TS stream and add the proper code to tvheadend to get this working properly.

It would be very good, in many occasions I also have several duplicated services - some work others not.

#3

Updated by A L about 2 years ago

Wow - the solution seems more involved than I was expecting. There is clearly so much more going on behind the scenes than I had appreciated.

I have searched the forums and I cannot find anyone with anything like the problem that I have (which is surprising). I was wondering whether it could have been the case that I missed something easy that would sort things out.

#4

Updated by saen acro about 2 years ago

Jaroslav Kysela wrote:

The question is another. How can we identify the identical channel. DVB uses unique 16-bit value (SID - service identification) which we use as the unique identifier, but if broadcaster changes this value, tvh handles the service as new.

From my experience
Operator have dual source input if one gone second is main but idiots with configured backup set different parameters to same services.

https://tvheadend.org/issues/5423

#5

Updated by A L about 2 years ago

Hi Saen - I think you are on to something with this.

I checked the services tab and noted that for BBC One HD (for example), there were four separate services:

https://en.kingofsat.net/find.php?question=bbc+one+hd

There were two identical entries for SID 6941 and two entries for 6961 (so four in total).

One one of the 6941 services was actually linked as a channel.

I disabled the other three services and (fingers crossed), things seem to be working correctly - though, I shall need to do some more testing to be sure.

1. Is this what you were talking about in your last post and
2. Why are there multiple services being picked up with the same SID?

#6

Updated by A L almost 2 years ago

This issue still exists - would upgrading to 4.3 get round the issue?

#7

Updated by Flole Systems almost 2 years ago

Nobody worked on it so it's no surprise it still exists. Upgrading could solve it, you'll definitely be running a more mature codebase then.

#8

Updated by A L almost 2 years ago

Thank you - I think I am going to have take the plunge and upgrade, then.

Also available in: Atom PDF