Martin

2012/6/17 <vdr-request@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-request@linuxtv.org

You can reach the person managing the list at
vdr-owner@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@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.8040109@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@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.1020803@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@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@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.2090105@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@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-SMTP3102EF5DC657CF686CD410E8F90@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.Schmidinger@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.2030006@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@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
***********************************