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 t
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 fo
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
"Frank Schmirler" 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 transpo
On Mon, 15 Dec 2008 21:50:45 +0200, Seppo Ingalsuo wrote
> I wonder if it solves the problems when the channels are not
> perfectly in sync? I have a manually sorted DVB-T channels section
> but my autosort handled huge amount of DVB-S channels are usually
> bit different in vdr instances due to
Frank Schmirler wrote:
> On Sat, 13 Dec 2008 18:52:52 +0200, Seppo Ingalsuo wrote
>
>> - The biggest annoyance: Possible to pause live TV only in vdr #1
>>
>
> Have you tried with the VDR patch from remotetimers-0.1.0? I never took the
> time to test it with timersync-plugin, but I'd be int
> -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
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 some
On Sun, 14 Dec 2008 16:42:21 +0100, Udo Richter 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. Remember 4 years ago: Remotetimers
feature wa
On Sun, 14 Dec 2008 09:42:40 +0100, Clemens Kirchgatterer wrote
> Seppo Ingalsuo 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 runn
On Sat, 13 Dec 2008 18:52:52 +0200, Seppo Ingalsuo wrote
> - The biggest annoyance: Possible to pause live TV only in vdr #1
Have you tried with the VDR patch from remotetimers-0.1.0? I never took the
time to test it with timersync-plugin, but I'd be interested to see if instant
recordings and pau
On Sat, 13 Dec 2008 12:31:05 +0100, Udo Richter wrote
> Agreed. Solutions like RemoteOSD and RemoteTiemrs are merely
> workarounds. A nice solution to this integrated into VDR would
> improve things a lot here.
Just curious: What are you missing?
> Another parameter for every timer would be a
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 and maybe unusable (say
What happens if vdr has got multiple FF-dvb-s cards in the same machine, and
you want to hookup multiple monitor/tvs? Can vdr successully handle this on
the same machine? Or is the only answer now to run multiple intances of vdr,
one for each FF-card? If vdr can do that, then surely implementing cr
On Sun, Dec 14, 2008 at 2:01 PM, Klaus Schmidinger <
klaus.schmidin...@cadsoft.de> wrote:
>
> >>> Some more info: apparently the problem only happens if a DVB-S2
> card
> >>> (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a
> DVB-S2
> >>> channel after the driver has be
On 14.12.2008 11:23, matthieu castet wrote:
> - on my configuration the recording only work on vdr#1. on vdr#2 svdrp
> should be used to control recording and ftp to read them (with a video
> player)
I never tried to record on the streaming client, but beside the fact
that video will go unnecessa
> 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 13.12.2008 22:34, Oleg Roitburd wrote:
> 2008/12/13 Klaus Schmidinger :
>> On 07.12.2008 14:41, Alex Betis wrote:
>>> On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger
>>> mailto:klaus.schmidin...@cadsoft.de>> wrote:
>>>
>>> On 07.12.2008 13:21, Klaus Schmidinger wrote:
>>> > Attached is
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
Seppo Ingalsuo 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 streamdev to
>
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
> th
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
> > 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 scann
Clemens Kirchgatterer wrote:
> Udo Richter 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
2008/12/13 Klaus Schmidinger :
> On 07.12.2008 14:41, Alex Betis wrote:
>> On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger
>> 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
>
On 07.12.2008 14:41, Alex Betis wrote:
> On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger
> 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. Dominik Strasser re
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 are connected by streamdev to
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 b
Udo Richter 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 instance per
>
On Fri, Dec 12, 2008 at 12:30 PM, Halim Sahin 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 VDR would become unsta
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 describe
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 e
> 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,
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.
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 differ
Karl Glatz a écrit :
> Of couse you can, either with xineliboutput, xine-vdr or softdevice.
> 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) limit
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 wo
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 th
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 m
On Tue, Dec 9, 2008 at 7:48 PM, Georg Acher <[EMAIL PROTECTED]> wrote:
> Why all this eHD-bashing? Just because a *commercial* company already made a
> complete HDTV-vdr-solution more than 18 months ago that the vdr-community
> hasn't achieved until now?
>
> Of course the eHD won't live forever, pr
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 machi
>> 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
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 enginee
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
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
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 y
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
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 in
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 820
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
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
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 vi
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
Goga777 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 using vdpau and ffmpeg!
>>
>
> which cp
> 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 pictu
2008/12/9 Klaus Schmidinger <[EMAIL PROTECTED]>
> 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: I
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 thin
On Sun, Dec 7, 2008 at 9:43 AM, Klaus Schmidinger
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>> 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
On 09.12.2008 18:54, Rolf Ahrenberg wrote:
> On Tue, 9 Dec 2008, Klaus Schmidinger wrote:
>
>> I have been thinking about something along that line for quite
>> a while, and also saw your patch you sent me earlier in a PM.
>> My actual implementation will most likely be somewhat different,
>> but
On Tue, 9 Dec 2008, Klaus Schmidinger wrote:
> I have been thinking about something along that line for quite
> a while, and also saw your patch you sent me earlier in a PM.
> My actual implementation will most likely be somewhat different,
> but should fulfill the same purpose.
This is off-topic
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 i
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) prefe
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 ca
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 e
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
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 t
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 thin
> 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
> 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
Udo Richter wrote:
> Second: Priority and Lifetime of a recording IMHO don't belong to the
> name part. This could easily fit into the info.vdr file instead. Or does
> it make sense to have the same recording with different lifetime or
> priority in separate folders?
No and it actually causes p
Hi,
On Mo, Dez 08, 2008 at 10:28:30 -0800, VDR User wrote:
V> On Mon, Dec 8, 2008 at 2:00 AM, Halim Sahin <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I don't like the hd discusion because we don't have
> > any tv's which are build using a well developed standard.
> > E. G.
> > You can buy a lcd tv and a
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
>
On Mon, Dec 8, 2008 at 2:00 AM, Halim Sahin <[EMAIL PROTECTED]> wrote:
> Hi,
> I don't like the hd discusion because we don't have
> any tv's which are build using a well developed standard.
> E. G.
> You can buy a lcd tv and after two years you can't use it's
> hdmi connectiorr of hdmi revision 59
Just some small comments..
I don't think I argue against FF (btw, my main vdr box has two Nexus-s
in it), more along the lines of argue for other/better options of the
current times. Sure, FF was a great choice for it's day but that day
has moved on in my opinion. Maybe it was never intended tha
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 negli
On Mon, Dec 8, 2008 at 12:03 PM, Klaus Schmidinger <
[EMAIL PROTECTED]> 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
Jochen Heuer a écrit :
> 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
>> f
On 08.12.2008 12:34, Morfsta wrote:
> ...
> Any idea when TS will be implemented? Its been talked about for a long
> time now... :-(
It's pretty much the next thing on my list, once the S2API switch
is done.
Klaus
___
vdr mailing list
vdr@linuxtv.org
h
On Mon, Dec 8, 2008 at 11:05 AM, Manu Abraham <[EMAIL PROTECTED]> wrote:
> It might be a bit more time, to know the actual status, but the TS
> feature might be a still important feature, if that were to happen.
I am an eHD user and I'm hoping that the TS feature might improve
things as currently
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.
> FF seems to have understandably gone the way of the dinosaur.
It has been true for the older FF cards, but there might be a
possible new generation/revolution of FF cards, though it was
originally considered expensive sometime back.
Other than for the FF cards, there are cards (not in retai
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,
-Original message-
From: Holger Rusch <[EMAIL PROTECTED]>
Sent: Mon 08-12-2008 11:22
To: VDR Mailing List ;
Subject: Re: [vdr] VDR with S2API (update)
> Hi,
>
> Klaus Schmidinger schrieb:
> >> FF will die in a years or two (months?) i guess and vdr has no well
Hi,
On Mon, Dec 08, 2008 at 12:19:24PM +0200, Theunis Potgieter wrote:
> On 08/12/2008, Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
> >
> > Currently it creates a new one, but I guess this should be changed to
> > continue an existing file (if the file size limit hasn't been exceeded,
> > yet).
On 08/12/2008, Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
>
> Currently it creates a new one, but I guess this should be changed to
> continue an existing file (if the file size limit hasn't been exceeded, yet).
> If file splitting is removed, then it would of course continue the (one and
> on
Hi,
Klaus Schmidinger schrieb:
>> FF will die in a years or two (months?) i guess and vdr has no well
>> integrated outputs.
> Is there anything in the VDR plugin API that would prevent a plugin
> from implementing a suitable output device?
I guess not, but there are (from my view as user with k
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 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
>
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-
Hi,
I don't like the hd discusion because we don't have
any tv's which are build using a well developed standard.
E. G.
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 limitatio
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 full pain
with there stupid outputs. I (and
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 en
> 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 !
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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 just as it was, or will
> it save in unencrypted form?
It w
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 just as it was, or will
it save in unencrypted form?
>
>
> Klaus
>
Klaus Schmidinger schrieb:
> On 08.12.2008 06:03, VDR User wrote:
>
>> Just curious why you prefer that setup instead of going the budget
>> route for the same or less cost?
>>
>
> Well, because I already have several of these FF cards, and it's
> so easy to set up a VDR with them.
>
>
>
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
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 completly broken with it.
>
>
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 re
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.
mfg
Edgar (gimli) Hucek
> Attached is an updated version of the patch to make VDR use
> the S2API. Dominik Strasser reported tha
1 - 100 of 120 matches
Mail list logo