Tvheadend

Do you have number 4916 in the service table (probably for DVB-T) in local channel number columns ?

Jaroslav Kysela wrote:

Do you have number 4916 in the service table (probably for DVB-T) in local channel number columns ?

Nope

Jaroslav Kysela wrote:

Please, apply attached patch and show messages (only few) which starts with ':channel:lcn ' string.

Just to repeat what I said over IRC

Tried your patch & I'm not getting any of those messages at all, I'll PM you the complete trace log on IRC (I might have left a password in there!).

So far what I've found out is that when you add additional services to a channel it disappears completely from the list. If you refresh the grid, you end up with a dozen channels of the same name linking to different services all with that mysterious 4916 number!

Weirdest thing I've ever seen (tvh related).

This bug has been bugging me (so to speak) for ages but I never got round to reporting it.

I use DVB-T and DVB-S and there are a lot of channels carried on both so I merged them together but use the bouquet from the DVB-S channels (to align with Sky UK) but when I add a service from DVB-T to the existing DVB-S channel the bug reporting by Mark happens (the channel number randomly changes, usually to something in the 4000's).

Whatever was done in the latest commits (26 August) has caused some ugly stuff to appear in my channels list. After install I simply restarted the tvheadend service and where I had previously nicely ordered channels (starting with 101) I had this (notice how all the ITV regions are now displayed (no idea where those LCN's have come from though - 63 etc. are not valid Sky UK/OpenTV LCN's) and duplicate ITV services on LCN 103 (only the one with the 'Update name' flag unchecked is the original one that should be there).

I've backed out the latest build until someone can take a look at it.

...should add I also had a load of the 4916 channels too...

Jonathan Young: Unable to reproduce here. Upgrade to latest and provide '--trace bouquet,tbl-base' log (use minimal steps until you see the duplicate channels). https://tvheadend.org/projects/tvheadend/wiki/Traces

Thanks, please, try again with latest (same log - I added a code to print more info). The detach for multiple channels was fixed.

Which channels/services are duplicated in this case?

Jaroslav Kysela wrote:

Which channels/services are duplicated in this case?

ITV, ITV + 1, Channel 4, etc.

Here's the JSON output of the channel entries if it's any use.

http://pastebin.com/raw/HEcc2SDd

Jaroslav Kysela wrote:

Jonathan Young: Unable to reproduce here. Upgrade to latest and provide '--trace bouquet,tbl-base' log (use minimal steps until you see the duplicate channels). https://tvheadend.org/projects/tvheadend/wiki/Traces

I actually re-upgraded (if that's even a word ) back to git-master and only the numbers less than 100 re-appeared so I just hid them, problem solved (for me at least) and no pesky 4916 channels.

p.s. how does one edit a post on the issue tracker? I can only add new ones and not edit existing ones, is that a permissions restriction?

Please, apply the patch bellow and provide the new log.

diff --git a/src/bouquet.c b/src/bouquet.c
index d58bb40..ef53263 100644
--- a/src/bouquet.c
+++ b/src/bouquet.c
@@ -300,6 +300,9 @@ bouquet_map_channel(bouquet_t *bq, service_t *t)
       service_get_channel_number(t) <= 0 &&
       bouquet_get_channel_number(bq, t) <= 0)
     return;
+  tvhtrace(LS_BOUQUET, "mapping service nolcn %d lcn %"PRId64" bq lcn %"PRId64,
+           bq->bq_mapnolcn, service_get_channel_number(t) / CHANNEL_SPLIT,
+           bouquet_get_channel_number(bq, t) / CHANNEL_SPLIT);
   if (!bq->bq_mapnoname && noname(service_get_channel_name(t)))
     return;
   if (!bq->bq_mapencrypted && service_is_encrypted(t))

It appears that the services have another LCNs grabbed from different source (opentv?). Because some services have zero LCN in the BSkyB bouquet, this value is used instead.. Probably, I should remove the non-zero LCN check from other sources..

Please, retest with latest...

Jaroslav Kysela wrote:

Please, retest with latest...

Can confirm as fixed, channels are now mapped correctly. Many thanks Jaroslav