Feature #1378

Feature #114: Add the adaptor id to the adaptor name so it easy to separate them.

Some (US) cable providers reporting TSID=0 for multiple muxes

Added by BlueCop - about 11 years ago. Updated almost 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


The problem appears when tvheadend find multiply frequencies with a muxids of 0. It will scan the first channel with muxid 0 correctly but the services found from the next frequency with muxid 0 will overwrite the first frequencies services. I believe it is called of the sid of the service is overwriten for the wrong frequencies. This completely breaks all the frequency scans with mux id 0 because it continually overwrites the first muxid 0 frequency with services it doesn't have.

I have been attempting to configure tvheadend with comcast service in the us.
I am using an hd home run prime with cablecard and 2 x ATI HDTV Wonders tuning using Nextwave NXT200X VSB/QAM firmware for clear qam.

I worked around the problem by stopping tvheadend after it scans a muxid 0 frequency and manually changing the muxid to a non-zero value. This seemed to work and let tvheadend scan the next frequency correctly but then the problem would just repeat. I would have to do it after every frequency with muxid 0. I am sure this is not the a good way to work around it. It worked for scanning a few the few unencrypted channels for the clear qam tuners. I am now running into the same problem setting up the HD homerun prime with the full cablecard lineup. It seems a majority of the frequencies have a zero mux id so it is unpractical to even attempt.

Is there anything else I can provide to help track the bug down?

I have scans with w_scan and hdhomerun scanner which detect all the muxes and services fine. I found the problem by comparing these scans with the services found by tvheadend. I reset the frequencies a couple times just to confirm the behavior and it is consistent.

Thanks for the great backend. It is working great with my XBMC setup with the clearqam tuners. It would be amazing to get my full cable lineup
in XBMC.


logfile.txt (85.4 KB) logfile.txt Gary Anderson, 2014-01-01 22:34
Capture.PNG (34.5 KB) Capture.PNG Gary Anderson, 2014-01-01 22:37
Capture1.PNG (42.1 KB) Capture1.PNG Gary Anderson, 2014-01-01 22:37
Capture2.PNG (22.7 KB) Capture2.PNG Gary Anderson, 2014-01-01 22:43



Updated by Adam Sutton about 11 years ago

  • Status changed from New to Need feedback

I'm not entirely sure I understand the problem? 1) there really shouldn't be any muxes with ID 0 from what I remember, though maybe it is legal (I forget). 2) Since TVH currently (wrongly) identifies muxes by the tuning info (not the ID) this shouldn't really matter (though I've been known to be wrong before).

Can you provide a debug log when you perform this initial setup, so I can get an idea of what is happening?



Updated by BlueCop - about 11 years ago

I attached the debug log from tvheadend after I added my atsc_us_TN_Nashville frequencies and it does a full initial scan.

I also attached scan output from the hdhomerun linux utility as scan.txt . It just is a more complete map of what is actually available. It also shows that almost all frequencies have a TSID/MUXID of 0x0000. the exceptions are 429,435,645,651-687 but they all scan and add service correctly in tvheadend. I can dump some full dvb muxes dump if you want to take a look.

In the initial scan the first zeroed mux id is frequency 753,000 kHz. It adds the 4 services for 753,000 correctly. These 4 services are then corrupted with each new scan of a zeroed id frequency. It will keep updating the services only for 753,000 kHz like every zero id mux exists on that frequency. I monitor the service tab and see the name of the services change and the last number of the play url is also changes.

I think I can confirm it is some problem with the zeroed mux id. If I stop tvheadend after the 753,000 scan and then go to "dvbmuxes" and change the muxid in the 753,000 frequency file to any non-zero value. I then restart tvheadend and it will scan the next zeroed frequency correctly. This worked for using the 4 frequencies I use for my clearqam tuners. the hdhomerun prime with cable card is going to be using dozens of the frequencies with a zero id so it would be much harder to work around.

Thanks for looking into this. Let me know if there is anything else I can provide or do to help.


Updated by BlueCop - about 11 years ago

Sorry the the server is throwing errors when I attempt to attach files.

"Internal error

An error occurred on the page you were trying to access.
If you continue to experience problems please contact your Redmine administrator for assistance.

If you are the Redmine administrator, check your log files for details about the error.

