Hi!
Look at streamdev plugin (plus remotetimers), this will solve your problem.
Regards
Marco
Am 03.01.2011 23:29, schrieb Mika Laitio:
The second thing is the tuning. "Get next channel on this transponder"
sounds simple, but actually deciding whether a channel is tuneable
involves 17 differ
> The second thing is the tuning. "Get next channel on this transponder"
> sounds simple, but actually deciding whether a channel is tuneable
> involves 17 different rules that get checked against each device, plus
> probing the CAM whether the channel can be decoded by the CAM. I think
> that part
On 27.12.2010 13:07, Jochen Dolze wrote:
> Am 12.12.2010 16:19, schrieb Klaus Schmidinger:
>> Hmm, I see.
>> So how about changing cEIT in such a way that it never overwrites
>> any events in a schedule if the first existing event in that schedule
>> has a table id of 0?
>
> There are three usecas
On 14.12.2010 12:18, Dominic Evans wrote:
> On 14 December 2010 10:49, Eric Valette wrote:
>>> On 17 March 2010 07:59, william wrote:
>>> I have made some other changes. and also got an update from Rob Davis.
>>> which added ratings and credits
>>>
>>> see: http://cobradevil.org/downloads/xmltv2v
Am 12.12.2010 16:19, schrieb Klaus Schmidinger:
Hmm, I see.
So how about changing cEIT in such a way that it never overwrites
any events in a schedule if the first existing event in that schedule
has a table id of 0?
There are three usecases for adding EPG-Data:
1. Using EIT-EPG as it is
2. Ad
On Sun, Dec 19, 2010 at 2:43 AM, Manuel Reimer wrote:
>> You actually make an important point. VDR was never designed with
>> server/client in mind.
>
> But there are plugins out there, that can add exactly what you need. One of
> them is "streamdev", which does a very good job.
I disagree abou
Hello,
> You actually make an important point. VDR was never designed with
> server/client in mind.
But there are plugins out there, that can add exactly what you need. One of
them is "streamdev", which does a very good job.
Not anyone wants a client/server setup, so why should those people, n
On 18/12/2010 14:33, Udo Richter wrote:
Am 17.12.2010 22:58, schrieb Pasi Juppo:
That said and with no disrespect to the author of vdr in my opinion it
starts to be a time to fork vdr and redefine its base + few other
elements.
Of course things can remain the same but will we ever see natively
On Sat, Dec 18, 2010 at 5:33 AM, Udo Richter wrote:
> Am 17.12.2010 22:58, schrieb Pasi Juppo:
>> That said and with no disrespect to the author of vdr in my opinion it
>> starts to be a time to fork vdr and redefine its base + few other
>> elements.
>>
>> Of course things can remain the same but
Am 17.12.2010 22:58, schrieb Pasi Juppo:
> That said and with no disrespect to the author of vdr in my opinion it
> starts to be a time to fork vdr and redefine its base + few other
> elements.
>
> Of course things can remain the same but will we ever see natively
> implemented in vdr:
> -_proper_
Dear Pasi,
it is a great idea to fork a new line and rewrite code to satisfy all
requests which been put forward.
Please let me know when you will set a repository and write stable code
so that I could give it a try. Please make changes quick so that people
who was waiting for this changes h
On 12/15/2010 10:49 PM, Ville Skyttä wrote:
On Wednesday 15 December 2010, Jouni Karvo wrote:
>
> I think adding dependencies to outside packages is a burden that
> should be avoided. There are already many things I need to install
> separately in order the vdr box to work; kernel, graphics dri
On Wednesday 15 December 2010, Jouni Karvo wrote:
>
> I think adding dependencies to outside packages is a burden that should
> be avoided. There are
> already many things I need to install separately in order the vdr box to
> work; kernel, graphics
> drivers, and xine-lib. Luckily, lirc is now a
Al 15/12/10 20:57, En/na Jouni Karvo ha escrit:
I don't understand what would be easy in using SQL. Since the
channels.conf-code is already there,
and pretty stable, then obviously rewriting that to SQL is not "easy",
but instead additional work.
Justifying additional work needs some reason.
W
Al 15/12/10 20:35, En/na VDR User ha escrit:
On Wed, Dec 15, 2010 at 9:21 AM, Luca Olivetti wrote:
Instead of speculating I actually tried.
I created a test database with the contents of my channels.conf (only
containing the number, name, frequency, source, symbol rate and the vpid,
I
don't thi
I don't understand what would be easy in using SQL. Since the
channels.conf-code is already there,
and pretty stable, then obviously rewriting that to SQL is not "easy",
but instead additional work.
Justifying additional work needs some reason.
I think adding dependencies to outside packages
On Wed, Dec 15, 2010 at 9:21 AM, Luca Olivetti wrote:
>>> Instead of speculating I actually tried.
>>> I created a test database with the contents of my channels.conf (only
>>> containing the number, name, frequency, source, symbol rate and the vpid,
>>> I
>>> don't think adding all the fields wou
Al 15/12/10 00:19, En/na VDR User ha escrit:
On Tue, Dec 14, 2010 at 12:56 PM, Luca Olivetti wrote:
Instead of speculating I actually tried.
I created a test database with the contents of my channels.conf (only
containing the number, name, frequency, source, symbol rate and the vpid, I
don't th
Steffen Barszus wrote:
> well the point was to make it simpler, improving something. This goal
> would be missed by that.
"simple" is a matter of definition. I think the VDR built-in handlers of
configuration files are very simple with the big benefit of being plain text.
Yours
Manuel
--
() a
On Tue, 14 Dec 2010 21:46:52 +0100
Udo Richter wrote:
> Actually, no one stops you from doing lots of things from within a
> plugin. The EPG system of VDR has even a multithread safe interface,
> so you could constantly scan for changes and propagate your own
> changes. Keeping some SQL database
On Tue, Dec 14, 2010 at 12:56 PM, Luca Olivetti wrote:
> Instead of speculating I actually tried.
> I created a test database with the contents of my channels.conf (only
> containing the number, name, frequency, source, symbol rate and the vpid, I
> don't think adding all the fields would change t
Am 14.12.2010 21:56, schrieb Luca Olivetti:
> Instead of speculating I actually tried.
> I created a test database with the contents of my channels.conf (only
> containing the number, name, frequency, source, symbol rate and the
> vpid, I don't think adding all the fields would change the result
>
Am 14.12.2010 21:20, schrieb Luca Olivetti:
> Right now I have a recording going on. If I press the "up" channel past
> the last channel on the same transponder, vdr is unresponsive for ~30
> seconds.
> I guess that sqlite, with a well formulated query and the right indexes,
> would take a fraction
Al 14/12/10 21:20, En/na Luca Olivetti ha escrit:
Al 13/12/10 11:34, En/na Steffen Barszus ha escrit:
That was my point in the beginning. Then: I want to see sqlite3 being
less efficient on insert and fetch or memory consumption. I can not
imagine it (prove me wrong! ;)). Last but not least i
Am 14.12.2010 20:20, schrieb Steffen Barszus:
> 1.) Klaus doesnt like it, also does not like to make it possible to do
> it in a plugin.
Actually, no one stops you from doing lots of things from within a
plugin. The EPG system of VDR has even a multithread safe interface, so
you could constantly s
Al 13/12/10 11:34, En/na Steffen Barszus ha escrit:
That was my point in the beginning. Then: I want to see sqlite3 being
less efficient on insert and fetch or memory consumption. I can not
imagine it (prove me wrong! ;)). Last but not least i don't think any
user would even notice any differen
On Tue, 14 Dec 2010 10:31:03 +0100 (CET)
"Gerald Dachs" wrote:
> > Am 13.12.2010 23:21, schrieb Gerald Dachs:
> > >
> >> Maybe I understand the code in epg.c wrong, but it look like that
> >> the whole epg.data file is always read and write complete by the
> >> vdr. Even if only one record has t
On 14.12.2010 16:21, Theunis Potgieter wrote:
e.g. vdr-xineliboutput is dependent on xine-lib. If xine-lib updated
then it would make sense to recompile vdr-xineliboutput again.
Off Topic: vdr-xineliboutput- is currently broken.
___
vdr mailing l
On 14 December 2010 12:49, Eric Valette wrote:
> On 12/14/2010 10:13 AM, Theunis Potgieter wrote:
>
>> Gave Gentoo a try? Once you updated vdr, all you need to run on Gentoo
>> is: vdrplugin-rebuild all
>
> I'm not going to try gentoo. However, if this works that is great alltough
> you should pro
On 14 December 2010 10:49, Eric Valette wrote:
>> On 17 March 2010 07:59, william wrote:
>> I have made some other changes. and also got an update from Rob Davis.
>> which added ratings and credits
>>
>> see: http://cobradevil.org/downloads/xmltv2vdr-1.0.9.tar.gz
>
> Thanks for the pointer. Howev
On 12/14/2010 10:13 AM, Theunis Potgieter wrote:
Gave Gentoo a try? Once you updated vdr, all you need to run on Gentoo
is: vdrplugin-rebuild all
I'm not going to try gentoo. However, if this works that is great
alltough you should probably recompiled vdr depending on the plugin code
you ins
> Am 13.12.2010 23:21, schrieb Gerald Dachs:
> >
>> Maybe I understand the code in epg.c wrong, but it look like that the
>> whole epg.data file is always read and write complete by the vdr. Even
>> if only one record has to be changed. Maybe the coding with sqlite will
>> look less elegant, but i
On 12 December 2010 23:50, Eric Valette wrote:
>
> On 12/12/2010 20:29, Steffen Barszus wrote:
>
>> external epg source is possible allready - i just think the merge and
>> general handling could be improved :)
>
> If you try to prove everything is possible via plugin yes. Vdr could even be
> sim
On Mon, Dec 13, 2010 at 2:53 PM, Helmut Auer wrote:
>> Maybe I understand the code in epg.c wrong, but it look like that the
>> whole epg.data file is always read and write complete by the vdr. Even
>> if only one record has to be changed. Maybe the coding with sqlite will
>> look less elegant, bu
Am 13.12.2010 23:21, schrieb Gerald Dachs:
>
Maybe I understand the code in epg.c wrong, but it look like that the
whole epg.data file is always read and write complete by the vdr. Even
if only one record has to be changed. Maybe the coding with sqlite will
look less elegant, but it will be much
Am Mon, 13 Dec 2010 22:19:45 +0100
schrieb Udo Richter :
> Never under-estimate a native C/C++ coded data structure, at least if
> it's a smart one. Reading/writing to a tree or hash might be done
> before the sql interpreter even starts.
Maybe I understand the code in epg.c wrong, but it look li
On 13/12/10 21:19, Udo Richter wrote:
Am 13.12.2010 11:34, schrieb Steffen Barszus:
That was my point in the beginning. Then: I want to see sqlite3 being
less efficient on insert and fetch or memory consumption. I can not
imagine it (prove me wrong! ;)).
Correct me if I'm wrong, but for sqlite
On Mon, 13 Dec 2010 22:19:45 +0100
Udo Richter wrote:
> Am 13.12.2010 11:34, schrieb Steffen Barszus:
> > That was my point in the beginning. Then: I want to see sqlite3
> > being less efficient on insert and fetch or memory consumption. I
> > can not imagine it (prove me wrong! ;)).
>
> Correc
Am 13.12.2010 11:34, schrieb Steffen Barszus:
> That was my point in the beginning. Then: I want to see sqlite3 being
> less efficient on insert and fetch or memory consumption. I can not
> imagine it (prove me wrong! ;)).
Correct me if I'm wrong, but for sqlite you'll have to convert all these
n
En/na Klaus Schmidinger ha escrit:
Of course, but they are *simple* databases ;-)
I don't want VDR to become dependent on some particular database software.
And I like the fact that these files are plain readable text files.
text files, yes, plain readable, no (with all special symbols, specia
On Mon, 13 Dec 2010 12:14:48 +0100
Klaus Schmidinger wrote:
> On 12/13/10 11:49, Steffen Barszus wrote:
> > On Sun, 12 Dec 2010 23:33:13 +0100
> > Klaus Schmidinger wrote:
> >
> >> On 12.12.2010 18:21, Steffen Barszus wrote:
> >>> If we can be sure that between clre and adding the external epg
On 12/13/2010 01:44 PM, Klaus Schmidinger wrote:
On 12/13/10 13:40, Eric Valette wrote:
On 12/13/2010 12:14 PM, Klaus Schmidinger wrote:
Of course, but they are *simple* databases ;-)
xmltv format is ascii also ;-)
So?
so you could use another source to feed your ascii database.
-- eric
On 12/13/10 13:40, Eric Valette wrote:
> On 12/13/2010 12:14 PM, Klaus Schmidinger wrote:
>
>> Of course, but they are *simple* databases ;-)
>
> xmltv format is ascii also ;-)
So?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi
On 12/13/2010 12:14 PM, Klaus Schmidinger wrote:
Of course, but they are *simple* databases ;-)
xmltv format is ascii also ;-)
-- eric
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-Original Message-
>>> Having epg in a DB (sqlite,mysql) might also be nice.
>>
>> Definiteley *no* database in VDR!
>> I've said it on many occasions, and I'll repeat it as many times
>> as necessary! If you want to handle EPG data in a database, do it
>> externally and feed the resultin
On 12/13/10 11:49, Steffen Barszus wrote:
> On Sun, 12 Dec 2010 23:33:13 +0100
> Klaus Schmidinger wrote:
>
>> On 12.12.2010 18:21, Steffen Barszus wrote:
>>> If we can be sure that between clre and adding the external epg no
>>> event comes into vdr by cEIT, means it can be ensured that this
>>>
On Sun, 12 Dec 2010 23:33:13 +0100
Klaus Schmidinger wrote:
> On 12.12.2010 18:21, Steffen Barszus wrote:
> > If we can be sure that between clre and adding the external epg no
> > event comes into vdr by cEIT, means it can be ensured that this
> > holds true for any stations external epg is used
On Mon, 13 Dec 2010 00:00:27 +
Tony Houghton wrote:
> On 12/12/10 22:33, Klaus Schmidinger wrote:
> > On 12.12.2010 18:21, Steffen Barszus wrote:
> >> Having epg in a DB (sqlite,mysql) might also be nice.
> >
> > Definiteley *no* database in VDR!
> > I've said it on many occasions, and I'll r
On 13/12/2010 08:21, Eric Valette wrote:
On 12/12/2010 23:44, Klaus Schmidinger wrote:
I always find it amusing how people consider the GUI so important.
Come on! It's a *video recorder* for cryin' out loud! It's main
purpose is to record and replay tv broadcasts.
I know its the main purpose
On 12/12/2010 23:44, Klaus Schmidinger wrote:
I always find it amusing how people consider the GUI so important.
Come on! It's a *video recorder* for cryin' out loud! It's main
purpose is to record and replay tv broadcasts.
I know its the main purpose but do not forget that in order to record,
On Sun, Dec 12, 2010 at 2:44 PM, Klaus Schmidinger
wrote:
> I always find it amusing how people consider the GUI so important.
> Come on! It's a *video recorder* for cryin' out loud! It's main
> purpose is to record and replay tv broadcasts. The menus are tools
> that allow the user to program tim
On 12/12/10 22:33, Klaus Schmidinger wrote:
On 12.12.2010 18:21, Steffen Barszus wrote:
Having epg in a DB (sqlite,mysql) might also be nice.
Definiteley *no* database in VDR!
I've said it on many occasions, and I'll repeat it as many times
as necessary! If you want to handle EPG data in a dat
On 12.12.2010 19:46, Eric Valette wrote:
> On 12/12/2010 19:24, VDR User wrote:
>> On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel
>> wrote:
> Having epg in a DB (sqlite,mysql) might also be nice.
You are going to find a lot of opposition to this. Thinking of sql, I
don't recall
On 12.12.2010 18:21, Steffen Barszus wrote:
> On Sun, 12 Dec 2010 16:19:00 +0100
> Klaus Schmidinger wrote:
>
>> On 09.12.2010 07:59, Steffen Barszus wrote:
>>> On Wed, 08 Dec 2010 23:22:05 +0100
>>> Klaus Schmidinger wrote:
On 08.12.2010 20:25, Jochen Dolze wrote:
> To be able using ot
On 12/12/2010 20:29, Steffen Barszus wrote:
external epg source is possible allready - i just think the merge and
general handling could be improved :)
If you try to prove everything is possible via plugin yes. Vdr could
even be simply a plugin loader as someone else suggested. The problem
f
On Sun, 12 Dec 2010 19:46:32 +0100
Eric Valette wrote:
> On 12/12/2010 19:24, VDR User wrote:
> > On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel
> > wrote:
> Having epg in a DB (sqlite,mysql) might also be nice.
> >>>
> >>> You are going to find a lot of opposition to this. Thinking of
> >>
On 12/12/2010 19:24, VDR User wrote:
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel
wrote:
Having epg in a DB (sqlite,mysql) might also be nice.
You are going to find a lot of opposition to this. Thinking of sql, I
don't recall ever hearing anyone suggest VDR using it would be a good
idea but
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel
wrote:
>> > Having epg in a DB (sqlite,mysql) might also be nice.
>>
>> You are going to find a lot of opposition to this. Thinking of sql, I
>> don't recall ever hearing anyone suggest VDR using it would be a good
>> idea but I have heard people will
Am Sonntag, den 12.12.2010, 09:33 -0800 schrieb VDR User:
> On Sun, Dec 12, 2010 at 9:21 AM, Steffen Barszus
> wrote:
> > Having epg in a DB (sqlite,mysql) might also be nice.
>
> You are going to find a lot of opposition to this. Thinking of sql, I
> don't recall ever hearing anyone suggest VDR
On Sun, Dec 12, 2010 at 9:21 AM, Steffen Barszus
wrote:
> Having epg in a DB (sqlite,mysql) might also be nice.
You are going to find a lot of opposition to this. Thinking of sql, I
don't recall ever hearing anyone suggest VDR using it would be a good
idea but I have heard people will look into
On Sun, 12 Dec 2010 16:19:00 +0100
Klaus Schmidinger wrote:
> On 09.12.2010 07:59, Steffen Barszus wrote:
> > On Wed, 08 Dec 2010 23:22:05 +0100
> > Klaus Schmidinger wrote:
> >> On 08.12.2010 20:25, Jochen Dolze wrote:
> >>> To be able using other epg sources with other event ids as from
> >>>
On 09.12.2010 07:59, Steffen Barszus wrote:
> On Wed, 08 Dec 2010 23:22:05 +0100
> Klaus Schmidinger wrote:
>> On 08.12.2010 20:25, Jochen Dolze wrote:
>>> To be able using other epg sources with other event ids as from the
>>> broadcaster. Today i cannot add 14 days of external epg without
>>> pa
On Wed, 08 Dec 2010 23:22:05 +0100
Klaus Schmidinger wrote:
> On 08.12.2010 20:25, Jochen Dolze wrote:
> > To be able using other epg sources with other event ids as from the
> > broadcaster. Today i cannot add 14 days of external epg without
> > patching.
>
> Why would you have to patch VDR for
On 08.12.2010 20:25, Jochen Dolze wrote:
> Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
>> On 05.12.2010 23:01, Jochen Dolze wrote:
>>> i would like to implement an parameter to disable the epg scan for
>>> (some) channels. I think an parameter in the channels.conf-file would be
>>> the best pla
Am 06.12.2010 21:30, schrieb Udo Richter:
Generally, however, there are a lot of similar needs to influence how
VDR does its several automatic scans. Maybe it's time for a generic
plugin interface that allows to filter incoming EPG data, channel scan
data, transponder data and so on, that allows
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
On 05.12.2010 23:01, Jochen Dolze wrote:
i would like to implement an parameter to disable the epg scan for
(some) channels. I think an parameter in the channels.conf-file would be
the best place. So, E0 means dont scan, E1 or absence of the E-para
Am 06.12.2010 13:38, schrieb Mario Schulz:
> My previous platform had selectable EPG scans.
> When I first got into touch with VDR, I asked myself, how I was supposed
> to restrict searchtimers to interesting channels.
So you want to cut off EPG data for these channels just because
epgsearch shoul
2010/12/5 Klaus Schmidinger :
> On 05.12.2010 23:01, Jochen Dolze wrote:
>> Hi,
>>
>> i would like to implement an parameter to disable the epg scan for
>> (some) channels. I think an parameter in the channels.conf-file would be
>> the best place. So, E0 means dont scan, E1 or absence of the E-para
I'm seeing two different things talked about here. One is not to scan
EPG data on some channels and that does seem like something that belongs
in the channels.conf. I use the web vdradmin and epg search for shows to
record can be limited to a range of channels but they must be grouped
together
On Mon, 6 Dec 2010, Mario Schulz wrote:
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
What would that be necessary for?
I'd like to prevent EIT scans on IPTV devices.
In its default behaviour VDR will add transponders and channels to the
channels.conf, as a result these will be searched a
Hi,
> I don't see the advantage of implementing this directly into the VDR.
I do and would love to see this feature.
My cable TV provider offers several regional variations of the same TV
channel (*). They will show the same shows most of the time and differ
only for a regional broadcast once or
On 6 December 2010 15:16, Denis Loh wrote:
>
> I don't see the advantage of implementing this directly into the VDR. The
> parameter must be maintained by the user, so it should be an additional
> configuration file which is independend from the channels.conf, as this file
> is and should only
I don't see the advantage of implementing this directly into the VDR. The
parameter must be maintained by the user, so it should be an additional
configuration file which is independend from the channels.conf, as this file
is and should only used for channel information. NOEPG and NOEPGMENU do this
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
> What would that be necessary for?
My previous platform had selectable EPG scans.
When I first got into touch with VDR, I asked myself, how I was supposed
to restrict searchtimers to interesting channels.
In its default behaviour VDR will add tran
On 05.12.2010 23:01, Jochen Dolze wrote:
> Hi,
>
> i would like to implement an parameter to disable the epg scan for
> (some) channels. I think an parameter in the channels.conf-file would be
> the best place. So, E0 means dont scan, E1 or absence of the E-parameter
> means scan the channel.
Wha
Hi,
i would like to implement an parameter to disable the epg scan for
(some) channels. I think an parameter in the channels.conf-file would be
the best place. So, E0 means dont scan, E1 or absence of the E-parameter
means scan the channel.
I only start investing my time if it has an chance
76 matches
Mail list logo
