Hi,
I'm planning to work back on the parental lock plugin that I've made loong time ago, and which doesn't work anymore on the last VDR version (by the way, congratulations to all vdr/plugin developer)
I'm thinking of a way to "limit" the needed patches for such "options", and I wonder if there is no way to include one more field to the channels.conf, which would enable/disable the viewing of the channel (in locked mode).
What I propose is to implement by myself this features (to the cChannel class) and I wonder if this could be implemented to the next VDR versions (not the full parental lock functions, but only the channels.conf field, reading functions and one little more function such as bool cChannels.IsLocked(), the rest of the parental lock implementation still under plugin form). I guess this should not break anything...
@Klaus : Do you think it is possible?
Sad
Sad wrote:
Hi,
I'm planning to work back on the parental lock plugin that I've made loong time ago, and which doesn't work anymore on the last VDR version (by the way, congratulations to all vdr/plugin developer)
I'm thinking of a way to "limit" the needed patches for such "options", and I wonder if there is no way to include one more field to the channels.conf, which would enable/disable the viewing of the channel (in locked mode).
What I propose is to implement by myself this features (to the cChannel class) and I wonder if this could be implemented to the next VDR versions (not the full parental lock functions, but only the channels.conf field, reading functions and one little more function such as bool cChannels.IsLocked(), the rest of the parental lock implementation still under plugin form). I guess this should not break anything...
@Klaus : Do you think it is possible?
The channels.conf file shall only contain data that is broadcast from the data stream - nothing else.
What I am going to implement (with luck even before 1.4) are user defined "favorite channel" lists. Such a list could contain only channels you consider non-harmful for your kids.
Klaus
Klaus Schmidinger a écrit :
Sad wrote:
Hi,
I'm planning to work back on the parental lock plugin that I've made loong time ago, and which doesn't work anymore on the last VDR version (by the way, congratulations to all vdr/plugin developer)
I'm thinking of a way to "limit" the needed patches for such "options", and I wonder if there is no way to include one more field to the channels.conf, which would enable/disable the viewing of the channel (in locked mode).
What I propose is to implement by myself this features (to the cChannel class) and I wonder if this could be implemented to the next VDR versions (not the full parental lock functions, but only the channels.conf field, reading functions and one little more function such as bool cChannels.IsLocked(), the rest of the parental lock implementation still under plugin form). I guess this should not break anything...
@Klaus : Do you think it is possible?
The channels.conf file shall only contain data that is broadcast from the data stream - nothing else.
What I am going to implement (with luck even before 1.4) are user defined "favorite channel" lists. Such a list could contain only channels you consider non-harmful for your kids.
Klaus
Oh yes, I haven't see the thinks like this, and I fully understand your point of view!
So I'll "suspend" my plugin development until such user defined "favorite channel" lists are implemented!
Thanks again for all your (great) work!
Sad
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de writes:
[...]
The channels.conf file shall only contain data that is broadcast from the data stream - nothing else.
What I am going to implement (with luck even before 1.4) are user defined "favorite channel" lists. Such a list could contain only channels you consider non-harmful for your kids.
That would be great !
I know I may ask too much, but would that allow to group identical channels (provided by different satellites) under the same user-defined channel ?
Anyway, thanks for your work !
syrius.ml@no-log.org wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de writes:
[...]
The channels.conf file shall only contain data that is broadcast from the data stream - nothing else.
What I am going to implement (with luck even before 1.4) are user defined "favorite channel" lists. Such a list could contain only channels you consider non-harmful for your kids.
That would be great !
I know I may ask too much, but would that allow to group identical channels (provided by different satellites) under the same user-defined channel ?
I'd say that's a completely different thing and has nothing to do with user defined favorite channels.
Klaus
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de writes:
[...] I know I may ask too much, but would that allow to group identical channels (provided by different satellites) under the same user-defined channel ?
I'd say that's a completely different thing and has nothing to do with user defined favorite channels.
grrr again I read too quickly. (i missed the "favorite") I thought you were talking about a generic user defined channel list. Something that would allow regrouping and to have user-defined settings per channel (volume for ex)
syrius.ml@no-log.org wrote:
Klaus Schmidinger Klaus.Schmidinger@cadsoft.de writes:
[...] I know I may ask too much, but would that allow to group identical channels (provided by different satellites) under the same user-defined channel ?
I'd say that's a completely different thing and has nothing to do with user defined favorite channels.
grrr again I read too quickly. (i missed the "favorite") I thought you were talking about a generic user defined channel list. Something that would allow regrouping and to have user-defined settings per channel (volume for ex)
You could keep the per channel parental control setting in a separate configuration file indexed by channel-id. This is more cumbersome but it is totally independent from main vdr. You can look at the ttxtsubs plugin and the "premium edition" patch at http://users.tkk.fi/~rahrenbe/vdr/ : the patch stores per-channel teletext subtitles configuration (the original patch used a std::map indexed on the sid, in a private branch I changed that to use the channel-id instead, and then got rid of std::map altogether. The last step I did --eliminating the map and iterating on all the elements instead-- maybe was not very wise, but you can get the idea).
Bye
Luca Olivetti a écrit :
You could keep the per channel parental control setting in a separate configuration file indexed by channel-id. This is more cumbersome but it is totally independent from main vdr. You can look at the ttxtsubs plugin and the "premium edition" patch at http://users.tkk.fi/~rahrenbe/vdr/ : the patch stores per-channel teletext subtitles configuration (the original patch used a std::map indexed on the sid, in a private branch I changed that to use the channel-id instead, and then got rid of std::map altogether. The last step I did --eliminating the map and iterating on all the elements instead-- maybe was not very wise, but you can get the idea).
Bye
How does this channel-id is made??
My last issue was with channels which have been auto-updated, and which was present in the "unlocked" list, and no more in the channels list, which cause a segfault on unlocked list loading... that's why I've though about including a new field in the channels.conf file.
But I hope the use of the futur favorite channels list will remove this issue and everything will be much better for everyone :)
Sad
Sad wrote:
How does this channel-id is made??
look in channels.h: struct tChannelID, cChannel::GetChannelID
My last issue was with channels which have been auto-updated, and which was present in the "unlocked" list, and no more in the channels list, which cause a segfault on unlocked list loading... that's why I've though about including a new field in the channels.conf file.
I don't know if my implementation is good or no, but look at the plugin I mentioned (ttxtsubs+premium edition patch): up until now I never had a segfault due to it. If I understood it correctly, a channel id is supposed to be unique and constant, regardless of changes in other attributes of the channel.
But I hope the use of the futur favorite channels list will remove this issue and everything will be much better for everyone :)
well, I think that's something not strictly related to parental control.
Bye
Luca Olivetti a écrit :
Sad wrote:
How does this channel-id is made??
look in channels.h: struct tChannelID, cChannel::GetChannelID
My last issue was with channels which have been auto-updated, and which was present in the "unlocked" list, and no more in the channels list, which cause a segfault on unlocked list loading... that's why I've though about including a new field in the channels.conf file.
I don't know if my implementation is good or no, but look at the plugin I mentioned (ttxtsubs+premium edition patch): up until now I never had a segfault due to it. If I understood it correctly, a channel id is supposed to be unique and constant, regardless of changes in other attributes of the channel.
I'll look at it for sure ;) Thanks
But I hope the use of the futur favorite channels list will remove this issue and everything will be much better for everyone :)
well, I think that's something not strictly related to parental control.
Bye
Not strictly, but migth be used/inherited for that purpose!
Bye
Sad
-
Klaus Schmidinger -
Luca Olivetti -
Sad -
syrius.ml＠no-log.org