I will try to mirror then and post a link.


Updated by BlueCop - about 11 years ago

here is the initial scan log

this is the hdhomerun utility scan. It shows all the ts ids.


Updated by Ilias Stergiou about 11 years ago

I believe the issue is not related to muxId 0 but in more multiplexes having the same muxId. I have the following problem that explains my statement (I will be brief as I do not want to hijack this issue, let me know if it is related and if you need more information)
I have a DVB-T tuner receiving 6 multiplexes (with muxId 1, 2, 3, 4, 5, 3300) and 2 different multiplexes (with muxId 1, 2) . If I scan the first set I get all channels. If I cleanup and scan the second set it gets all channels. If i scan both of them in any sequence only the first multiplex will give the channels. The transportstreamid in the tvheadend files of the last registered multiplex will get value 65535. If I update that value to a unique value and set initialscan to 1 it will not continue scanning. If you consider the two issues related I will provide more information


Updated by Adam Sutton about 11 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from Intial service scan bug with when multiply muxIDs are 0 to Some (US) cable providers reporting TSID=0 for multiple muxes
  • Status changed from Need feedback to Accepted
  • Assignee set to Adam Sutton

I think that evaluation is indeed correct, and it looks like this has also been reported in the forums,

It sounds to me like the cable provider is doing something it really shouldn't and I don't think this can be considered a bug in TVH. At best we might be able to create some horrible workaround, but I'm not sure how likely it is short term.

But since this is now affecting several users I will give it some thought.


Updated by BlueCop - about 11 years ago

thanks. Sorry I shouldn't have tried to diagnose what the problem actually was because that can be annoying to devs. The TSID value was the only connection I saw.

I can compile and test any patches if a possible solution is devised.

thanks again. I am loving tvheadend.


Updated by Jim Ancona about 11 years ago

FWIW, this post indicates that this is a common issue on US cable systems.


Updated by Adam Sutton about 11 years ago

  • Parent task set to #114

This should possibly be related to #1140, since its HDHR related. However if this is a more general issue with US Cable providers, which seems the suggestion, then we will indeed need to bare this in mind in relation to #1394.



Updated by BlueCop - about 11 years ago

I don't think it is HDHR related. It shows the same problem on my clear qam tuners.


Updated by Gary Anderson almost 11 years ago

FYI, I'm am seeing this same issue with ATSC OTA except here the Mux ID is 1 on 7 different muxes. If I make a custom file for DVB Network by location file with only one of these muxes with an id of 1, it scans fine.

Also, I think I'm seeing the same issue with DVB-S on the AMC21 125W satellite. Not sure tho. I'll need to look into that.

Thanks for your time.


Updated by Gary Anderson almost 11 years ago

Verified this is behaving the same on muxes on AMC21 125W. Appears each mux has an ID of 1. With only one mux it scans fine. So it appears this is happening because of more than one mux with the same ID as another one.

I see that the transportstreamid on any of the muxes after the initial one gets changed to 65535 (0xFFFF)

"quality": 100,
"enabled": 1,
"status": "OK",
"transportstreamid": 65535,
"network": "MONTANA PBS",
"frequency": 12106000,
"initialscan": 0,
"symbol_rate": 2398000,
"fec": "2/3",
"polarisation": "Vertical",
"modulation": "PSK_8",
"delivery_system": "SYS_DVBS2",
"rolloff": "ROLLOFF_35",
"satconf": "1"

Thanks again.


Updated by Adam Sutton almost 10 years ago

  • Status changed from Accepted to Fixed

I "think" this should work with latest code, please try.



Updated by Gary Anderson almost 10 years ago

Thanks for your continued work on this. I'm still seeing this same issue or variant of it. I have attached a logfile and 2 pics of what the GUI shows. Hopefully these will help. Used git clone this morning and it built 3.9.313~gf25d918

Thanks again for your work.


Updated by Gary Anderson almost 10 years ago

Gary Anderson wrote:

Thanks for your continued work on this. I'm still seeing this same issue or variant of it. I have attached a logfile and 2 pics of what the GUI shows. Hopefully these will help. Used git clone this morning and it built 3.9.313~gf25d918

Thanks again for your work.

Forgot this screenshot

Also available in: Atom PDF