I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
Which global pointer will I have to deleted and assign to the new object?
Thanks, Theunis
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
Klaus
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
Klaus
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same. Asking my broadcaster to fix it would achieve the same results as if you would be talking to a brick wall :)
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Theunis Potgieter wrote: ...
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same. Asking my broadcaster to fix it would achieve the same results as if you would be talking to a brick wall :)
to prevent patching of vdr how about creating a kind of favorite channel plugin that has its own "namelist" which refers to the unique channel "markers" (like in timers.conf) maybe similar to that http://famillejacques.free.fr/vdr/prefermenu/
beside the fact that you have you chosen name for the channel it reduces the channel list to what you need
2010/1/5 Lars Bläser lblaeser@mainz-online.de:
Theunis Potgieter wrote: ...
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same. Asking my broadcaster to fix it would achieve the same results as if you would be talking to a brick wall :)
to prevent patching of vdr how about creating a kind of favorite channel plugin that has its own "namelist" which refers to the unique channel "markers" (like in timers.conf) maybe similar to that http://famillejacques.free.fr/vdr/prefermenu/
beside the fact that you have you chosen name for the channel it reduces the channel list to what you need
Thanks for your idea, but it does not suite my needs. The idea of mine is so that any plugin/vdr function that calls on channel information should see my version of the long name. e.g. vdr-streamdev, vdr-xine, vdr-xineliboutput, vdr-wapd etc.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 05.01.2010 09:40, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same.
And what's wrong with that?
Klaus
2010/1/6 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 05.01.2010 09:40, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same.
And what's wrong with that?
If you have a lot of channels, where the Long names are reduced to short (acronym) names. Then you might run into the problem where you see a few channels with the same short name but with different IDs. I can't always remember what the short name used to stand for after I visit the channel in 6 months. The STB will show the correct long name.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 06.01.2010 13:05, Theunis Potgieter wrote:
2010/1/6 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 05.01.2010 09:40, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote: > I was in search for a plug-in that could map alternative long names to > the supposedly current long name of a channel. I guess I didn't search > hard and long enough, but could not find one that would implement this > behaviour. The idea is, that when ever a channel list is called, it > will provide the alternative long name, but saves the original long > name in channels.conf. > > So I thought of implementing one my self. After reading the > PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't > see any spoon feeding when it came to channels in the documentation, > so I thought I will have a look at channels.h and there seems to be a > member function called Name() in the tChannelID class. Would it be > wise then to copy the tChannelID class and replace the member function > Name()? tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
> Which global pointer will I have to deleted and assign to the new object? I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same.
And what's wrong with that?
If you have a lot of channels, where the Long names are reduced to short (acronym) names. Then you might run into the problem where you see a few channels with the same short name but with different IDs. I can't always remember what the short name used to stand for after I visit the channel in 6 months. The STB will show the correct long name.
Where does the STB get that long name from?
Klaus
2010/1/6 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 06.01.2010 13:05, Theunis Potgieter wrote:
2010/1/6 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 05.01.2010 09:40, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de: > On 04.01.2010 14:37, Theunis Potgieter wrote: >> I was in search for a plug-in that could map alternative long names to >> the supposedly current long name of a channel. I guess I didn't search >> hard and long enough, but could not find one that would implement this >> behaviour. The idea is, that when ever a channel list is called, it >> will provide the alternative long name, but saves the original long >> name in channels.conf. >> >> So I thought of implementing one my self. After reading the >> PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't >> see any spoon feeding when it came to channels in the documentation, >> so I thought I will have a look at channels.h and there seems to be a >> member function called Name() in the tChannelID class. Would it be >> wise then to copy the tChannelID class and replace the member function >> Name()? > tChannelID has no member function named Name(). > Maybe you mean the cChannel class? > I guess if you change the implementation of cChannel::Name(), then you > could do what you want. Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
>> Which global pointer will I have to deleted and assign to the new object? > I don't understand this question. > There is no "new object". > You will have to patch the VDR source to implement this. The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same.
And what's wrong with that?
If you have a lot of channels, where the Long names are reduced to short (acronym) names. Then you might run into the problem where you see a few channels with the same short name but with different IDs. I can't always remember what the short name used to stand for after I visit the channel in 6 months. The STB will show the correct long name.
Where does the STB get that long name from?
I only guess that it will get that information in the same form as the EPG works. The EPG can only be accessed by going to a specific channel and view it using the STB's propriety hardware.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 06.01.2010 13:18, Theunis Potgieter wrote:
2010/1/6 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 06.01.2010 13:05, Theunis Potgieter wrote:
2010/1/6 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 05.01.2010 09:40, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote: > 2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de: >> On 04.01.2010 14:37, Theunis Potgieter wrote: >>> I was in search for a plug-in that could map alternative long names to >>> the supposedly current long name of a channel. I guess I didn't search >>> hard and long enough, but could not find one that would implement this >>> behaviour. The idea is, that when ever a channel list is called, it >>> will provide the alternative long name, but saves the original long >>> name in channels.conf. >>> >>> So I thought of implementing one my self. After reading the >>> PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't >>> see any spoon feeding when it came to channels in the documentation, >>> so I thought I will have a look at channels.h and there seems to be a >>> member function called Name() in the tChannelID class. Would it be >>> wise then to copy the tChannelID class and replace the member function >>> Name()? >> tChannelID has no member function named Name(). >> Maybe you mean the cChannel class? >> I guess if you change the implementation of cChannel::Name(), then you >> could do what you want. > Thanks for that. I must have scrolled back up and saw the wrong class, > I meant cChannel:Name(). > >>> Which global pointer will I have to deleted and assign to the new object? >> I don't understand this question. >> There is no "new object". >> You will have to patch the VDR source to implement this. > The idea is that the plug-in would delete the current instance of > cChannel and instantiate a new cChannel instance in the place there > of. This without having to patch vdr to implement this feature. There > for the question about the (e.g. global) pointer that is pointing to > the original instance of cChannel. Is there a member function in the > plug-in class that can be called from VDR's main and hand over such a > pointer? There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
Just curious: what's wrong with the original names?
The long names and the short names are the same.
And what's wrong with that?
If you have a lot of channels, where the Long names are reduced to short (acronym) names. Then you might run into the problem where you see a few channels with the same short name but with different IDs. I can't always remember what the short name used to stand for after I visit the channel in 6 months. The STB will show the correct long name.
Where does the STB get that long name from?
I only guess that it will get that information in the same form as the EPG works. The EPG can only be accessed by going to a specific channel and view it using the STB's propriety hardware.
Those providers really suck!
At the moment the only real advice I can give you is to change the cChannel::Name() function so that it looks up your long channel names in a list that maps channel ids to long names.
A clean solution will be possible once I get to implement user defined favorite channel lists, where the user will be able to overwrite the channel name.
Klaus
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 16:09, Theunis Potgieter wrote:
2010/1/4 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
On 04.01.2010 14:37, Theunis Potgieter wrote:
I was in search for a plug-in that could map alternative long names to the supposedly current long name of a channel. I guess I didn't search hard and long enough, but could not find one that would implement this behaviour. The idea is, that when ever a channel list is called, it will provide the alternative long name, but saves the original long name in channels.conf.
So I thought of implementing one my self. After reading the PLUGINS.html from VDR-1.7.10, I thought it would be possible. I didn't see any spoon feeding when it came to channels in the documentation, so I thought I will have a look at channels.h and there seems to be a member function called Name() in the tChannelID class. Would it be wise then to copy the tChannelID class and replace the member function Name()?
tChannelID has no member function named Name(). Maybe you mean the cChannel class? I guess if you change the implementation of cChannel::Name(), then you could do what you want.
Thanks for that. I must have scrolled back up and saw the wrong class, I meant cChannel:Name().
Which global pointer will I have to deleted and assign to the new object?
I don't understand this question. There is no "new object". You will have to patch the VDR source to implement this.
The idea is that the plug-in would delete the current instance of cChannel and instantiate a new cChannel instance in the place there of. This without having to patch vdr to implement this feature. There for the question about the (e.g. global) pointer that is pointing to the original instance of cChannel. Is there a member function in the plug-in class that can be called from VDR's main and hand over such a pointer?
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
The reason for not wanting to create a patch against the main vdr core was related to this old article: http://www.linuxjournal.com/article/3687 Would you rather prefer a patch with a menu option where you can choose the plug-in that will handle the external mappings of channel names?
Just curious: what's wrong with the original names?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 04.01.2010 18:26, schrieb Klaus Schmidinger:
There is an object of cChannel for each channel, and they are stored in a list. You can either patch VDR to modify cChannel::Name() so that it takes the original name as an index into some database of yours, or modify the names in your channels.conf and set "Setup/DVB/Update channels" to "PIDs only".
There are a lot of similar problems with channel info and epg data coming up frequently. Maybe its a good idea to add some plugin interface that allows to 'filter' all these informations, so that plugins can be written that fix all the bogus data that the broadcasters send out.
Cheers,
Udo
-
Klaus Schmidinger -
Lars Bläser -
Theunis Potgieter -
Udo Richter