On 05.03.2012 19:54, Timothy D. Lenz wrote:
On 3/5/2012 2:52 AM, Gero wrote:
On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
...
A problem
On 05.03.2012 19:50, Timothy D. Lenz wrote:
No, but I have the auto shutdown thing turned off because when signal is bad on
1 channel, it would disrupt everything with frequent restarts and as I recall,
it often didn't restart. Might have been xine or something that stopped with
the restart, I
On 3/5/2012 2:52 AM, Gero wrote:
On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
...
A problem I have run into before is not that a channel
No, but I have the auto shutdown thing turned off because when signal is
bad on 1 channel, it would disrupt everything with frequent restarts and
as I recall, it often didn't restart. Might have been xine or something
that stopped with the restart, I don't recall. Plus, restarting VDR in
this c
On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
> On 05.03.2012 04:47, Gero wrote:
> > On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
> >> On 04.03.2012 19:04, Timothy D. Lenz wrote:
> >>> ...
> >>> A problem I have run into before is not that a channel is down, though
>
On 05.03.2012 04:47, Gero wrote:
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
On 04.03.2012 19:04, Timothy D. Lenz wrote:
...
A problem I have run into before is not that a channel is down, though
that also happens, but that a tuner is down. I've had tuner crashes, but
vdr just
On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
> On 04.03.2012 19:04, Timothy D. Lenz wrote:
> > ...
> > A problem I have run into before is not that a channel is down, though
> > that also happens, but that a tuner is down. I've had tuner crashes, but
> > vdr just stayed with that tu
On 04.03.2012 19:04, Timothy D. Lenz wrote:
...
A problem I have run into before is not that a channel is down, though that
also happens, but that a tuner is down. I've had tuner crashes, but vdr just
stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA
tuners. 2 Dual tun
"Timothy D. Lenz" writes:
[...]
> A problem I have run into before is not that a channel is down, though
> that also happens, but that a tuner is down. I've had tuner crashes,
> but vdr just stayed with that tuner/chanel and recorded nothing. I
> currently have 5 ATA tuners. 2 Dual tuner cards an
On 3/3/2012 4:48 AM, Klaus Schmidinger wrote:
On 02.03.2012 18:13, Udo Richter wrote:
Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
On 29.02.2012 21:33, Udo Richter wrote:
Roughly, the callback should be at the places where these two get
called:
DELETENULL(liveSubtitle);
DELETENULL(dvbSub
On 3/2/2012 11:06 AM, VDR User wrote:
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton wrote:
Signal the server to start recording. But then the client has to be able
to match up its buffer with what the server has recorded after the
buffer filled and let the server know when the temp recording
On 02.03.2012 18:13, Udo Richter wrote:
Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
On 29.02.2012 21:33, Udo Richter wrote:
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle);
DELETENULL(dvbSubtitleConverter);
(Thats how VDR's ow
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton wrote:
> Signal the server to start recording. But then the client has to be able
> to match up its buffer with what the server has recorded after the
> buffer filled and let the server know when the temp recording is no
> longer needed. Complicated.
Am 02.03.2012 10:30, schrieb fnu:
> You want to have a feeling how it feels, if a live buffer is the underlying
> central function in a PVR solution, just go and test MythTV.
I think the main objection against buffering was that for old FF cards,
this also forces transfer mode, resulting in additi
On Fri, 02 Mar 2012 13:01:23 +0100, Klaus Schmidinger wrote
> On 02.03.2012 12:54, Frank Schmirler wrote:
> > On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
> >> On 01.03.2012 09:38, Frank Schmirler wrote:
> >>> On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
> Am 29.02.2012
Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
> On 29.02.2012 21:33, Udo Richter wrote:
>> Roughly, the callback should be at the places where these two get called:
>>
>> DELETENULL(liveSubtitle);
>> DELETENULL(dvbSubtitleConverter);
>>
>> (Thats how VDR's own receivers get out of way.)
Am 02.03.2012 11:35, schrieb Jarkko Kangas:
> On 2.3.2012 12:17, Pertti Kosunen wrote:
>> It would be great if next stable could include ttxtsubs-plugin
>> readiness, i.e. recording/viewing teletext subtitles would not require
>> patching of main VDR code anymore.
>
> It would be also great if nex
On Fri, 2 Mar 2012 10:30:37 +0100
"fnu" wrote:
> > about "Pause and rewind live TV".
>
> What is live TV there, as it is already recorded ... ?
>
> Only users which didn't got into VDR and epgsearch timers do call for
> this live buffer function. They hope for a kind of security, which
> this f
On Fri, 02 Mar 2012 08:29:00 +0100
Gerald Dachs wrote:
> Am 2012-03-02 00:18, schrieb Tony Houghton:
> > Going off on a tangent, there's been some discussion about "Pause
> > and rewind live TV". That could be implemented fairly easily in
> > clients with
> > a big RAM buffer, without adding any
On 02.03.2012 12:54, Frank Schmirler wrote:
On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
On 01.03.2012 09:38, Frank Schmirler wrote:
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
+ The function cDevice::Receiving() now
On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
> On 01.03.2012 09:38, Frank Schmirler wrote:
> > On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
> >> Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
> >>>+ The function cDevice::Receiving() now returns true if there is any
> >>
On 2.3.2012 13:06, Pertti Kosunen wrote:
Epgsearch doesn't need patching.
I think it does, if you want replace VDR's standard
schedule menu with epgsearch?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Fri, 02 Mar 2012 11:06:03 +0100, Klaus Schmidinger wrote
> I'm currently considering giving GetDevice() another parameter:
>
>static cDevice *GetDevice(const cChannel *Channel, int Priority,
> bool LiveView, bool Query = false);
>
> and make it not do any CAM assignments or receiver detac
On 2.3.2012 12:35, Jarkko Kangas wrote:
It would be also great if next stable could include mainmenuhooks-patch
so extrecmenu- and epgsearch-plugins would not require patching VDR code
anymore.
Epgsearch doesn't need patching.
___
vdr mailing list
vd
On 2.3.2012 12:17, Pertti Kosunen wrote:
It would be great if next stable could include ttxtsubs-plugin
readiness, i.e. recording/viewing teletext subtitles would not require
patching of main VDR code anymore.
It would be also great if next stable could include mainmenuhooks-patch
so extrecme
On 29.2.2012 10:20, Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0.
It would be great if next stable could include ttxtsubs-plugin
readiness, i.e. recording/viewing teletext subtitles would not require
patching of main VDR code anymore.
___
On 01.03.2012 09:38, Frank Schmirler wrote:
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
+ The function cDevice::Receiving() now returns true if there is any
receiver
attached to the device. Its boolean parameter has no meaning an
On 29.02.2012 21:33, Udo Richter wrote:
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
+ The function cDevice::Receiving() now returns true if there is any
receiver
attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from P
> about "Pause and rewind live TV".
What is live TV there, as it is already recorded ... ?
Only users which didn't got into VDR and epgsearch timers do call for this
live buffer function. They hope for a kind of security, which this function
doesn't really provide.
You want to have a feeling how
Am 2012-03-02 00:18, schrieb Tony Houghton:
Going off on a tangent, there's been some discussion about "Pause and
rewind live TV". That could be implemented fairly easily in clients
with
a big RAM buffer, without adding any complexity to the server.
Big RAM buffer means long breaks between ch
On Thu, 01 Mar 2012 22:12:19 +0100
Manuel Reimer wrote:
> Tony Houghton wrote:
> > I don't think a plugin is enough. For better client-server VDR
> > needs to support multiple clients watching different channels with
> > different OSDs simultaneously.
>
> It just has to deliver the data. The OSD
Am 01.03.2012 22:25, schrieb Klaus Schmidinger:
> Guys, *please*! I stated earlier that I am currently concentrating
> on making a stable version 2.0, and that I will see to make client/server
> a priority *after* that.
Agreed, lets focus on 2.0 for now. We just got carried away dreaming of
VDR 3.
On 01.03.2012 22:17, VDR User wrote:
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter wrote:
Am 01.03.2012 07:03, schrieb VDR User:
one option to spread
the workload could be Klaus assigning different portions to different
contributors that would like to work on it. If Klaus is clear about
what he
Tony Houghton wrote:
I don't think a plugin is enough. For better client-server VDR
needs to support multiple clients watching different channels with
different OSDs simultaneously.
It just has to deliver the data. The OSD itself is created by the client.
Yours
Manuel
___
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter wrote:
> Am 01.03.2012 07:03, schrieb VDR User:
>> one option to spread
>> the workload could be Klaus assigning different portions to different
>> contributors that would like to work on it. If Klaus is clear about
>> what he wants and is in good commu
Am 01.03.2012 07:03, schrieb VDR User:
> one option to spread
> the workload could be Klaus assigning different portions to different
> contributors that would like to work on it. If Klaus is clear about
> what he wants and is in good communication with other coders, perhaps
> it could become more
Am 01.03.2012 06:37, schrieb Gero:
>> A timer menu that belongs to a recording backend, a recording menu that
>> displays content of storage modules, several frontends that can connect
>> to one recording backend or several storage modules, ...
>
> I think, here is already the first shortcoming in
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
> Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
> > + The function cDevice::Receiving() now returns true if there is any
> > receiver
> > attached to the device. Its boolean parameter has no meaning any more.
>
> Please remember to drop
On Wed, Feb 29, 2012 at 11:45 AM, Udo Richter wrote:
> In any case this would be the biggest rewrite of major parts of VDR
> ever, with lots of breakage, total loss of plugin compatibility and very
> long development cycle.
It's not a small task, but I believe the end product will be well
worth t
On Wednesday 29 February 2012 - 20:45:54, Udo Richter wrote:
> Am 29.02.2012 17:50, schrieb Tony Houghton:
> > For better client-server VDR needs to support multiple clients watching
> > different channels with different OSDs simultaneously.
>
> Not necessarily. I think the key solution is to modu
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
> + The function cDevice::Receiving() now returns true if there is any
> receiver
> attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is
now finally comple
Am 29.02.2012 17:50, schrieb Tony Houghton:
> On Wed, 29 Feb 2012 16:48:33 +0100
> Manuel Reimer wrote:
>> What does this mean? Do you plan built-in networking support or do
>> you plan to improve streamdev? IMHO it is a big task to make really
>> good networking support. Keeping this code separat
On Wednesday 29 February 2012 - 17:50:27, Tony Houghton wrote:
> On Wed, 29 Feb 2012 16:48:33 +0100
> Manuel Reimer wrote:
> > Klaus Schmidinger wrote:
> > > Yes, the next stable version will be 2.0.
> > > Version 1.0 was the "SD version", and version 2.0 shall be the "HD
> > > version" ;-).
> > >
On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger
wrote:
> Yes, the next stable version will be 2.0.
> Version 1.0 was the "SD version", and version 2.0 shall be the "HD version"
> ;-).
Sounds good! :)
> I'll see to make "client/server" a priority after that.
I honestly had to read this a cou
On Wed, 29 Feb 2012 16:48:33 +0100
Manuel Reimer wrote:
> Klaus Schmidinger wrote:
> > Yes, the next stable version will be 2.0.
> > Version 1.0 was the "SD version", and version 2.0 shall be the "HD
> > version" ;-).
> >
> > I'll see to make "client/server" a priority after that.
>
> What does
On Wed, 29 Feb 2012 16:17:07 +0100, Klaus Schmidinger wrote
> Even though VDR itself doesn't have the necessity for "remote receivers"
> (yet), I see the problem for streamdev. I have therefore reconsidered
> this matter and will make the following changes for the next
> developer version:
>
> -
On 29.02.2012 16:48, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0.
Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in netwo
29.02.2012 10:30, Tobi kirjoitti:
> On 29.02.2012 08:24, Dave wrote:
>
>> And the Linux distributions will generally only package 'stable' versions.
>
> For Debian I'm already packaging 1.7.x, because 1.6 became pretty much
> useless nowadays. Wheezy is going to freeze in June and I hope that VDR
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0.
Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in networking support or do you plan to
improve st
On 28.02.2012 16:48, Frank Schmirler wrote:
On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote
Am 27.02.2012 14:33, schrieb Frank Schmirler:
Instead of a configurable "LiveTV priority", your approach uses the fixed
priority value 0 for LiveTV. The new idle priority of -100 opens the range fo
On 29.02.2012 08:24, Dave wrote:
> And the Linux distributions will generally only package 'stable' versions.
For Debian I'm already packaging 1.7.x, because 1.6 became pretty much
useless nowadays. Wheezy is going to freeze in June and I hope that VDR
becomes stable until then.
Tobias
_
On 29.02.2012 08:17, Steffen Barszus wrote:
On Wed, 29 Feb 2012 05:38:06 +0100
Gero wrote:
On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
28.02.2012 12:24, Gero kirjoitti:
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
I'll keep this in mind for "after versi
On Wednesday 29 February 2012 05:58:21 Mika Laitio wrote:
> > Because 1.6.0 was released a long time ago, and we want a new stable
> > version soon? :)
>
> I agree, 1.7 devel versions have many nice improvements like the support
> for hvr-4000's multiple frontends in same adapter.
> Even thought m
On Wed, 29 Feb 2012 05:38:06 +0100
Gero wrote:
> On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
> > 28.02.2012 12:24, Gero kirjoitti:
> > > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
> > >>
> > >> I'll keep this in mind for "after version 2.0".
> > >
> > > Why
> Because 1.6.0 was released a long time ago, and we want a new stable
> version soon? :)
I agree, 1.7 devel versions have many nice improvements like the support
for hvr-4000's multiple frontends in same adapter.
Even thought most active users in this mail list very likely uses
developer versions
On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
> 28.02.2012 12:24, Gero kirjoitti:
> > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
> >>
> >> I'll keep this in mind for "after version 2.0".
> >
> > Why so far?
>
> Because 1.6.0 was released a long time ago, and w
28.02.2012 12:24, Gero kirjoitti:
> On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
>> On 28.02.2012 09:32, Frank Schmirler wrote:
>>> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
What exactly is the use case for this, anyway?
VDR has two purposes: "li
I'm included in the list of people that wished VDR supported real
server/client. I don't mean hacks and workarounds but real true
support, which of course means a major redesign. I know several users
who hated to but left VDR because it lacks this. Bringing VDR to
modern times/needs would be absolu
On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote
> Am 27.02.2012 14:33, schrieb Frank Schmirler:
> > Instead of a configurable "LiveTV priority", your approach uses the fixed
> > priority value 0 for LiveTV. The new idle priority of -100 opens the range
> > for
> > cReceivers with negative pr
Hi,
On Tuesday 28 February 2012 - 15:49:32, syrius...@no-log.org wrote:
> i like the xine and xinelibouput plugins way a lot, on my laptop no
> need to install a huge (and sometimes bloaty) media center, ...
Agreed! That's why I like vdr-sxfe. On standard distributions one file to
install and it
On 02/28/2012 03:49 PM, syrius...@no-log.org wrote:
Eric Valette writes:
On 02/28/2012 03:08 PM, Gero wrote:
... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR,
so I think it could be a good template for future vdr-development, but not
serve as a vdr-replacement.
W
Eric Valette writes:
> On 02/28/2012 03:08 PM, Gero wrote:
>
>> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR,
>> so I think it could be a good template for future vdr-development, but not
>> serve as a vdr-replacement.
>
> Well openelec distrib does have means to us
On 02/28/2012 03:08 PM, Gero wrote:
... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR,
so I think it could be a good template for future vdr-development, but not
serve as a vdr-replacement.
Well openelec distrib does have means to use tvheadend...
At least I think,
On Dienstag 28 Februar 2012, Eric Valette wrote:
> On 02/28/2012 11:24 AM, Gero wrote:
> > I think, many vdr-users crave for redesign and I'm sure, that some users
> > are willing to participate.
>
> I drooped vdr in favor of tvheadend just for many of the design reason ...
Whow - I'm impressed ;
On 02/28/2012 11:24 AM, Gero wrote:
I think, many vdr-users crave for redesign and I'm sure, that some users are
willing to participate.
I drooped vdr in favor of tvheadend just for many of the design reason
you mentioned:
1) Clear backend/front end design,
2) Better networ
On 28/02/12 10:24, Gero wrote:
At the moment it all works pretty well in streamdev, ...
As far as I understood available docs, streamdev is not able to handle
recordings, so I would not say "all works"
Streamdev does work fine for recordings. However, I tend to use e-tobi's
fuse filesystem t
On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
> On 28.02.2012 09:32, Frank Schmirler wrote:
> > On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
> >> On 27.02.2012 14:33, Frank Schmirler wrote:
> >>> I can't however overlook the impact these modifications have.
> >>
>
On 28.02.2012 09:32, Frank Schmirler wrote:
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
On 27.02.2012 14:33, Frank Schmirler wrote:
I suggest the following additional changes:
- instead of any negative priority, only priority -MAXPRIORITY gets the
special meaning of "may be deta
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
> On 27.02.2012 14:33, Frank Schmirler wrote:
> > I suggest the following additional changes:
> > - instead of any negative priority, only priority -MAXPRIORITY gets the
> > special meaning of "may be detached anytime"
> > - the constructo
Am 27.02.2012 14:33, schrieb Frank Schmirler:
> Instead of a configurable "LiveTV priority", your approach uses the fixed
> priority value 0 for LiveTV. The new idle priority of -100 opens the range for
> cReceivers with negative priority. The problem is, that *any* negative
> priority is still con
On 27.02.2012 14:33, Frank Schmirler wrote:
On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
There was also apparently some misunderstanding about what
PrimaryLimit was supposed to do. It was *never* meant to allow
"Channel switching can cancel timers with priority<=
Setup.PrimaryLimi
On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
> There was also apparently some misunderstanding about what
> PrimaryLimit was supposed to do. It was *never* meant to allow
> "Channel switching can cancel timers with priority <=
> Setup.PrimaryLimit" (as noted at the bottom of http:
On 25.02.2012 00:21, Frank Schmirler wrote:
On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
IIRC that whole "Primary Limit" thing was introduced because in the
beginning
the full featured DVB cards were unable to record and play at the same
On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote
> Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
> > IIRC that whole "Primary Limit" thing was introduced because in the
> > beginning
> > the full featured DVB cards were unable to record and play at the same
> > time.
> > So it could happen t
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
> On 24.02.2012 15:37, Frank Schmirler wrote:
>> On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
>>> - Fixed handling the PrimaryLimit when requesting a device for live
>>> viewing
>>> (reported by Uwe Scheffler).
Hmmm, didn't even n
On 24.02.2012 15:37, Frank Schmirler wrote:
Hi,
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
- Fixed handling the PrimaryLimit when requesting a device for live viewing
(reported by Uwe Scheffler).
Refers to the following change in device.c:
- if (device[i]->Provi
Hi,
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
> - Fixed handling the PrimaryLimit when requesting a device for live viewing
>(reported by Uwe Scheffler).
Refers to the following change in device.c:
- if (device[i]->ProvidesChannel(Channel, Priority, &ndr)) { // thi
Am 20.02.2012 10:18, schrieb Klaus Schmidinger:
> On 20.02.2012 00:06, Joerg Riechardt wrote:
>> With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is
>> ok again.
>> Other patches were not involved.
>> Jörg
>
> Well, then I guess it's best if I revoke that change.
> Any objections?
On 2012-02-20 11:18, Klaus Schmidinger wrote:
> On 20.02.2012 00:06, Joerg Riechardt wrote:
>
>> With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok
>> again.
>> Other patches were not involved.
>> Jörg
>
> Well, then I guess it's best if I revoke that change.
> Any objections
On 20.02.2012 00:06, Joerg Riechardt wrote:
Am 19.02.2012 22:04, schrieb Klaus Schmidinger:
On 19.02.2012 20:45, Joerg Riechardt wrote:
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes
Am 19.02.2012 22:04, schrieb Klaus Schmidinger:
On 19.02.2012 20:45, Joerg Riechardt wrote:
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. H
On 19.02.2012 20:45, Joerg Riechardt wrote:
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made wi
Am 19.02.2012 19:51, schrieb Joerg Riechardt:
Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made with 1.7.24.
With 1.7.23 no problem.
This hap
Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made with 1.7.24.
With 1.7.23 no problem.
Jörg
___
On 19.02.2012 14:54, Klaus Schmidinger wrote:
VDR developer version 1.7.24 is now available ...
...
- Fixed switching into time shift mode when pausing live video (thanks to
Reinhard
Nissl for helping to debug this one).
Just realized that on channels with 50fps the info file needs
to be re-
85 matches
Mail list logo
