vdr June 2012

vdr@linuxtv.org

35 participants
32 discussions

VDR on Centos/RHEL6
by Michael Schumacher 02 Jul '12

02 Jul '12

Hi everybody, I am trying for some days to get VDR running on my recent home server. This machine is running CENTOS6. There are various compiling errors and I am starting to wonder if somebody went through the installation process successfully? Any feedback would be welcome. -- Best regards, Michael mailto:Michael.S.Schumacher@gmx.de

3 5

Re: [vdr] Please share your systemd (Upstart) service file
by Steve Ross 29 Jun '12

29 Jun '12

Mika Laitio <lamikr(a)pilppa.org> wrote: >On 06/28/2012 08:02 PM, VDR User wrote: >> On Thu, Jun 28, 2012 at 12:01 AM, Ludwig Nussel <ludwig.nussel(a)suse.de> wrote: >> That would be a nice feature -- worth suggesting for the big `after >> 2.0 is released` redesign(?). But, there may be plugins which need to >> be initialized with certain values. Although, maybe it's possible to >> have those be reinitialized within vdr? > >Yeah, I would like to have option to pass path to plugin config file >for vdr-executable. Then somebody could write simple ui app for >configuting it via ui based on to plugins it finds from the PLUGINS dir. > >In the case of systemd, it's no need to have this vdr has died, unload >and load kernel module loop in the runvdr script, as those can be >specified also as a pre and post commands in systemd. > >Mika > > >> >> _______________________________________________ >> vdr mailing list >> vdr(a)linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > >_______________________________________________ >vdr mailing list >vdr(a)linuxtv.org >http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

1 0

[Announce] remotetimers 0.1.7
by Frank Schmirler 27 Jun '12

27 Jun '12

Hi, today I published remotetimers-0.1.7 on http://vdr.schmirler.de. It brings some minor bugfixes plus the following new features: With (at least) VDR 1.7.28: - Patch for new LCARS skin: Include remote timers in the main menu timers list - Calculate free disk space in minutes based on size and length of recordings as in VDR 1.7.27. Just like VDR only displays free disk space information for the video directory filesystem, VDR takes only recordings on the video directory filesystem into account when calculating the average data rate. Remotetimers' recordings menu will show the free disk space of the filesystem corresponding to the currently selected directory. Naturally the average data rate is then calculated based on this filesystem's recordings. - The whole average data rate calculation is a nice thing, but it's not very helpful if you have both, SD and HD recordings on the same filesystem. How about an estimated free disk space in minutes based on the data rate of an individual recording? Just select a recording in remotetimers' recordings menu and hit either red (Edit recording) or blue (Info). In addition to size and length of the recording you'll get the free minutes based on the data rate of this recording in the title bar. For all VDR versions: - By default remotetimers syncs timers using channel IDs. So the order of channels on client and server may be completely different. Now remotetimers could also use the channel number to sync timers. In this mode of course the channel lists on client and server must be identical or it will wreak havoc. You could of course swap e.g. the positions of HD and SD (or DVB-S and DVB-T) variants of the same channel. Imagine you have a client which cannot display HD (or receives DVB-T only) but you always want to record HD (or from DVB-S) on the server: Voilà - that's the solution. - If the server recordings are mounted on a subdirectory of the local video directory you can have remotetimers monitors the server's .update file to keep the local recordings list up to date. Now remotetimers will not only monitor the .update file, it will touch it whenever the local .update file changes. So when a client deletes a recording, the server and other clients monitoring the server's .update file will update their recordings lists. CHANGELOG - If server recordings are mounted in a subdirectory of local video dir, make server and other clients aware of changes made by this client. - Fixed occasionally missed video directory mounts during startup. Now getting mtime and device id of .update file already in SetupParse(), i.e. before VDR starts to scan recordings. - Updated Slovak translations (thanks to Milan Hrala) - Added vdr-1.7.28-remote_instant_recordings.patch to display remote timers in skin LCARS' main menu view - Fixed RemoteTimers::ForEach service call - With 1.7.28 or newer, show remaining disk space in minutes based on size and length of currently selected recording in menus "Recording info" and "Edit recording". - With 1.7.28 or newer, calculate remaining disk space in minutes based on size and length of all recordings on current filesystem. - Updated Italian translations (thanks to Diego Pierotto) - Updated the menu parts copied from VDR to 1.7.28 - New option to map channels by number instead of channel id when syncing between client and server. Useful if you want to view and record different variants of a simulcast channel on client and server (e.g. HD/SD or DVB-T/ DVB-S). Requires channels to be in same order (suggested by woz@vdrportal) - API changes of VDR 1.7.28 - Updated MainMenuHooks patch (thanks to Manuel Reimer) - Fixed compile error due to unknown type 'tI18nPhrase' - Released recordings must be re-read or they reappear in recordings menu Have fun, Frank

