Tvheadend

Ok, I follow these step

(1) Set up Sat conf for for lnb's with switchports 0 to 3
(2) Add DVB network by location for Hotbird, Astra 1, Astra 2, Astra 3
(3) It scans the muxes and brings back over 7000 channels, which is a lot more than is expected
(4) When I look at the services there seems to be a lot of duplication, but only on channels on Astra 1 (19.2).
(5) So I remove all muxes associated with Astra1 - this should remove all associated services
(6) However, when I go back to services a lot of these duplicate channels for Astra1 remain, even tho the muxes have been deleted.
(7) It causes problems on the xbmc frontend, as channels that where working before now do not open at all.
(8) When I scan just one lnb, (say 28.2), everything works fine
(9) Ive been using TVH for quite some time, and this is a new behaviour.

Hope this helps, if you need logs, channel listings etc, if you give me some direction, I can provide that

Im using TVH 3.2.18 on openelec and have also tried the latest pull from git on my debian server.

Thanks

If you can mail me (or attach here) your .hts folder that would be useful, just so I can see what problems it might contain.

It would be useful to have a copy from after you've setup all 4 networks (with the 7k services etc..) and then another copy showing the state after you removed the various muxes etc..

Adam

Hi,

Ive emailed you a zip of the settings folder.

Thanks

OK,

Looks like that config is OK, given what you've described. The muxes and services have all been correctly removed. You now have some channels that are not backed by any services, but this (as previously explained) is expected behaviour.

Though I accept it might be confusing and an option to "purge" such things could be (very) useful. But that in itself does not constitute a bug, its a new feature. This is covered by #112, which I've updated to expand the request.

When you're scan is complete I will see what that provides with regards to the duplicated services etc...

Adam

Hi,

Ive reset everything and the problem persists. This was 100% not happening before. Almost every channel is displaying 4 times in the services list. And other channels which where there before are missing. I can let you log in remotely to my TVH interface so you can have a look and supply my config folder again, but I dont think this is expected behaviour.

Cheers,

Dave

Just another quick update:

Nov 23 18:24:48 subscription: "192.168.0.104 [ user | XBMC Media Center ]" subscribing on "Really", weight: 150, adapter: "Technisat SkyStar USB HD (DVB-S/S2)", network: "ASTRA 1", mux: "ASTRA 1: 11,817,000 kHz Vertical (ASTRA 28.2)", provider: "BSkyB", service: "Really", quality: 100
Nov 23 18:24:48 eit: begin processing

Im trying to watch "Really" on ASTRA, but the adapter is trying to open it on "ASTRA 1" which is the wrong network. ASTRA 1 is for a different Sat conf, namely 19.2, as opposed to 28.2. This is happening to a lot of the channels and therefore wont open, as TV headend is essentially looking for a different channel on a different satellite.

Hmm, yeah something is a bit odd there. Its definitely got all the right info for the service, freq/pol etc... and it even looks like its picked the correct satconf. However I'm not sure where its getting that ASTRA 1 from.

It might be that the config you sent me is slightly out of date compared to this reason run (as I note that you've changed the satconf names, I think).

Maybe you could re-send your config directory so I can take another look. I go agree that something weird is happening, just very difficult to tell what.

Adam

Hi,

Ive resent. Thanks,

Dave

I am experiencing the same problem (git c1cb274 28/11/2012).

For instance, the channel RTL8 (Astra 1M 12343.50H) at first works \but after
a while produces no picture.

I have noticed something strange: there exists as file with "sat_conf_3" in the name
in a directory with "satconf_1" in the name:
./dvbtransports/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend12344000_H_satconf_1/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend12343500_H_satconf_3_07f3

I have 4 satconfs which for some reason are numbered 1 3 4 5 in
.hts/tvheadend/tvheadend/dvbsatconf/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend
The one for ASTRA1 (port 1) is
.hts/tvheadend/tvheadend/dvbsatconf/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend/3

/1 is for ASTRA2 (port 0)

Perhaps the port number is confused with the sat_config number?

I am also seeing a bug which is supposed to be fixed:
many muxes appear without an associated satellite config.

Deep Thought wrote:

I am experiencing the same problem (git c1cb274 28/11/2012).

For instance, the channel RTL8 (Astra 1M 12343.50H) at first works \but after
a while produces no picture.

I have noticed something strange: there exists as file with "sat_conf_3" in the name
in a directory with "satconf_1" in the name:
./dvbtransports/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend12344000_H_satconf_1/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend12343500_H_satconf_3_07f3

I have 4 satconfs which for some reason are numbered 1 3 4 5 in
.hts/tvheadend/tvheadend/dvbsatconf/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend
The one for ASTRA1 (port 1) is
.hts/tvheadend/tvheadend/dvbsatconf/_dev_dvb_adapter0_TurboSight_TBS_6981_DVBS_S2_frontend/3

/1 is for ASTRA2 (port 0)

Perhaps the port number is confused with the sat_config number?

I am also seeing a bug which is supposed to be fixed:
many muxes appear without an associated satellite config.

try to delete muxes without satconf, turn on audetect and on each satconf create /if there isnt any present/ at least one working mux /see kingofsat for reference/. when mannualy creating mux use proper satconf. recreated muxes should be with correct satconf.
dont know if troubles with missed satconf are related to change in code, but at the moment a will recomend u backup whole hts directory when everything is ok.

Is this still happening, sorry I've not had time to follow up on things recently.

Adam

Yes,

Ive been using a single Sat for the last month or so, but ive been running the latest build every few days for testing on a separate machine and it still appears to be happening.

Thanks

Sorry guys I know I've been ignoring this, but I'm trying to bottom out all the scanning related issues and I have a suspicion this might be related to #1586.

Can you check this patch (http://pastebin.com/Sf7YFSvQ), some inspiration taken from deepthoughts.

Note: this patch only applies to latest git master, not 3.2. I'd appreciate if you could test against that as I'm trying to stabilise this for release shortly.

Adam

I need to get some feedback on the state of this or I will have to close it. I believe the problem should be fixed by my commit but I need validation (Note: that commit is now in master).

Ta
Adam

Sorry if I'm being thick, but I can't find that commit in master??

Can't really provide any feedback if it's good as I seem to have multiple issues going on, reliable configuration of my multiswitch being one. Still working on hunting them down one by one.

I had the same problem with Astra1 and I have just compiled and installed 3.5.23~g4724e01 and I could tell that the problem is still there.
If I can help anyway...