Tvheadend

PMT pids relate to services, not muxes. The change added here is really only related to MUX data, adding of ONID/TSID and also auto mux discovery. I have realised there could be some issues with this, unfortunately there are equally many issues with the old approach.

What exactly are you not getting, not functional doesn't really help as scanning works fine for myself and others. Are you not getting muxes added, not getting mux info (ONID/TSID), not getting services?

Adam

Not getting any services.

Delete a known working MUX. Existing services on the MUX get deleted.

Add the Mux back in manually...

dvb: "/dev/dvb/adapter0" tuning via s2api to "3,933,000 kHz Vertical (Default (Port 0, Universal LNB))" (1217000, 9300000 Baud, 9/10, SYS_DVBS, QPSK) for Initial autoscan

Jan 31 17:04:59 dvb: "3,933,000 kHz Vertical (Default (Port 0, Universa" on adapter "STV0900 frontend", status changed to OK

It doesn't find any services. No services are added. Same result with every frequency on the satellite so far. Previously it would populate the services into the services tab almost instantly. Turned skip initial scan back off, idle scan back on and it starts running through MUXes but never sees a service. Restart and still nada.

Not sure if it's not getting scanned but kern log does shows it tunes and locks. Frontend status changes to OK, Network ID and MUX ID do not show.

I found one MUX on the satellite that did scan in services. So it will work, just not for a lot MUXes.

Only issue I had with the previous method was not scanning when a duplicate TSID was used for a different MUX on the same satellite. I noticed in scan-S2 I think it was that they did a check on the frequency and if the TSID was duplicate but frequency was different they would let it go.

Dunno... in a perfect world MUXes would be configured to spec. I see almost none that actually are. Makes life difficult.

I'm seeing the same issue when scanning ATSC muxes. Worked fine before the commits today (except scanning atsc muxes with the same TSID). When tuning each mux it shows signal and BER info but no services are ever found. If there's any thing more you need from me let me know.

Thanks for you work and time.

I'd already realised that the idealised changes will not work on ATSC, where no NIT exists (or at least isn't required to exist). I'm going to back out some of the changes, but hopefully in a way that will continue to solve the original problem (of some muxes being given the wrong IDs - due to the way the tables were being used).

Keep an eye on master, as I'll try and fix things in the coming days, just need to find some time.

Adam

Yes, I see what you are going for. Unfortunately even with DVB-S the NIT data is commonly inacurate, incomplete or missing entirely. Using NIT data to find services will give pretty wildly mixed results. Using it to autodetect muxes can create a huge mess. Any thing that tries to go beyond manual mux creation is going to have some kind of issue. Once the muxes are created and services scanned in there needs to be a way to turn off any automatic updating of services. On some satellites automatic mux creation and automatic updating of services may work, although it sounds like there are issues if you say some muxes are being given the wrong IDs. In general though, I would say that allowing automatic mux creatation and service updates will eventually cause problems.

Ron,

Just to clarify, NIT is not used for service discovery (though it is possible), SDT is used for service discovery. At this stage there is no way to disable the continuous updating of services (never has been), and mux updating happens continually (but this doesn't change the tuning info).

The wrong IDs is not an issue in the network, its a problem with the way TVH deals with the incoming data. The only place where you can absolutely garauntee (assuming ofc the data is right in the first place) to have a coherent set of tuning info + identifiers (ONID/TSID) is from the NIT. Previously TVH would process the ONID/TSID from other tables based on the fact that it was for the currently tuned mux and would update accordingly. The problem with this is that some adapters appear to be buffering data and so what TVH sees as for the current mux is actually for the previous one. Now we can put traps in to handle this, hopefully, but this was a first pass naive approach using NIT. Clearly its not good enough and we need a hybrid solution.

The main issue here is that if the mux ID is wrong, then so will the service processing and lots of knock on things. Since that is tied based on TSID/ONID. Again you can get some info based on "current mux" but once again it suffers the same buffering issues.

I think its fair to say that the success of the automated stuff greatly depends on the network you're using. I've never created a mux manually (except occasionally for testing) since I've used TVH, I've always used auto-detection. TVH has never had a mechanism for manually adding services, its always been an automatic process by parsing SDT and other tables.

The problem I'm finding is that due to often general disregard for following the specs and equal parts my lack of knowledge/experience, you end up having to have a whole mess of crap just to keep things running smoothly in all situations.

Do bare with us though and feel free to contribute any suggestions, they're always appreciated.

Adam

It behaved similar to a duplicate TSID. The mux was created but then silently ignored. Only the mux with accurate NIT data was scanned.

tvheaded has the best services discovery of any media app or server I've ever used. It will create services for muxes that contain neither SDT or NIT as long as PMT pids are in the PAT. Channel names need to by typed in manually, but once you do that the service can be mapped.

I have successfully created services for channels that are not in the SDT, NIT or PAT by directly editing files in ~/.hts but it's a task. Currently that isn't necessary for any of the channels I watch.

There are chipset issues as well. Older cards would just fail to tune if given a bogus frequency. My new one will tune anything even remotely close to the frequency provided and no other params are necessary. No system, SR required. If you let it go on automatic you'll be sorry. I only add muxes manually. Idle scan always disabled, skip initial scan on, auto Mux off. It's generally OK until one day it decides to auto update your services using data from the wrong frequency. That is the only thing I can't disable at present. The skip initial scan option has helped a great deal since I move my dish with a motor to different satellites. Every network is on a different satellite.

Your task is a tricky one. I hope you succeed. In general tvheadend is the simplest best performing system I've ever seen. Your efforts are much appreciated.

Pulled the git today and I can confirm that it is creating services again. Has worked on all the muxes I've added so far. Only issue I've noticed is that xbmc is having trouble changing channels. Changing channels within a Mux works OK normally, but if the card needs to retune to change into a channel on a different mux I need to first stop play back and then switch to the channel or I get the "No Input Detected". I assume that is just a matter of the pvr addon catching up with your new code in tvheadend.

I think the no input may have related to a commit I accidentally pushed to master than included some prototype stuff (related to the other scanning changes), I've reverted that commit and my own system is behaving better now.

Adam

Yes, it's good now.