1 0

distribution of systemd service file
by Paul Menzel 27 Jun '12

27 Jun '12

Dear VDR folks, I just noticed that Davide Cavalca added an systemd [1] service file for VDR to OpenBricks [2]. Is it useful to get this included upstream, so that all distributions can use it? I just found this one comment, that these service files supposed to be uniform between distributions [3]. On the other hand I did not find any init scripts in the VDR source. Thanks, Paul PS: Please do not use this thread to discuss different init systems. [1] http://www.freedesktop.org/wiki/Software/systemd [2] http://hg.openbricks.org/openbricks-next/rev/c532ffce1712 [3] http://bheekly.blogspot.com/2010/08/systemd-in-gentoo.html?showComment=1282…

2 2

xine-plugin; 16x9 no-signal image
by Torgeir Veimo 26 Jun '12

26 Jun '12

I'm unable to change the no-signal image to always be shown in 16x9. Is there an easy way? All my sources are 16x9, and when using OSD blending, getting a 4x3 image on each channel change looks really bad. -- -Tor

2 2

Patch to put disk usage back in main & recording menus (vdr-1.7.28) for text2skin/anthra
by VDR User 24 Jun '12

24 Jun '12

Hi. I was wondering if anyone has a patch that puts the disk usage back into the title of the main & recording menus when using the anthra (anthra_1920_OSE to be exact) with text2skin? After the following change in vdr, there's no way to know how much free space is on my recording drive without manually checking outside of vdr, and that's very inconvenient. - The disk usage is no longer automatically added to the title of the main and "Recordings" menus. This has always been a mekeshift solution and it is now up to the individual skin if, where and how it wants to display this information. A skin can use the new cVideoDiskUsage class to implement such a display. For compatibility, the default skins "Classic VDR", "ST:TNG Panels" and "Text mode" (i.e. curses) have been changed to behave like before. Other skins may want to display the disk usage in totally different ways. Thanks

2 2

Plugin for MHEG (BBC RedButton service)
by John Williams 21 Jun '12

21 Jun '12

