Project

General

Profile

Bug #1472

Not auto-detecting muxes

Added by bas t almost 10 years ago. Updated almost 10 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
Start date:
2012-12-25
Due date:
% Done:

0%

Estimated time:
Found in version:
feature/timeshift
Affected Versions:

Description

With current head 67661e7001 (feature/timeshift and deleted line 63 from src/timeshift.c), tvheadend only detects 25 of 32 muxes.
This is while using ziggo netherlands (dvb-c) as a provider

History

#1

Updated by bas t almost 10 years ago

In branch release/3.2 the error exists in one or more commits from dec 19
the head from nov 7 is ok

#2

Updated by bas t almost 10 years ago

Discard the last update. It may be true, but I can't even build release/3.2 from 19 dec.
So no way that I can confirm that release/3.2 from 19 dec suffers from the same bug.

#3

Updated by Adam Sutton almost 10 years ago

  • Status changed from New to Need feedback
  • Affected Versions 3.4 added

Please check 3.2 (use 3.2patch1 tag), my guess is this is related to the ONID changes that are present in master.

Also please don't report non-feature related bugs against feature branches it just muddies the water.

Adam

#4

Updated by bas t almost 10 years ago

Checked that.
And it is indeed not affected.

Bas

#5

Updated by Adam Sutton almost 10 years ago

  • Subject changed from autodetection of muxes to Not auto-detecting muxes
  • Category set to DVB
  • Status changed from Need feedback to Accepted
  • Target version set to 3.4

My guess is this all relates to the ONID stuff I added, which needs re-thinking. However this will not happen until after Andreas has completed his work on re-structuring the DVB code.

For now you could possibly track down the commit made some time ago related to ONID and see if you can remove it.

Adam

#6

Updated by Adam Sutton almost 10 years ago

  • Status changed from Accepted to Need feedback

Please can you try latest, its possible this issue has been resolved.

Adam

#7

Updated by bas t almost 10 years ago

Will do, tomorrow. Backend is busy recording atm.

#8

Updated by bas t almost 10 years ago

Fixed, thanks.

#9

Updated by bas t almost 10 years ago

Though it is probably just cosmetic: thv used to correctly discover the network name of all muxes (and services) and display it in the webui accordingly.
This is no longer the case. Some will get a name, but most won't.

#10

Updated by Adam Sutton almost 10 years ago

I'm still not entirely happy about the missing network names. That really should be working. Can you give some examples of muxes you're not getting names for, and possibly capture some debug output for me.

Compile as:

CFLAGS=-DTDT_TRACE ./configure; make

And log output from console. It'll include some additional debug related to processing the network info tables. I'll double check I've not made a mistake in recent code changes.

Adam

#11

Updated by Adam Sutton almost 10 years ago

Ok, can you also apply this patch:

http://pastebin.com/hPj16dag

I have noticed that its not updating the current mux where applicable, though there was a good reason for this. And also its possibly overwriting network names with empty strings.

However I'm not convinced either of those really explain why its processing many NIT entries and finding no network name. It may be though that's always been the case and that it was from elsewhere that it was getting the names, which is what the debug above is hopefully to check.

Also you mentioned trying 3.2, that would be a useful test. Though the debug won't necessarily help provide any deeper insight at this stage.

Adam

#12

Updated by Adam Sutton almost 10 years ago

  • Status changed from Need feedback to Fixed

I'm marking this as fixed, the problem with missing network names is related to the way TVH handles sectioned NIT. Unfortunately there is no trivial solution to this problem (at least not without a nasty hack). However the problem will almost certainly go away post 3.4 when Andreas' new DVB code is added, since things will be restructured and that will allow us to naturally handle this particular case.

Adam

Also available in: Atom PDF