Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
In case, I am missing something, I would also like to ask everybody reading this to let us know, if for any reason, the idea about replacing the channelnames with channelname-source cannot work.
There are of course also other solutions, like adding a system to the VDR allowing the user to indicate to the VDR, that both ZDF channels (to continue with the example above) are only variations of the same channel; the VDR could thus only show one of the two channels in his channellist (hd channels could also be seen as another variation of the channel); a priority system would be required to indicate what variation of the channel to use for recordings,...
Restarting the discussion about how to best handle the simultaneous reception of more than one source is on my ToDo list since I started that thread in the german forum. Unfortunately, I did not have the time to do it until now, and probably will not have the time to do it seriously in the near future. Moreover, since I got the idea about simply adding the information about the source to the string of the channelname, I decided to ask for it, instead of waiting for something, that would probably require a long time to get designed and implemented.
Cheers,
Ludi
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)
which would return things like
ZDF (DVB-T) ZDF (DVB-S)
or, shorter,
ZDF (T) ZDF (S)
and using that function instead of the Name() function at the appropriate places.
In case, I am missing something, I would also like to ask everybody reading this to let us know, if for any reason, the idea about replacing the channelnames with channelname-source cannot work.
Well, it could work all right. But as I said, I'd like to keep that raw data in the channels.conf entries.
Klaus
Hi Klaus,
First of all, thanks for your reply and for taking the problem into account.
On Sat, 16 Jun 2012 15:32:11 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
I understand your concerns.
I assumed that changing the names in the channels.conf would be the best in order to make also the plugins and other software use the names+source for free. Moreover, since the channels.conf can be constantly updated, I thought that it would not really matter, because the names without source could be restored in the channels.conf by simply disabling the new option and configure the update setting to also modify the channelnames. I was not aware that there was a standard for the broadcasting of the channelnames; but it does not surprise me either now.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)
which would return things like
ZDF (DVB-T) ZDF (DVB-S)
or, shorter,
ZDF (T) ZDF (S)
and using that function instead of the Name() function at the appropriate places.
If I get you right, that means that if the user activates the new option (I assume that you will make it optional, since most people probably use only one source and do not have the problem), the VDR uses the NameWithSource() method instead of the Name() method.
But what does this mean for the plugins? I am particularly thinking at the plugins related to the timers, like the epgsearch and the live plugin. Will they have to be adapted or will they also show the name+source if the new option is enabled?
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)
In case, I am missing something, I would also like to ask everybody reading this to let us know, if for any reason, the idea about replacing the channelnames with channelname-source cannot work.
Well, it could work all right. But as I said, I'd like to keep that raw data in the channels.conf entries.
In any case, I am grateful for anything you will do to improve the VDR for people receiving channels from different sources.
Cheers,
Ludi
Hi again,
On Sat, 16 Jun 2012 16:53:58 +0200 Ludi ludi113@hotmail.com wrote:
Hi Klaus,
First of all, thanks for your reply and for taking the problem into account.
On Sat, 16 Jun 2012 15:32:11 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
I understand your concerns.
I assumed that changing the names in the channels.conf would be the best in order to make also the plugins and other software use the names+source for free. Moreover, since the channels.conf can be constantly updated, I thought that it would not really matter, because the names without source could be restored in the channels.conf by simply disabling the new option and configure the update setting to also modify the channelnames. I was not aware that there was a standard for the broadcasting of the channelnames; but it does not surprise me either now.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)
which would return things like
ZDF (DVB-T) ZDF (DVB-S)
or, shorter,
ZDF (T) ZDF (S)
and using that function instead of the Name() function at the appropriate places.
If I get you right, that means that if the user activates the new option (I assume that you will make it optional, since most people probably use only one source and do not have the problem), the VDR uses the NameWithSource() method instead of the Name() method.
But what does this mean for the plugins? I am particularly thinking at the plugins related to the timers, like the epgsearch and the live plugin. Will they have to be adapted or will they also show the name+source if the new option is enabled?
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)
I suppose that ZDF (I) for the IPTV reception would also make sense. And what about analogue and the other standards? http://en.wikipedia.org/wiki/Digital_television
Maybe that the different ways of reception are already available in an header of the VDR or in some definition of the channels.conf.
In case, I am missing something, I would also like to ask everybody reading this to let us know, if for any reason, the idea about replacing the channelnames with channelname-source cannot work.
Well, it could work all right. But as I said, I'd like to keep that raw data in the channels.conf entries.
In any case, I am grateful for anything you will do to improve the VDR for people receiving channels from different sources.
Cheers,
Ludi
On 16.06.2012 18:21, Ludi wrote:
Hi again,
On Sat, 16 Jun 2012 16:53:58 +0200 Ludiludi113@hotmail.com wrote:
Hi Klaus,
First of all, thanks for your reply and for taking the problem into account.
On Sat, 16 Jun 2012 15:32:11 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
I understand your concerns.
I assumed that changing the names in the channels.conf would be the best in order to make also the plugins and other software use the names+source for free. Moreover, since the channels.conf can be constantly updated, I thought that it would not really matter, because the names without source could be restored in the channels.conf by simply disabling the new option and configure the update setting to also modify the channelnames. I was not aware that there was a standard for the broadcasting of the channelnames; but it does not surprise me either now.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)which would return things like
ZDF (DVB-T) ZDF (DVB-S)or, shorter,
ZDF (T) ZDF (S)and using that function instead of the Name() function at the appropriate places.
If I get you right, that means that if the user activates the new option (I assume that you will make it optional, since most people probably use only one source and do not have the problem), the VDR uses the NameWithSource() method instead of the Name() method.
But what does this mean for the plugins? I am particularly thinking at the plugins related to the timers, like the epgsearch and the live plugin. Will they have to be adapted or will they also show the name+source if the new option is enabled?
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)I suppose that ZDF (I) for the IPTV reception would also make sense. And what about analogue and the other standards? http://en.wikipedia.org/wiki/Digital_television
Maybe that the different ways of reception are already available in an header of the VDR or in some definition of the channels.conf.
That would be the first character of the "source" parameter in channels.conf.
Klaus
In case, I am missing something, I would also like to ask everybody reading this to let us know, if for any reason, the idea about replacing the channelnames with channelname-source cannot work.
Well, it could work all right. But as I said, I'd like to keep that raw data in the channels.conf entries.
In any case, I am grateful for anything you will do to improve the VDR for people receiving channels from different sources.
Cheers,
Ludi
I use VDR mainly via www frontends, but I agree that there is need to tell VDR what to do with channels from different tuners. For example detection of recordings collision doesn't take into account that channels are from two different sources (two different tuners). It also doesn't understand that it's possible to record simultanoesly from the same transponder. Vdr itself allow for all of it, but module which analyse collisions should be much more flexible. We also sometimes have the same channels in SD and HD which has different name but they differ only in quality. I can imagine that it should be easily possible to teach colision detection module that some devices can record at once, also that it's possible to record multiple streams form the same transponder. But it would be also great if we could virtually join some channels and tell recording module that they are the same channel, so they for example share EPG (it's possible now via plugins, I know). It should be possible to tell which one should be picked at first if we record from such virtual channel. Collision module should advice for example "record from SD version of channel because it's on the same transponder that second recording we have planned" or "move this recording from DVB-S card to DVB-T card because DVB-S card records at the same time from another channel". I can give example: polish channel TVP 1 is available from Hotbird as (1) SD version, (2) HD version. It's also available in DVB-T as (3) SD version and (4) HD version. I have this channel also available in (5) old good analogue version. It's probably also available from Astra, and from local provider of DVB-C. Marx
On 17.06.2012 00:13, Marx wrote:
I use VDR mainly via www frontends, but I agree that there is need to tell VDR what to do with channels from different tuners. For example detection of recordings collision doesn't take into account that channels are from two different sources (two different tuners). It also doesn't understand that it's possible to record simultanoesly from the same transponder. Vdr itself allow for all of it, but module which analyse collisions should be much more flexible. We also sometimes have the same channels in SD and HD which has different name but they differ only in quality. I can imagine that it should be easily possible to teach colision detection module that some devices can record at once, also that it's possible to record multiple streams form the same transponder. But it would be also great if we could virtually join some channels and tell recording module that they are the same channel, so they for example share EPG (it's possible now via plugins, I know). It should be possible to tell which one should be picked at first if we record from such virtual channel. Collision module should advice for example "record from SD version of channel because it's on the same transponder that second recording we have planned" or "move this recording from DVB-S card to DVB-T card because DVB-S card records at the same time from another channel". I can give example: polish channel TVP 1 is available from Hotbird as (1) SD version, (2) HD version. It's also available in DVB-T as (3) SD version and (4) HD version. I have this channel also available in (5) old good analogue version. It's probably also available from Astra, and from local provider of DVB-C.
The core VDR doesn't have these features, yet, but I'm planning on looking into these after version 2.0.
Klaus
What do you think about moving collision detection module into plugin? That way it could be easily swapped. I'm sure many people have their preferences different in how such module should work Marx
On 18.06.2012 08:37, Marx wrote:
What do you think about moving collision detection module into plugin? That way it could be easily swapped. I'm sure many people have their preferences different in how such module should work
There is no "collision detection" in core VDR yet, so there's nothing to "move into a plugin" ;-)
These are things that I will look into *after* version 2.0.
Klaus
On 16.06.2012 16:53, Ludi wrote:
Hi Klaus,
First of all, thanks for your reply and for taking the problem into account.
On Sat, 16 Jun 2012 15:32:11 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
I understand your concerns.
I assumed that changing the names in the channels.conf would be the best in order to make also the plugins and other software use the names+source for free. Moreover, since the channels.conf can be constantly updated, I thought that it would not really matter, because the names without source could be restored in the channels.conf by simply disabling the new option and configure the update setting to also modify the channelnames. I was not aware that there was a standard for the broadcasting of the channelnames; but it does not surprise me either now.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)which would return things like
ZDF (DVB-T) ZDF (DVB-S)or, shorter,
ZDF (T) ZDF (S)and using that function instead of the Name() function at the appropriate places.
If I get you right, that means that if the user activates the new option (I assume that you will make it optional, since most people probably use only one source and do not have the problem), the VDR uses the NameWithSource() method instead of the Name() method.
But what does this mean for the plugins? I am particularly thinking at the plugins related to the timers, like the epgsearch and the live plugin. Will they have to be adapted or will they also show the name+source if the new option is enabled?
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)
After sleeping over this for a night I tend to follow your idea of using modifed names directly, thus having them appear everywhere.
I won't change these names in channels.conf, though (this file shall always store what comes from the broadcaster - provided it is enabled in the setup). I'll rather
- Make a setup option to "Show channel names with source" (default is "no"). - Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
The attached patch implements this (i18n stuff left out for brevity). Please give it a try.
@Ludi: BTW: in order to give you credit in VDR's HISTORY/CONTRIBUTORS file I'll need your full name.
Klaus
On 17.06.2012 14:16, Klaus Schmidinger wrote:
On 16.06.2012 16:53, Ludi wrote:
Hi Klaus,
First of all, thanks for your reply and for taking the problem into account.
On Sat, 16 Jun 2012 15:32:11 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
I understand your concerns.
I assumed that changing the names in the channels.conf would be the best in order to make also the plugins and other software use the names+source for free. Moreover, since the channels.conf can be constantly updated, I thought that it would not really matter, because the names without source could be restored in the channels.conf by simply disabling the new option and configure the update setting to also modify the channelnames. I was not aware that there was a standard for the broadcasting of the channelnames; but it does not surprise me either now.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)
which would return things like
ZDF (DVB-T) ZDF (DVB-S)
or, shorter,
ZDF (T) ZDF (S)
and using that function instead of the Name() function at the appropriate places.
If I get you right, that means that if the user activates the new option (I assume that you will make it optional, since most people probably use only one source and do not have the problem), the VDR uses the NameWithSource() method instead of the Name() method.
But what does this mean for the plugins? I am particularly thinking at the plugins related to the timers, like the epgsearch and the live plugin. Will they have to be adapted or will they also show the name+source if the new option is enabled?
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)
After sleeping over this for a night I tend to follow your idea of using modifed names directly, thus having them appear everywhere.
I won't change these names in channels.conf, though (this file shall always store what comes from the broadcaster - provided it is enabled in the setup). I'll rather
- Make a setup option to "Show channel names with source" (default is "no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally
append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
The attached patch implements this (i18n stuff left out for brevity). Please give it a try.
Sorry, apparently I forgot to store this new option in the setup.conf file:
--- config.c 2012/06/13 09:12:53 2.25 +++ config.c 2012/06/17 12:27:07 @@ -658,6 +659,7 @@ else if (!strcasecmp(Name, "InitialVolume")) InitialVolume = atoi(Value); else if (!strcasecmp(Name, "DeviceBondings")) DeviceBondings = Value; else if (!strcasecmp(Name, "ChannelsWrap")) ChannelsWrap = atoi(Value); + else if (!strcasecmp(Name, "ShowChannelNamesWithSource")) ShowChannelNamesWithSource = atoi(Value); else if (!strcasecmp(Name, "EmergencyExit")) EmergencyExit = atoi(Value); else return false; @@ -756,6 +758,7 @@ Store("InitialVolume", InitialVolume); Store("DeviceBondings", DeviceBondings); Store("ChannelsWrap", ChannelsWrap); + Store("ShowChannelNamesWithSource", ShowChannelNamesWithSource); Store("EmergencyExit", EmergencyExit);
Sort();
Klaus
Am Sonntag, 17. Juni 2012, 14:16:53 schrieb Klaus Schmidinger:
- Make a setup option to "Show channel names with source" (default is "no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
you could give that option different values like
- never show channel source - always show channel source - only show channel source if the same channel has different sources
for space conserving people, something shorter than (%c) might be nice
maybe an additional option "channel source format" which only triggers if the channel source is to be displayed:
with values like
%s (%c) %n/%c %c %s
On 17.06.2012 15:19, Wolfgang Rohdewald wrote:
Am Sonntag, 17. Juni 2012, 14:16:53 schrieb Klaus Schmidinger:
- Make a setup option to "Show channel names with source" (default is "no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
you could give that option different values like
- never show channel source
- always show channel source
- only show channel source if the same channel has different sources
for space conserving people, something shorter than (%c) might be nice
maybe an additional option "channel source format" which only triggers if the channel source is to be displayed:
with values like
%s (%c) %n/%c %c %s
Let's keep this simple ;-)
Klaus
On Sun, 17 Jun 2012 14:16:53 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
After sleeping over this for a night I tend to follow your idea of using modifed names directly, thus having them appear everywhere.
That's great news.
I won't change these names in channels.conf, though (this file shall always store what comes from the broadcaster - provided it is enabled in the setup). I'll rather
- Make a setup option to "Show channel names with source" (default is
"no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel
name in the (short) form mentioned above.
The attached patch implements this (i18n stuff left out for brevity). Please give it a try.
Could you please tell us whether the patch is compatible to vdr 1.7.27? It is the version that is currently in use in the development version of yavdr.
@Ludi: BTW: in order to give you credit in VDR's HISTORY/CONTRIBUTORS file I'll need your full name.
You can use Ludi Kaleni <ludi113 * hotmail * com>.
Ludi
On 17.06.2012 16:50, Ludi wrote:
On Sun, 17 Jun 2012 14:16:53 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
... The attached patch implements this (i18n stuff left out for brevity). Please give it a try.
Could you please tell us whether the patch is compatible to vdr 1.7.27? It is the version that is currently in use in the development version of yavdr.
It should apply just fine.
Klaus
On Sun, 17 Jun 2012 16:55:10 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 17.06.2012 16:50, Ludi wrote:
Could you please tell us whether the patch is compatible to vdr 1.7.27? It is the version that is currently in use in the development version of yavdr.
It should apply just fine.
After some fiddling (unfortunately, I am far from being an expert), I was able to apply the patch (enhanced with the part to save the configuration) to vdr-1.7.27, that I got from the unstable vdr PPA for precise of yavdr. I added the patch, added a point to debian/changelog and was able to rebuild and install the vdr debian package. (The patch I used and that contains Klaus' code is attached to this email, but be aware that I don't know whether I did everything correctly.)
Depending on the skin used, the source is visible on more or less places; I am using the narrowhd skin, and the source is not visible in the menu that appears when hitting "ok" on the remote control, it is not visible in the next records section of the main menu, but it is visible in the channellist, in the detailed view of the timers,...
I was able to verify the with the default vdr skin, the source is visible on more places.
Concerning the plugins, I only looked at the live plugin and the xmltv2vdr plugin; unfortunately, the source is not visible in this plugins.
@Henning
You talked about an error in the patch from Klaus; if you know how to fix it, you are welcome to enhance my patch.
Cheers
Am 17.06.2012 14:16, schrieb Klaus Schmidinger:
On 16.06.2012 16:53, Ludi wrote:
Hi Klaus,
First of all, thanks for your reply and for taking the problem into account.
On Sat, 16 Jun 2012 15:32:11 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 15.06.2012 17:17, Ludi wrote:
Hello,
Some time ago, I started a discussion in german on the VDR forum about making the VDR more friendly for users that are simultaneously using different sources to receive channels: http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1...
I am going to explain the problem, when receiving channels from two different sources by using the second german public channel named ZDF:
Suppose a user is receiving the channel ZDF by dvb-s and dvb-t. For the VDR, these are two different channels, and it probably is not a bad thing that the VDR differentiates between them because these channels might be of different quality (different data rates, etc.). However, as both sources name these channels often the same way, it is not easily possible to differentiate between the two channels in the VDR OSD, which is particularly annoying for the timers, one of the main VDR features.
Currently, I work around this problem, by setting the VDR to not update channelnames and manually adding a suffix to the channelnames in the channels.conf. So, to use the example above and differentiate between the two channels, they could be renamed to ZDF-s and ZDF-t (or ZDF.s and ZDF.t, or...). In practice, I only only rename the channelnames of the source with the smallest number of channels; I know that the channelnames without suffix are those from the other source.
@ Klaus
Do you think that you could add an additional option to one of your next VDR releases, like "Add suffix about source to channelnames"; I could imagine such an option next to the "Update channels" option in the DVB section of the Setup in the OSD of the VDR.
Since the information is already in the channels.conf for every channel, I assume, that it will not require huge changes to the VDR code to use channelnames-source (or something similar) instead of only the channelname in the channelname field of the channels.conf, when the corresponding option is active.
I'd rather have the channels.conf entries keep the names that are broadcast in the SI data. I wouldn't want to add a "source" suffix there.
I understand your concerns.
I assumed that changing the names in the channels.conf would be the best in order to make also the plugins and other software use the names+source for free. Moreover, since the channels.conf can be constantly updated, I thought that it would not really matter, because the names without source could be restored in the channels.conf by simply disabling the new option and configure the update setting to also modify the channelnames. I was not aware that there was a standard for the broadcasting of the channelnames; but it does not surprise me either now.
However, I could imagine adding a function like
cString cChannel::NameWithSource(void)which would return things like
ZDF (DVB-T) ZDF (DVB-S)or, shorter,
ZDF (T) ZDF (S)and using that function instead of the Name() function at the appropriate places.
If I get you right, that means that if the user activates the new option (I assume that you will make it optional, since most people probably use only one source and do not have the problem), the VDR uses the NameWithSource() method instead of the Name() method.
But what does this mean for the plugins? I am particularly thinking at the plugins related to the timers, like the epgsearch and the live plugin. Will they have to be adapted or will they also show the name+source if the new option is enabled?
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)After sleeping over this for a night I tend to follow your idea of using modifed names directly, thus having them appear everywhere.
I won't change these names in channels.conf, though (this file shall always store what comes from the broadcaster - provided it is enabled in the setup). I'll rather
- Make a setup option to "Show channel names with source" (default is
"no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
Hi,
satellite sources are a special case because with satellites it is possible to receive more than one satellite position. For example, there is a channel called "Sky Atlantic HD" on S28.2E, but there's also a channel called "Sky Atlantic HD" on S19.2E. Both channels have different EPG data and different audio/language streams.
My suggestion: Users with more than one satellite position might want to enable an option "Show full satellite position name" so that they don't see "Sky Atlantic HD (S)" but instead "Sky Atlantic HD (S19.2E)".
Cheers, Henning
On 06/17/2012 02:16 PM, Klaus Schmidinger wrote:
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)After sleeping over this for a night I tend to follow your idea of using modifed names directly, thus having them appear everywhere.
I won't change these names in channels.conf, though (this file shall always store what comes from the broadcaster - provided it is enabled in the setup). I'll rather
- Make a setup option to "Show channel names with source" (default is
"no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
Hello Klaus!
Just in case you miss this: Your patch puts a '(' after a channel Category defined with ':CategoryName' in channels.conf
here is a screenshot: http://i.imgur.com/maSlV.jpg?1
Cheers!
On 18.06.2012 11:27, mtron wrote:
On 06/17/2012 02:16 PM, Klaus Schmidinger wrote:
Concerning whether to use the longer or the shorter version of the name+source, I would choose the shorter version to not increase chances of the new name not fitting in the OSD. Thus:
ZDF (S) ZDF (T) ZDF (C)After sleeping over this for a night I tend to follow your idea of using modifed names directly, thus having them appear everywhere.
I won't change these names in channels.conf, though (this file shall always store what comes from the broadcaster - provided it is enabled in the setup). I'll rather
- Make a setup option to "Show channel names with source" (default is
"no").
- Modify cChannel::Name() and cChannel::ShortName() to optionally append the source character (A, C, S, T, I, ...) to the channel name in the (short) form mentioned above.
Hello Klaus!
Just in case you miss this: Your patch puts a '(' after a channel Category defined with ':CategoryName' in channels.conf
here is a screenshot: http://i.imgur.com/maSlV.jpg?1
Thanks, I did miss that. Will fix it after my vacation ;-)
Klaus
Hi,
As some of you might already know, I'm working on a way to semi-automatically assign unique channel IDs to channels of different DVB providers. As I currently don't have time to explain it in detail today, I will just post some links and join this discussion later on when I have more time to sit down and explain stuff. ;-)
The whole thing is based on Channelpedia, a sub-project of the yaVDR distribution. It is a web-based channel string directory that can contain channels from different DVB providers and DVB types. It stores all data centrally in a SQLITE database. This makes it easy to work with the data and generate lookup tables for VDR core or plugins.
Demos: http://channelpedia.yavdr.com/gen/de_uniqueIDs2.html http://channelpedia.yavdr.com/gen/de_uniqueIDs.html (JSON files available for auto-assignment)
German language thread: http://www.vdr-portal.de/board1-news/board2-vdr-news/111607-announce-entwurf-channelpedia-generiert-automatisch-unique-kanal-ids/
Regards, Henning
On Sat, Jun 16, 2012 at 11:47 PM, Henning Pingel henning@henningpingel.de wrote:
Hi,
As some of you might already know, I'm working on a way to semi-automatically assign unique channel IDs to channels of different DVB providers. As I currently don't have time to explain it in detail today, I will just post some links and join this discussion later on when I have more time to sit down and explain stuff. ;-)
Why not just patch VDR so it cycles through channels that use the same channel number. No bothering with sql databases & dependency, no altering the real channel numbers, no real pain that I can think of. For example, say you have 3 different sources using the same channel number:
channel 100, dvb-s channel 100, dvb-t channel 100, dvb-c
You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop back to 100 dvb-s. Also, instead of having to enter the channel number to cycle through them, maybe just use different keys (skip +/-, ffw/rew, some other keys) to cycle. If there's only one of that channel number, the cycle keys don't do anything.
I like this idea far better than adding an sql dependency to VDR and I see no reason why the above would be difficult to implement or use. If I'm missing something, please let me know.
On Sun, 17 Jun 2012 00:26:22 -0700 VDR User user.vdr@gmail.com wrote:
Why not just patch VDR so it cycles through channels that use the same channel number. No bothering with sql databases & dependency, no altering the real channel numbers, no real pain that I can think of. For example, say you have 3 different sources using the same channel number:
channel 100, dvb-s channel 100, dvb-t channel 100, dvb-c
You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop back to 100 dvb-s. Also, instead of having to enter the channel number to cycle through them, maybe just use different keys (skip +/-, ffw/rew, some other keys) to cycle. If there's only one of that channel number, the cycle keys don't do anything.
The trouble with that idea is that it doesn't make it easy to work out which source you've selected, especially via vdradmin, unless that gets patched too.
I use DVB-T and DVB-S and I select DVB-S where possible. The reception is more reliable, not being vulnerable to breaking up every time someone rides past on a motor scooter :-/. I do this manually, so it's important that I can tell which is which.
The official LCNs (published in most listings magazines) for UK's DVB-T start at 1 and at 101 for DVB-S, so it's quite easy to keep them separate; I only have to renumber a few DVB-T radio stations to avoid clashes. This depends on external tools/scripts when scanning though.
I think having VDR (optionally) show something like "(T)"/"(S)" next to the names is the best idea, but I also like the idea that it somehow understands that they can be considered as identical. Further, there are several regional variants of the main channels available on DVB-S, so it would be handy if it could prompt something like, "It isn't possible to record BBC 1 South and BBC 2 simultaneously, but you can record the same programme from BBC 1 London instead."
On Sun, 17 Jun 2012 12:44:06 +0300 Tony Houghton h@realh.co.uk wrote:
I think having VDR (optionally) show something like "(T)"/"(S)" next to the names is the best idea, but I also like the idea that it somehow understands that they can be considered as identical.
That was the core of my idea: let's simply enhance the names of the channels with an indication to its source, so that people are able to distinguish the source of the channels with the same name. This would allow people with more than one source of reception to more easily bridge the time until a full solution is available.
And if the enhancement of the channelnames could be made in a place, where also the plugins could see it without modifications to the plugins, it would be even better. But I understand Klaus being reluctant to change the names directly in the channels.conf.
Cheers
On 17.06.2012 09:26, VDR User wrote:
On Sat, Jun 16, 2012 at 11:47 PM, Henning Pingel henning@henningpingel.de wrote:
Hi,
As some of you might already know, I'm working on a way to semi-automatically assign unique channel IDs to channels of different DVB providers. As I currently don't have time to explain it in detail today, I will just post some links and join this discussion later on when I have more time to sit down and explain stuff. ;-)
Why not just patch VDR so it cycles through channels that use the same channel number. No bothering with sql databases& dependency, no altering the real channel numbers, no real pain that I can think of. For example, say you have 3 different sources using the same channel number:
channel 100, dvb-s channel 100, dvb-t channel 100, dvb-c
You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop back to 100 dvb-s. Also, instead of having to enter the channel number to cycle through them, maybe just use different keys (skip +/-, ffw/rew, some other keys) to cycle. If there's only one of that channel number, the cycle keys don't do anything.
I like this idea far better than adding an sql dependency to VDR and I see no reason why the above would be difficult to implement or use. If I'm missing something, please let me know.
Well, first of all: there will be no SQL dependency in the core VDR ;-)
Once version 2.0 is finished, I'm planning on dealing with the "same channel from multiple sources" problem.
Klaus
Al 17/06/12 12:50, En/na Klaus Schmidinger ha escrit:
Well, first of all: there will be no SQL dependency in the core VDR ;-)
That's a pity, because channels.conf would be a perfect candidate for being an sqlite table. (Note that I said "sqlite", not "sql", but since sqlite uses sql it would allow for the more adventurous to substitute it for an heavy-weight database like postgresql or mysql). Bye
Once version 2.0 is finished, I'm planning on dealing with the "same channel from multiple sources" problem.
There is a related problem with the PCTV nanostick T2-usb receiver.
The nanostick T2 can receive C/T/T2 though the same antenna connector. Change between C and T is done the normal way and the stick works perfectly with vdr as long as the setup is simple enough.
However, there seems to be no way of telling the driver or vdr whether the nanostick is connected to C or T antenna cable. As far as I know I have the following alternatives:
1) Combiner. Build a combiner to connect both signals to the nanostick at the same time. I guess that would require me to measure the signal levels and use an attenuator or aplifier to match the levels. Then I'd need to build some band pass circuitry to select VHF and UHF frequencies from the T antenna and some others from cable. I don't exactly know how to do that and I don't have the necessary tools to measure the signal levels. However, if somebody is willing to do the math and design such a combiner I would definetly try to build one.
2) Fix the driver. Add a kernel module parameter to the driver that can be used to limit the available delivery systems visible to applications. This solution might need some extra work if order of the usb devices change randomly at each boot.
3) Vdr config. Make each channel use a certain receiver in vdr. This would be easy, but too limiting. For example if I had 2 receivers connected to T and 1 to C, I wouldn't like to pin the T-channels to a dedicated receiver when there are more than 2 T-multiplexes in the air.
4) Make some changes to vdr? Perhaps, but I think the option 2 would be better idea.
Here in Turku we have some channels that are FTA-available only on DVB-C and a channel that is FTA-available only on DVB-T2. The driver fix together with a fix to the "same channel from multiple sources" would help greatly in this situation too.
A side note: There is a bug or feature with the nanostick that has helped me a lot with my setup. A DVB-T channel marked to be DVB-T2 will work just fine. Due to some antenna issues, I can't receive some T multiplexes with my old receivers, but the nanosticks can receive them ok. I have set these channels to be DVB-T2 in channels.conf. Vdr selects one of the nanosticks when they need to be received. If this "bug" didn't exist, the same setup wouldn't be possible.
Why not just patch VDR so it cycles through channels that use the same channel number. No bothering with sql databases & dependency, no altering the real channel numbers, no real pain that I can think of. For example, say you have 3 different sources using the same channel number:
channel 100, dvb-s channel 100, dvb-t channel 100, dvb-c
You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop back to 100 dvb-s. Also, instead of having to enter the channel number to cycle through them, maybe just use different keys (skip +/-, ffw/rew, some other keys) to cycle. If there's only one of that channel number, the cycle keys don't do anything.
I have a similar idea that I've carried in my head for some time. The idea is to extend the "channel number" by another character, like '.'. That way you can store the dvb-s channel as 100.1, the dvb-t as 100.2, and so on. Or if you have the same channel in HD and SD, give SD the 100.3.
The channel number 100 would be an alias for one of the 100.x channels, ChUp/ChDown will go to 101 or 99 directly. Recordings for channel 100 will also pick the first available of them. By hitting a '.' key on the remote, you can still enter the sub level, where ChUp/ChDown cycles between 100.x channels, or for timers to record from a specific source. Hitting '.' again could return to the top level of numbers.
Of course this would require a rewrite of the channel numbering code, probably by making the current channel numbers internal only, and having an additional UI channel number as string. For the channels.conf syntax, this could be an extension to the :@ syntax, where :@. or :@100. or @100.1 starts a group of channels. And maybe an empty :@ to end the group without explicitly setting :@101 as next number.
Cheers,
Udo
On 17.06.2012 14:59, Udo Richter wrote:
Why not just patch VDR so it cycles through channels that use the same channel number. No bothering with sql databases& dependency, no altering the real channel numbers, no real pain that I can think of. For example, say you have 3 different sources using the same channel number:
channel 100, dvb-s channel 100, dvb-t channel 100, dvb-c
You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop back to 100 dvb-s. Also, instead of having to enter the channel number to cycle through them, maybe just use different keys (skip +/-, ffw/rew, some other keys) to cycle. If there's only one of that channel number, the cycle keys don't do anything.
I have a similar idea that I've carried in my head for some time. The idea is to extend the "channel number" by another character, like '.'. That way you can store the dvb-s channel as 100.1, the dvb-t as 100.2, and so on. Or if you have the same channel in HD and SD, give SD the 100.3.
The channel number 100 would be an alias for one of the 100.x channels, ChUp/ChDown will go to 101 or 99 directly. Recordings for channel 100 will also pick the first available of them. By hitting a '.' key on the remote, you can still enter the sub level, where ChUp/ChDown cycles between 100.x channels, or for timers to record from a specific source. Hitting '.' again could return to the top level of numbers.
Well, none of the remote controls I have has a '.' key.
Klaus
Am 17.06.2012 09:26, schrieb VDR User:
No bothering with sql databases& dependency
Sorry, I didn't say that clearly enough: The Channelpedia uses a sqlite database - but this doesn't mean at all that VDR core would need to use a sqlite database too. Both are totally independent from each other.
Cheers, Henning
I like the idea of external channels database. There is well known kingofsat site which is always up-to-date and inspite of scanning it could be easier to simply import channels definition from it. It for example could allow to import only channels from selected provider. I imagine it could be done via external plugin, hovewer I don't know if plugin is allowed to overwrite channels list Marx
On Sun, Jun 17, 2012 at 11:50 PM, Marx acc.for.news@gmail.com wrote:
I like the idea of external channels database. There is well known kingofsat site which is always up-to-date and inspite of scanning it could be easier to simply import channels definition from it. It for example could allow to import only channels from selected provider. I imagine it could be done via external plugin, hovewer I don't know if plugin is allowed to overwrite channels list
You can already manipulate channels.conf via svdrpsend commands. It wouldn't take much to write a script to do exactly what you're suggesting but without altering VDR or using a channel database.
Hi Henning,
First of all, thanks again for creating and continuing to offer such a service as the channelpedia.
Could you please tell us whether the channelpedia already provides an interface that an application can use to retrieve the uniqueID if a is passed to it? I can easily imagine plugins like the xmltv2vdr plugin sending requests to the channelpedia to match epg and channels.
Cheers,
Francesco
On Sun, 17 Jun 2012 08:47:20 +0200 Henning Pingel henning@henningpingel.de wrote:
Hi,
As some of you might already know, I'm working on a way to semi-automatically assign unique channel IDs to channels of different DVB providers. As I currently don't have time to explain it in detail today, I will just post some links and join this discussion later on when I have more time to sit down and explain stuff. ;-)
The whole thing is based on Channelpedia, a sub-project of the yaVDR distribution. It is a web-based channel string directory that can contain channels from different DVB providers and DVB types. It stores all data centrally in a SQLITE database. This makes it easy to work with the data and generate lookup tables for VDR core or plugins.
Demos: http://channelpedia.yavdr.com/gen/de_uniqueIDs2.html http://channelpedia.yavdr.com/gen/de_uniqueIDs.html (JSON files available for auto-assignment)
German language thread: http://www.vdr-portal.de/board1-news/board2-vdr-news/111607-announce-entwurf-channelpedia-generiert-automatisch-unique-kanal-ids/
Regards, Henning
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I intended to say: "if a NID-TID-SID is passed to it"
On Sun, 17 Jun 2012 09:33:08 +0200 Ludi ludi113@hotmail.com wrote:
Hi Henning,
First of all, thanks again for creating and continuing to offer such a service as the channelpedia.
Could you please tell us whether the channelpedia already provides an interface that an application can use to retrieve the uniqueID if a is passed to it? I can easily imagine plugins like the xmltv2vdr plugin sending requests to the channelpedia to match epg and channels.
Cheers,
Francesco
On Sun, 17 Jun 2012 08:47:20 +0200 Henning Pingel henning@henningpingel.de wrote:
Hi,
As some of you might already know, I'm working on a way to semi-automatically assign unique channel IDs to channels of different DVB providers. As I currently don't have time to explain it in detail today, I will just post some links and join this discussion later on when I have more time to sit down and explain stuff. ;-)
The whole thing is based on Channelpedia, a sub-project of the yaVDR distribution. It is a web-based channel string directory that can contain channels from different DVB providers and DVB types. It stores all data centrally in a SQLITE database. This makes it easy to work with the data and generate lookup tables for VDR core or plugins.
Demos: http://channelpedia.yavdr.com/gen/de_uniqueIDs2.html http://channelpedia.yavdr.com/gen/de_uniqueIDs.html (JSON files available for auto-assignment)
German language thread: http://www.vdr-portal.de/board1-news/board2-vdr-news/111607-announce-entwurf-channelpedia-generiert-automatisch-unique-kanal-ids/
Regards, Henning
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Henning Pingel -
Klaus Schmidinger -
Luca Olivetti -
Ludi -
Marx -
Mikko Tuumanen -
mtron -
Tony Houghton -
Udo Richter -
VDR User -
Wolfgang Rohdewald