Hello, I have adapted the standalone "redbutton" program (http://redbutton.sourceforge.net/) into a plugin for VDR. This allows me to view the "Redbutton" data service broadcast by the BBC. This is a preliminary version of the plugin and it is not robust enough for general use, but if anyone would like to experiment with it, the source code can be downloaded from http://pond-weed.com/redbutton/ Regards, John Williams

6 8

Collecting semantic channel meta data in a way to be useful for VDR
by Henning Pingel 18 Jun '12

18 Jun '12

Hi, I posted in the discussion "RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C" yesterday and mentioned that my little project Channelpedia could be helpful in this regard. But because my approach is more targeting the necessary semantic meta data that would be necessary for those advanced features, I would like to explain my ideas in a different thread. When I started to work on Channelpedia my goal was to offer a website where different VDR channel lists of different DVB providers could be easily stored, sorted and regularly updated in an easy way. The main audience were new VDR users who often are overwhelmed by the amount of channels offered by their DVB source (in particular satellite sources). Technically, Channelpedia is a PHP web application that uses a sqlite database and offers to upload channel data and retreive channel data in different ways (static generated HTML pages + a small RESTful JSON interface). Channelpedia is not a VDR addon and not a VDR plugin. The coding is completely independet from VDR and it can't be plugged into VDR in any way. Now that there are a couple of different DVB providers in the Channelpedia database, I thought it would make sense to additionally collect semantic meta data for channels in a provider independent way. This semantic data can be gathered and stored in Channelpedia, but in the end it should be easily exportable from Channelpedia. For example in a single textfile, so that this textfile could be used by VDR plugins (or even VDR core) for lookups. The basic idea is that this textfile has a certain structure (could also be XML or JSON) and that anybody could create this data file by typing it all down manually. But Channelpedia on the other hand could create this file in an automated way so that it is rarely necessary to maintain that file manually. At this time, Channelpedia collects some of this meta data only for channels relevant for German language countries (due to the amount of work involved I have limited it to German channels for now). I will now give an example of the kind of metadata I would like to collect per channel: All this metadata below is not specific to one single DVB provider. Instead it should be usable for any provider (C,T,S,I,...) that offers the respective channel. * Country/countries where the organization is based that offers the channel (problems might arise with cooperations: 3sat is a joint effort of Germany, Austria, Switzerland) * Primary region of the audience: Where does the indended audience live? Which language do they speak? * Website URI of the channel (Wikipedia page of this channel + the website of the organization) * Type of channel (Kids entertainment, Music, Crime, Sport, ....) * Channel logo resources for this channel that can be found on the web * List of existing EPG web services (that offer an XML based epg for this channel) * Existing channel variants with the completely the same or nearly the same epg: - Time-shift-versions (+1, +2, +24): List of other channels that have the same epg but a timeshift offset - Regional variants (BBC 1 London, BBC 1 Oxford, ... / WDR Aachen, WDR Köln, WDR ....): List of other channels that share 95% of the EPG but have "regional windows" - Quality/Bandwidth variants (SD, HD, different bitrates, DVB-T offers less quality in Germany compared to SD via DVB-C/S): List of channel alternatives that offer a higher or lower picture quality) - Reference to root channel (the "root" channel is the predecessor of all other variants) * CA-status: This channel regularly changes from FTA to scrambled or is permanently scrambled. * Which pay-TV packages / platforms have got this channel in their portfolio To store all this metadata for a channel, the channel needs a unique ID that is different from the technical unique ID that VDR uses internally (Source-NID-TID-SID, for a more detailed explanation of this ID please read VDR man page). The technical IDs of VDR are only used to identify a channel within the channels.conf of one VDR user and his active DVB providers. But we need IDs that are able to identify channels across different providers. Therefore we have to make them up ourselves, based on their channel name. I want to call them Channelpedia IDs for now - short: CPID, to make it easier to talk about them. But the NID-TID and SID still remain very important. If we put all the NID-TID-SID data into the metadata too, we can use them to automatically assign a channel in a channels.conf to a CPID. Regarding German channels, the DVB-C sometimes reuse the same NID-TID-SID of the channel on satellite. This means that we can hope that we don't have to store as many variants of NID-TID-SID in the metadata as there are providers out there. I guess this metadata collection can never be complete or completely accurate, but even if it doesn't contain all those channels out there it could still be very helpful for VDR plugins. Example: I create a searchtimer using epgsearch and epgsearch is able to look up all channel siblings in my local channels.conf that share the same EPG with the channel that I have currently selected. Now, epgsearch could give me choices: "Do you want to record the HD version of this channel? Is SD quality good enought? etc." Further infos: <http://channelpedia.yavdr.com/> 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-entwur…> Regards, Henning

2 2

RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C
by Ludi 18 Jun '12

18 Jun '12

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/… 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

11 32

Re: [vdr] RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C
by Martin 17 Jun '12

17 Jun '12

And what about adding the satellite position to the source name? Martin 2012/6/17 <vdr-request(a)linuxtv.org> > Send vdr mailing list submissions to > vdr(a)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(a)linuxtv.org > > You can reach the person managing the list at > vdr-owner(a)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(a)tvdr.de> > To: vdr(a)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(a)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(a)tvdr.de> > To: vdr(a)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(a)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(a)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(a)ventoso.org> > To: VDR Mailing List <vdr(a)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(a)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(a)hotmail.com> > To: VDR Mailing List <vdr(a)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(a)phx.gbl> > Content-Type: text/plain; charset="US-ASCII" > > On Sun, 17 Jun 2012 12:44:06 +0300 > Tony Houghton <h(a)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(a)tvdr.de> > To: vdr(a)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(a)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(a)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/… > >>> > >>> 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 >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr June 2012