[vdr] RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C

Martin rekordc at gmail.com
Sun Jun 17 16:17:00 CEST 2012


And what about adding the satellite position to the source name?

Martin

2012/6/17 <vdr-request at linuxtv.org>

> Send vdr mailing list submissions to
>        vdr at 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-request at linuxtv.org
>
> You can reach the person managing the list at
>        vdr-owner at 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.Schmidinger at tvdr.de>
> To: vdr at linuxtv.org
> Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations
>        of DVB-S, DVB-T and DVB-C
> Message-ID: <4FDDB5F4.8040109 at 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.Schmidinger at tvdr.de>
> To: vdr at linuxtv.org
> Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations
>        of DVB-S, DVB-T and DVB-C
> Message-ID: <4FDDB693.1020803 at 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
> > <henning at 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 <luca at ventoso.org>
> To: VDR Mailing List <vdr at linuxtv.org>
> Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations
>        of DVB-S, DVB-T and DVB-C
> Message-ID: <4FDDBAE4.2090105 at 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 <ludi113 at hotmail.com>
> To: VDR Mailing List <vdr at linuxtv.org>
> Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations
>        of DVB-S, DVB-T and DVB-C
> Message-ID: <BLU0-SMTP3102EF5DC657CF686CD410E8F90 at phx.gbl>
> Content-Type: text/plain; charset="US-ASCII"
>
> On Sun, 17 Jun 2012 12:44:06 +0300
> Tony Houghton <h at 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.Schmidinger at tvdr.de>
> To: vdr at linuxtv.org
> Subject: Re: [vdr] RFE: Make VDR more friendly when using combinations
>        of DVB-S, DVB-T and DVB-C
> Message-ID: <4FDDCAB5.2030006 at 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.Schmidinger at 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 at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> End of vdr Digest, Vol 89, Issue 21
> ***********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20120617/a4cd31aa/attachment-0001.html>


More information about the vdr mailing list