drivers with another Twinhan DVB-S2 card (1041),
this one works fine on both vdr versions.
Patchlevel on vdr 1.7.0 is:
+ h264-syncearly-framespersec-audioindexer-fielddetection-speedup
+vdr-1.7.0-s2api-07102008-h264-clean.patch
From what I see in the 1.7.0 syslog I can make out a possible reason
-liplianin drivers with another Twinhan DVB-S2 card (1041),
this one works fine on both vdr versions.
Patchlevel on vdr 1.7.0 is:
+ h264-syncearly-framespersec-audioindexer-fielddetection-speedup
+vdr-1.7.0-s2api-07102008-h264-clean.patch
From what I see in the 1.7.0 syslog I can make out a possible
compiled vdr 1.7.0.
I use s2-liplianin drivers with another Twinhan DVB-S2 card (1041),
this one works fine on both vdr versions.
Patchlevel on vdr 1.7.0 is:
+ h264-syncearly-framespersec-audioindexer-fielddetection-speedup
+vdr-1.7.0-s2api-07102008-h264-clean.patch
From what I see
/ S2API to mature and become more widely supported with
plugins etc.
vdr-1.7.0 and the S2API patch doesn't work with DVB-T at all here, so
I guess there's a bug in the patch there somewhere that affects
reception of UK transmitters (perhaps handling of QAM 16 modulation
Hi,
Due to an attempt on OS upgrade and thus kernel upgrade I'm grudgingly
(it worked for me for months with no issues so why would I want to
change it for now?) trying to make the transition from multiproto to
S2API. I have two DVB-T cards and a NOVA-S2-HD (HVR4000 lite). I have
downloaded a
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger
klaus.schmidin...@cadsoft.de wrote:
Well, even using *any* version 1.7.x in a productive environment
is a risk ;-)
[SNIP]
S2API was necessary for HDTV channels, and recording HDTV channels
only makes sense in TS. The PES recording of HDTV
Op Wo, 4 februari, 2009 13:38, schreef Ales Jurik:
-- SNIP --
Hi,
Hello!
I have it working with some dirty hacks (reelvdr svn 10388 - the latest
with hdplayer). But for the problem with sending AC3 sound to ac3dec
(with -a ac3dec) I didn't have enough time to solve. With sound over HDMI
On Wednesday 04 of February 2009, Morfsta wrote:
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger
klaus.schmidin...@cadsoft.de wrote:
Well, even using *any* version 1.7.x in a productive environment
is a risk ;-)
[SNIP]
S2API was necessary for HDTV channels, and recording HDTV
On Wednesday 04 of February 2009, Morfsta wrote:
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger
klaus.schmidin...@cadsoft.de wrote:
Well, even using *any* version 1.7.x in a productive environment
is a risk ;-)
[SNIP]
S2API was necessary for HDTV channels, and recording HDTV
Op Wo, 4 februari, 2009 13:22, schreef Morfsta:
-- SNIP --
The other problem is that I don't think anyone has got VDR 1.7.4
working with the eHD yet, which is my output device... :-( So it seems
everywhere I look at the moment I am stuck. :-(
This is indeed correct. The eHD (which I have in
The Multiproto channels.conf should be interchangeable with S2API. But
*some* modulation types didn't exist in S2API when I wrote the patches and
you need to check this for yourself. You need to check the settings (Red
button to edit in the TV Channels overview) and see if they are indeed
Op Wo, 4 februari, 2009 10:16, schreef Morfsta:
Hi,
Goodmorning!
Due to an attempt on OS upgrade and thus kernel upgrade I'm grudgingly
(it worked for me for months with no issues so why would I want to
change it for now?) trying to make the transition from multiproto to
S2API. I have two
-framespersec-audioindexer-fielddetection-speedup.diff
vdr-1.7.0-s2api-07102008-h264-clean.patch
the only other plugin I am using at this stage is the reelbox plugin
output which seems to work fine.
BTW, you might want to increase the logging for VDR or check the logfiles
in /var/log what VDR has thrown out
On 04.02.2009 11:41, Morfsta wrote:
...[ tunig problems ]
Any suggestions?
Have you considered trying VDR 1.7.4?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I still think it's a problem with the channel.conf. For fun, please try
using the old and default scan for DVB-T. Because I used the old dvb-scan
with the option to output for VDR on my Gigabyte GT-U7000-RH based DVB-T
adapter to scan for KPN Digitenne bouquets (location Zwolle/Apeldoorn).
On Wed, Feb 4, 2009 at 10:58 AM, Klaus Schmidinger
klaus.schmidin...@cadsoft.de wrote:
Have you considered trying VDR 1.7.4?
Klaus, 1.7.4 works fine with S2API and DVB-T here
Looks like there might be a problem in your patch somewhere Niels, but
not sure where? I would still prefer to use
On 04/02/2009 19:26, Simon Baxter wrote:
Hi
Does vdr-1.7.4, ts recordings and and the S2API work under DVB-C?
I can't see why it wouldn't?
Dum question - where can I find the S2API repository? I just pulled the
latest v4l-dvb from linuxtv.org, but I get vdr compiling errors requesting
Due to an attempt on OS upgrade and thus kernel upgrade I'm grudgingly
(it worked for me for months with no issues so why would I want to
change it for now?) trying to make the transition from multiproto to
S2API. I have two DVB-T cards and a NOVA-S2-HD (HVR4000 lite). I have
downloaded a
On 15.12.2008 11:06, Frank Schmirler wrote:
- no channel sync
This would make an excellent addition to streamdev.
Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should
stick to what it was meant for: streaming.
Streamdev is a receiving device within VDR, and VDR can do
On Sat, 20 Dec 2008 20:31:33 +0100, Udo Richter wrote
On 15.12.2008 11:06, Frank Schmirler wrote:
- no channel sync
This would make an excellent addition to streamdev.
Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should
stick to what it was meant for: streaming.
On 20.12.2008 23:37, Frank Schmirler wrote:
It seems that we have a different understanding of the term channel sync.
Streamdev-0.3.4 has the capabilities you're talking about. What I had in mind
was merging or replacing the client's with the server's channels list.
One thing is updating the
Frank Schmirler v...@schmirler.de wrote:
yes, intelligent timer migration between vdr instances is a not
trivial task. when a timer is to be fired, you have to ask all vdr
instances its timer list and move the timer to the most suitable
instance. taking into account recordings on the same
Nicolas Huillard wrote:
Udo Richter a écrit :
* if 2 VDRs record the same program at the same time, it seems to a be a
big problem... If using a slightly different EPG data, this result in 2
recordings with different times, and if using the exact same EPG, this
result in something weird
-Ursprungligt meddelande-
Från: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] För Pasi
Juppo
Skickat: den 15 december 2008 16:31
Till: VDR Mailing List
Ämne: Re: [vdr] VDR with S2API (update)
Other point : previous emails talk about various possibilities about DVB
Seppo Ingalsuo seppo.ingal...@iki.fi wrote:
vdr in a massive client server configuration is a giant hack with
many pieces each with its own little problems summing up.
Not giant system, but some experiences: I have one server running
three instances of vdr. Vdr #2 and #3 are connected by
Schmidinger wrote:
Attached is an updated version of the patch to make VDR use
the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument
ist ungültig
Dec 6 18:39:02 VDR kernel: DVB
Hi,
Seppo Ingalsuo wrote:
Clemens Kirchgatterer wrote:
vdr in a massive client server configuration is a giant hack with many
pieces each with its own little problems summing up.
Not giant system, but some experiences: I have one server running three
instances of vdr. Vdr #2 and #3
and change scan.c so that it first tunes to DVB-S2, as in
/* set up list of delivery systems*/
//fe_delivery_system_t delset[]={SYS_DVBS,SYS_DVBS2};
fe_delivery_system_t delset[]={SYS_DVBS2,SYS_DVBS};
Ok, I did run some
On 07.12.2008 14:41, Alex Betis wrote:
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger
klaus.schmidin...@cadsoft.de mailto:klaus.schmidin...@cadsoft.de wrote:
On 07.12.2008 13:21, Klaus Schmidinger wrote:
Attached is an updated version of the patch to make VDR use
the S2API
is an updated version of the patch to make VDR use
the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument
ist ungültig
Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502
symbol rate
Clemens Kirchgatterer wrote:
Udo Richter udo_rich...@gmx.de wrote:
I really don't get the point why it is necessary to totally rewrite
VDR core to support multiple frontends (surely loosing compatibility
to almost all plugins), when it will at the end just start one thread
per frontend,
I just wanted to download the dvb-apps from linuxtv.org, but apparently
all those repositories are gone, http://linuxtv.org/hg/dvb-apps is empty.
Any idea where to get the scan-s2 source now?
http://mercurial.intuxication.org/hg/scan-s2/
also you can try new dvb-s/dvb-s2 scanner -
On 12.12.2008 23:23, Nicolas Huillard wrote:
The problems that come to mind in typical current multiple VDR are :
* DVB device handling is running even if there is no actual DVB device
(OK, this is not a problem in practice, except for device numbers)
When there are no DVB devices available at
On 13.12.2008 00:04, VDR User wrote:
Maybe those people who wants such a networking capable vdr should fork it and
implement the needed features?
Possibly. However, I could be wrong but didn't Klaus recently say if
anyone forks VDR, he would stop developing it? And it isn't as if
there's a
Jörg Knitter a écrit :
Klaus Schmidinger wrote:
Well, tell that to people writing plugins for such output devices.
I don't see where *I* would be involved there?!
Are there enough interfaces to be able to read the and control the OSD
for including them seamlessly it into a different
On Wed, Dec 10, 2008 at 10:07:35AM +, Morfsta wrote:
Are you selling single eHD cards solely for implementation within Reel
devices? If so, I believe you should make this clear as I wasn't aware
of this and other users won't be. Some of the problems I have when
running eHD with VDR 1.7.0
It is already possible to have disks array, DVB devices, and all the
cables down in the closet, and as many clients we want behind each TV
set, with only a CAT5 cable and an IR sensor. That's just difficult.
Moving existing plugin code into the VDR core, and getting some out of
the core, into
Hi,
On Fr, Dez 12, 2008 at 09:06:02 -0800, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't
provide a good solution to this. After years of using standalone VDR
boxes, I too would love if we had the option to use a networked VDR
with each client being
On 12.12.2008 18:06, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't
provide a good solution to this. After years of using standalone VDR
boxes, I too would love if we had the option to use a networked VDR
with each client being exactly as you
On Fri, Dec 12, 2008 at 12:30 PM, Halim Sahin halim.sa...@t-online.de wrote:
This would add more complexity to vdr and make it unstable.
BTW. VDR is a video disk recorder not a media center??
I don't know an other multimedia project like vdr wich works
stable like vdr.
Why would you assume
Udo Richter udo_rich...@gmx.de wrote:
I really don't get the point why it is necessary to totally rewrite
VDR core to support multiple frontends (surely loosing compatibility
to almost all plugins), when it will at the end just start one thread
per frontend, while we can already start one VDR
Udo Richter a écrit :
On 12.12.2008 18:06, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't
provide a good solution to this. After years of using standalone VDR
boxes, I too would love if we had the option to use a networked VDR
with each client being
Klaus Schmidinger wrote:
Besides, isn't there the streamdev plugin that provides signals
to other clients? I've never tried it myself, but I was under
the impression that this is what people use in such cases...
I've seen multi client streamdev users run multiple vdr daemons in
server
On Wed, 10 Dec 2008 11:59:47 +0200, Pertti Kosunen wrote
Klaus Schmidinger wrote:
Besides, isn't there the streamdev plugin that provides signals
to other clients? I've never tried it myself, but I was under
the impression that this is what people use in such cases...
I've seen multi
Klaus Schmidinger wrote:
Well, tell that to people writing plugins for such output devices.
I don't see where *I* would be involved there?!
Are there enough interfaces to be able to read the and control the OSD
for including them seamlessly it into a different front-end? I don´t
think that
Hi,
Why don't you just use such a graphics card then?
You're right. After my previous message in this thread, I updated my vdr
box yesterday, only to find FF output not working properly (once again). [*]
Now I'm considering the built-in graphics card as an alternative output,
hoping that it
Halim Sahin wrote:
You can buy a lcd tv and after two years you can't use it's
hdmi connectiorr of hdmi revision 599,95.0
hd ready-full-hd/hdmi1.1, 1.2 1.3 .
I read something about limitations of current hdmi standard so we will
maybe we get displayport as new solution???
This has
Hi,
the S2API implementation would be a perfect place to integrate my
frontend facilities patch in a way or another.
The patch simply extends the current cDevice API to include some common
frontend related statistics (now available only in femon), so that skins
and all the other plugins can
Hi,
I'm pretty sure there are quite a few systems out there using
FF DVB cards. I wonder why you are constantly arguing against
them ;-)
I own an FF card for two reasons only: It offers better video quality on
a CRT TV and vdr (1.6) prefers it.
There are a few things to dislike about FF
On 09.12.2008 17:22, Hanno Zulla wrote:
Hi,
I'm pretty sure there are quite a few systems out there using
FF DVB cards. I wonder why you are constantly arguing against
them ;-)
I own an FF card for two reasons only: It offers better video quality on
a CRT TV and vdr (1.6) prefers it.
On 09.12.2008 16:40, Rolf Ahrenberg wrote:
Hi,
the S2API implementation would be a perfect place to integrate my
frontend facilities patch in a way or another.
The patch simply extends the current cDevice API to include some common
frontend related statistics (now available only in
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would drive VDR in the wrong direction. I'm sitting here with
a €65 nvidia 8200-based motherboard playing 1080p videos with the cpu
97% idle using vdpau and ffmpeg!
which cpu do you have ? What about pictures
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would drive VDR in the wrong direction. I'm sitting here with
a ???65 nvidia 8200-based motherboard playing 1080p videos with the cpu
97% idle
Georg Acher wrote:
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would drive VDR in the wrong direction. I'm sitting here with
a ???65 nvidia 8200-based motherboard playing 1080p videos
On Tue, Dec 9, 2008 at 11:48 AM, Georg Acher [EMAIL PROTECTED] wrote:
The reelvdr code base is tested by a really large number of users (many
thousands and not many geeks ;-) ). Is there any specific reason why you
don't want to profit from the experiences RMM already made?
There are many
On Tue, Dec 09, 2008 at 12:46:21PM -0800, VDR User wrote:
On Tue, Dec 9, 2008 at 11:48 AM, Georg Acher [EMAIL PROTECTED] wrote:
The reelvdr code base is tested by a really large number of users (many
thousands and not many geeks ;-) ). Is there any specific reason why you
don't want to
On 09.12.2008 21:47, Magnus Hörlin wrote:
...
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would drive VDR in the wrong direction. I'm sitting here with
a ???65 nvidia 8200-based
Karl Glatz wrote:
But the disadvantages are clear: Modern GPUs support more than the OSD
provided by VDR (even older gpus do that).
So none of these Output-Plugins will face the real problem: The OSD is
(mostly) limited to work with FF cards.
[...]
Even if you don't like such
Klaus Schmidinger wrote:
On 09.12.2008 21:47, Magnus Hörlin wrote:
...
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would drive VDR in the wrong direction. I'm sitting
On Tue, 09 Dec 2008 22:39:04 +0100
Klaus Schmidinger [EMAIL PROTECTED] wrote:
Besides, isn't there the streamdev plugin that provides signals
to other clients? I've never tried it myself, but I was under
the impression that this is what people use in such cases...
Am I right in thinking you
On 09.12.2008 23:04, Magnus Hörlin wrote:
Klaus Schmidinger wrote:
On 09.12.2008 21:47, Magnus Hörlin wrote:
...
On Tue, Dec 09, 2008 at 07:34:19PM +0100, Magnus Hörlin wrote:
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would
Magnus Hörlin schrieb:
My VDR is one machine with several DVB devices and hardware replay.
As long as there is a way of having a good hardware replay, why
shouldn't I use it?
My opinion as a hardware design engineer is that when my cpu is 97% idle
displaying 1080p video, it is hardware
On Tuesday 09 December 2008 22:44:07 Stefan Hußfeldt wrote:
Magnus Hörlin schrieb:
My VDR is one machine with several DVB devices and hardware replay.
As long as there is a way of having a good hardware replay, why
shouldn't I use it?
My opinion as a hardware design engineer is that
Isn't PAL enough for everybody? *duckandcover*
and me. I don't have room for any more than DVB-T and FF in my VDR barebone
system
And many more. I've installed vdr for 50 persons - most of these are
still happy with an old P3 or Celeron ...
In Germany there's definitely no run
On 08.12.2008 06:03, VDR User wrote:
On Sun, Dec 7, 2008 at 9:43 AM, Klaus Schmidinger
[EMAIL PROTECTED] wrote:
On 07.12.2008 18:40, gimli wrote:
Hi Klaus,
just one question. Do you also use a budget system ?
If so, how do you watch TV with vdr 1.7.1 and later ;)
since xineliboutput is
On 08/12/2008, Klaus Schmidinger [EMAIL PROTECTED] wrote:
On 08.12.2008 10:08, Theunis Potgieter wrote:
On 07/12/2008, Klaus Schmidinger [EMAIL PROTECTED] wrote:
Apart from that the TS data stream will be saved
exactly as it comes in.
So will it then also record encrypted streams
On 08.12.2008 11:13, Artem Makhutov wrote:
Hi,
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
On 08.12.2008 10:49, Holger Rusch wrote:
Hi,
[EMAIL PROTECTED] schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best
On 8 Dec 2008, at 19:22, Theunis Potgieter wrote:
What is the best FF hardware solution if you have in my case only one
provider, which means one smartcard. But you want to watch an
encrypted channel on one transponder and record another on a different
transponder from the same provider. Do
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
Is there any movement to files 2GB for the recordings?
I will most likely change this when going to TS recording format.
In doing so, I'd like to get rid of splitting recordings into separate
files altogether. However, I
Hi,
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
On 08.12.2008 10:49, Holger Rusch wrote:
Hi,
[EMAIL PROTECTED] schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best choice to get the best picture
quality on a
On 08.12.2008 10:49, Holger Rusch wrote:
Hi,
[EMAIL PROTECTED] schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best choice to get the best picture
quality on a PAL CRT TV !
But for anybody who wants to use a beamer these FF-cards are
On 08.12.2008 16:34, Alex Betis wrote:
...
Klaus, I've asked about the size of recording in TS format that you
probably missed (or ignored :)).
Will there be more overhead compared to currently recorded format?
There may be a small overhead, but with today's huge disks this should
be
Klaus Schmidinger wrote:
Is there any movement to files 2GB for the recordings?
I will most likely change this when going to TS recording format.
In doing so, I'd like to get rid of splitting recordings into separate
files altogether. However, I think there might be people who still
want
But for anybody who wants to use a beamer these FF-cards are full pain
with there stupid outputs. I (and many others) want DVI/HDMI/Display-Port.
And I want beamer that has a network card and can download and show the
content downloaded from vdr server. I don't know whether they
could connect
BTW. Softdevice/play, vdr-xine and xineliboutput are able to play youtube divx
etc.
Is there btw any vdr-plugin for browsing you tupe content (like most
watched, movie trailers, etc...) and playing them.
Another nice plugin would be a something where you could select some of
your recordings
On Mon, Dec 8, 2008 at 11:57 AM, Halim Sahin [EMAIL PROTECTED] wrote:
It makes no sense to me supporting something
which can't be used with hdtv stuff in one year!
HDMI isn't going anywhere any time soon. Neither is h264, or anything
else so can you give us some examples of things you think
Hi,
search for webvideo plugin.
It works for me!
On Di, Dez 09, 2008 at 01:04:58 +0200, Mika Laitio wrote:
BTW. Softdevice/play, vdr-xine and xineliboutput are able to play youtube
divx
etc.
Is there btw any vdr-plugin for browsing you tupe content (like most
watched, movie trailers,
Is ther a problem with
vdr-1.7.0-h264-syncearly-framespersec-audioindexer-fielddetection-speedup
patch fom Reinhard Nilsl ?
Could this patch be included in vdr-1.7.2 like S2API patch?
yes, it will be great
Goga
___
vdr mailing list
vdr
Attached is an updated version of the patch to make VDR use
the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig
Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0
out
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger
[EMAIL PROTECTED] wrote:
On 07.12.2008 13:21, Klaus Schmidinger wrote:
Attached is an updated version of the patch to make VDR use
the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR
On 07.12.2008 18:40, gimli wrote:
Hi Klaus,
just one question. Do you also use a budget system ?
If so, how do you watch TV with vdr 1.7.1 and later ;)
since xineliboutput is completly broken with it.
Currently I still have a FF DVB card for replaying, which, in
the long run, will be
The attached patch is what I've gathered from various postings
regarding adapting VDR to the S2API driver API (thanks to
Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide a way of determining whether
a DVB-S device supports DVB-S2
El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió:
The attached patch is what I've gathered from various postings
regarding adapting VDR to the S2API driver API (thanks to
Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide
В сообщении от 6 December 2008 17:06:40 Klaus Schmidinger написал(а):
The attached patch is what I've gathered from various postings
regarding adapting VDR to the S2API driver API (thanks to
Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't
Приветствую, Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
The attached patch is what I've gathered from various postings
regarding adapting VDR to the S2API driver API (thanks to
Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI
On 06.12.2008 17:55, Goga777 wrote:
ðÒÉ×ÅÔÓÔ×ÕÀ, Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
[EMAIL PROTECTED]:/home/kls/vdr/vdr-1.7.0 patch --dry-run
../VDR/vdr-1.7.1-s2api.diff
patching file channels.c
Hunk #6 succeeded at 636 (offset -1 lines).
Hunk #7 succeeded at 643
Приветствую, Goga777
Приветствую, Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
ah, no
/vdr170# patch -p1 vdr-1.7.1-s2api_from_Klaus.diff
patching file channels.c
Hunk #6 succeeded at 636 (offset -1 lines).
Hunk #7 succeeded at 643 (offset -1 lines).
Hunk #8 succeeded at 665
On Sat, 6 Dec 2008, Klaus Schmidinger wrote:
If you don't want to patch the driver, you can change the line
case FE_QPSK: frontendType = (frontendInfo.caps FE_CAN_2ND_GEN_MODULATION)
? SYS_DVBS2 : SYS_DVBS; break;
in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType
88 matches
Mail list logo
