yes you are right it is with this patched "TurnOffTuningChannelCache.zip"
and with "tuning channel cache"Turn off, it works
and with "tuning channel cache"Turn off, it works
[confirm] Wrong detection of FTA disables watching channel (3 Viewers)
- Thread starter georgius
- Start date
ofc. this patch will work.
although it has a performance penalty.
in order to have the fastest channel change possible we need to avoid DB look ups
it would be better if the card alloc. cache would listen for changed scrambled/fta events.
at some point we dynamically update the DB with a new FTA value for the tuningdetail (right ?).
couldn't we just notify the card alloc. cache here, to remove the value from cache if :
cachedFTA != newFTA
/gibman
although it has a performance penalty.
in order to have the fastest channel change possible we need to avoid DB look ups
it would be better if the card alloc. cache would listen for changed scrambled/fta events.
at some point we dynamically update the DB with a new FTA value for the tuningdetail (right ?).
couldn't we just notify the card alloc. cache here, to remove the value from cache if :
cachedFTA != newFTA
/gibman
ok, in tvdvbchannel we have:
protected virtual bool SendPmtToCam(out bool updatePids, out int waitInterval)
the only place I can see where tuningdetails are persisted is in:
PersistPMTtoDataBase method.
this takes care of initial changes to the FTA flag.
then we have live changes to the FTA flag, this might not be handled yet, as MM states.
so it should be possible to add a notification to card alloc. cache class atleast for the initial detection of FTA.
/gibman
protected virtual bool SendPmtToCam(out bool updatePids, out int waitInterval)
Code:
// update any service scrambled / unscambled changes
if (_channelInfo.scrambled == channel.FreeToAir)
{
channel.FreeToAir = !_channelInfo.scrambled;
Log.Info("subch:{0} SendPMT: Channel FTA information changed to {1} according to CAIDs in PMT.",
_subChannelId, channel.FreeToAir);
}the only place I can see where tuningdetails are persisted is in:
PersistPMTtoDataBase method.
this takes care of initial changes to the FTA flag.
then we have live changes to the FTA flag, this might not be handled yet, as MM states.
so it should be possible to add a notification to card alloc. cache class atleast for the initial detection of FTA.
/gibman
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Hi guys
To be honest I don't know if I like either approach and I think there is more than one problem that needs to be solved.
I definitely would like to avoid having another setting in TV Server configuration - no disrespect to you georgius, but this solution feels like it is only a work-around for one of the problems.
Equally, although in this case the problem has been exposed by incorrect detection of FTA/encrypted status in the TV library, there are real channels that are sometimes free and sometimes encrypted. The only way to determine the *real* current state is to allow a tuner to try to tune the channel. In other words, I don't think the service should be making decisions about whether a tuner is able to tune such channels because the DB is not guaranteed to be correct. Ensuring that the cache is synchronised will help, but if the DB is wrong in the first place then there is still a problem.
So there are 3 problems:
1. Incorrect FTA/encrypted detection in the library.
2. Cache de-synchronisation with the detected FTA/encrypted status.
3. TV service making tuner allocation decisions with incorrect information.
My suggestion (purely from an "idealist" perspective) would be...
Change "FreeToAir" property to have 3 possible states: [always] free, [always] encrypted, mixed
The TV Service:
- logic for tuner selection and decrypt limit should be fine as is for free and encrypted channels
- should assume a mixed channel is encrypted for the purpose of decrypt limit logic (prefer to tune with a tuner that has CA)
- if there are no tuners with CA available then try with other tuners (if available)
- if other tuners are not available, we could optionally try to tune with a tuner that has CA (to handle the case when the channel is currently FTA)
In the TV Library:
- respect the always encrypted and always FTA settings - do *not* try to auto-detect encrypted status (this allows users to work around the existing faults in the detection of encrypted/FTA state and bad providers who do not follow DVB guidelines)
- for mixed channels, attempt to detect current status (ideally we would replace CA descriptor based detection with TS header scrambled bit detection or even ES level checking)
- implement decrypt limit enforcement so that if a mixed channel is encrypted and the tuner has no CA capability or would exceed the decrypt limit then throw an exception back to the service
In TsWriter:
- extend the TS header scrambled bit checking to be able to detect encrypted/FTA state of each elementary stream (I am imagining that if the channel is marked as mixed, the library would do an extra stage of processing after receiving PMT to check the status of each ES stream found in the PMT to decide the real status of the channel)
Of course I want to re-iterate that this is my ideal solution. It would be quite a lot of work to implement this; especially some of the TV Service logic. We need to be practical and consider what is doable for 1.3b...
The problem here was not caused by a mixed channel - it was triggered by incorrect FTA/encrypted detection in the library, and then made worse by the cache synchronisation problem.
Maybe it is simpler to remove the detection in the library until we can implement a better solution?
If we take that approach, my question would be how common are mixed channels - would we make a bigger problem by removing the library detection?
Maybe we don't need to get so complex in the service with the mixed channel handling. Maybe we can just tune with any tuner, detect actual status in the library, and then throw an exception or not depending on CA availability and current channel status. TV service can move on to try the next tuner with current logic. The service logic would not be 100% optimal, but *significantly* less complex.
What do you think?
mm
To be honest I don't know if I like either approach and I think there is more than one problem that needs to be solved.
I definitely would like to avoid having another setting in TV Server configuration - no disrespect to you georgius, but this solution feels like it is only a work-around for one of the problems.
Equally, although in this case the problem has been exposed by incorrect detection of FTA/encrypted status in the TV library, there are real channels that are sometimes free and sometimes encrypted. The only way to determine the *real* current state is to allow a tuner to try to tune the channel. In other words, I don't think the service should be making decisions about whether a tuner is able to tune such channels because the DB is not guaranteed to be correct. Ensuring that the cache is synchronised will help, but if the DB is wrong in the first place then there is still a problem.
So there are 3 problems:
1. Incorrect FTA/encrypted detection in the library.
2. Cache de-synchronisation with the detected FTA/encrypted status.
3. TV service making tuner allocation decisions with incorrect information.
My suggestion (purely from an "idealist" perspective
) would be...Change "FreeToAir" property to have 3 possible states: [always] free, [always] encrypted, mixed
The TV Service:
- logic for tuner selection and decrypt limit should be fine as is for free and encrypted channels
- should assume a mixed channel is encrypted for the purpose of decrypt limit logic (prefer to tune with a tuner that has CA)
- if there are no tuners with CA available then try with other tuners (if available)
- if other tuners are not available, we could optionally try to tune with a tuner that has CA (to handle the case when the channel is currently FTA)
In the TV Library:
- respect the always encrypted and always FTA settings - do *not* try to auto-detect encrypted status (this allows users to work around the existing faults in the detection of encrypted/FTA state and bad providers who do not follow DVB guidelines)
- for mixed channels, attempt to detect current status (ideally we would replace CA descriptor based detection with TS header scrambled bit detection or even ES level checking)
- implement decrypt limit enforcement so that if a mixed channel is encrypted and the tuner has no CA capability or would exceed the decrypt limit then throw an exception back to the service
In TsWriter:
- extend the TS header scrambled bit checking to be able to detect encrypted/FTA state of each elementary stream (I am imagining that if the channel is marked as mixed, the library would do an extra stage of processing after receiving PMT to check the status of each ES stream found in the PMT to decide the real status of the channel)
Of course I want to re-iterate that this is my ideal solution. It would be quite a lot of work to implement this; especially some of the TV Service logic. We need to be practical and consider what is doable for 1.3b...
The problem here was not caused by a mixed channel - it was triggered by incorrect FTA/encrypted detection in the library, and then made worse by the cache synchronisation problem.
Maybe it is simpler to remove the detection in the library until we can implement a better solution?
If we take that approach, my question would be how common are mixed channels - would we make a bigger problem by removing the library detection?
Maybe we don't need to get so complex in the service with the mixed channel handling. Maybe we can just tune with any tuner, detect actual status in the library, and then throw an exception or not depending on CA availability and current channel status. TV service can move on to try the next tuner with current logic. The service logic would not be 100% optimal, but *significantly* less complex.
What do you think?
mm
- Thread starter
- #27
I agree, I didn't find any other place in TV Server code where tuning details are stored.
Yes, when FTA flag is changed is not stored into database. Tuning detail is stored into database only when PMT PID changed.
Yes, it's only workaround and I suppose that workaround will be removed when FTA detection will be fixed (or another solution will be chosen).
I agree with you, we have to think how to fix this for MP 1.3.0 because new functionality makes MP unusable for some part of users.
Correct.
I think that this could lead to slower changing channels as is in MP 1.2.3.
I think that card allocation cache and tuning detail cache is not bad idea - it just not work as we want because of wrong FTA detection. Extending the TS header scrambled bit checking and/or searching for CAT's in stream should be better solution as my workaround.
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
My intention was that this should only be done for mixed channels. It would definitely be slower in the case where the first tuner is not able to decrypt the channel. However I don't know if we have the time to implement and test fully optimised logic.
Absolutely - the cache is fine... even great
... as long as it doesn't have negative impacts.So if we had a list of options like this:
1. Only add an option in TV Server configuration.
2. Only fix cache sync.
3. Only disable FTA/encrypted check in TV library.
4. Change FTA flag to a 3-state variable (FTA/encrypted/mixed), enable TVLibrary detection only for mixed, disable TV Service caching for mixed.
5. <some other option>
...which would you choose for MP 1.3b?
I lean towards option 3 (and option 2 if possible) because from my list of problems:
...it partially solves #1 (people not prevented from viewing FTA channels)...
...it solves #2 (for PMT PID as well if we do option 2)...
...it doesn't solve #3, but it is no worse than MP 1.2.x...
And effort is quite minimal.
mm
Last edited:
- Thread starter
- #29
I prefer option #3 for MP 1.3.0 Beta ... if it will not work there is still possibility to revert it and apply option #1. For MP 1.4.0 (or 1.3.x) I prefer fixing detection of FTA state. Because of complexity, implementation of option #4 is for me last option.
- Thread starter
- #30
Just a technical question. I'm not familiar with TsWriter to be able to disable FTA check, so should I revert changes in Git branch to original state and assign bug in mantis for mm?
Last edited: