And what about adding the satellite position to the source name? Martin
2012/6/17 <vdr-requ...@linuxtv.org> > Send vdr mailing list submissions to > vdr@linuxtv.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > or, via email, send a message with subject or body 'help' to > vdr-requ...@linuxtv.org > > You can reach the person managing the list at > vdr-ow...@linuxtv.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vdr digest..." > > > Today's Topics: > > 1. Re: RFE: Make VDR more friendly when using combinations of > DVB-S, DVB-T and DVB-C (Klaus Schmidinger) > 2. Re: RFE: Make VDR more friendly when using combinations of > DVB-S, DVB-T and DVB-C (Klaus Schmidinger) > 3. Re: RFE: Make VDR more friendly when using combinations of > DVB-S, DVB-T and DVB-C (Luca Olivetti) > 4. Re: RFE: Make VDR more friendly when using combinations of > DVB-S, DVB-T and DVB-C (Ludi) > 5. Re: RFE: Make VDR more friendly when using combinations of > DVB-S, DVB-T and DVB-C (Klaus Schmidinger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 17 Jun 2012 12:48:20 +0200 > From: Klaus Schmidinger <klaus.schmidin...@tvdr.de> > To: vdr@linuxtv.org > Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations > of DVB-S, DVB-T and DVB-C > Message-ID: <4fddb5f4.8040...@tvdr.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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 > > > > ------------------------------ > > Message: 2 > Date: Sun, 17 Jun 2012 12:50:59 +0200 > From: Klaus Schmidinger <klaus.schmidin...@tvdr.de> > To: vdr@linuxtv.org > Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations > of DVB-S, DVB-T and DVB-C > Message-ID: <4fddb693.1020...@tvdr.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 17.06.2012 09:26, VDR User wrote: > > On Sat, Jun 16, 2012 at 11:47 PM, Henning Pingel > > <henn...@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 > > > > ------------------------------ > > Message: 3 > Date: Sun, 17 Jun 2012 13:09:24 +0200 > From: Luca Olivetti <l...@ventoso.org> > To: VDR Mailing List <vdr@linuxtv.org> > Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations > of DVB-S, DVB-T and DVB-C > Message-ID: <4fddbae4.2090...@ventoso.org> > Content-Type: text/plain; charset=ISO-8859-1 > > 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 > -- > Luca > > > > ------------------------------ > > Message: 4 > Date: Sun, 17 Jun 2012 14:00:39 +0200 > From: Ludi <ludi...@hotmail.com> > To: VDR Mailing List <vdr@linuxtv.org> > Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations > of DVB-S, DVB-T and DVB-C > Message-ID: <blu0-smtp3102ef5dc657cf686cd410e8...@phx.gbl> > Content-Type: text/plain; charset="US-ASCII" > > 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 > > > > ------------------------------ > > Message: 5 > Date: Sun, 17 Jun 2012 14:16:53 +0200 > From: Klaus Schmidinger <klaus.schmidin...@tvdr.de> > To: vdr@linuxtv.org > Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations > of DVB-S, DVB-T and DVB-C > Message-ID: <4fddcab5.2030...@tvdr.de> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > 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 Schmidinger<klaus.schmidin...@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/110156-%C3%BCberlegungen-zur-channels-conf-f%C3%BCr-dvb-c-s-t-mischbetrieb/index3.html > >>> > >>> 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 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: vdr-1.7.28-channelnameswithsource.diff > Type: text/x-patch > Size: 4611 bytes > Desc: not available > URL: < > http://www.linuxtv.org/pipermail/vdr/attachments/20120617/98e83de5/attachment.bin > > > > ------------------------------ > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > End of vdr Digest, Vol 89, Issue 21 > *********************************** >
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
