Am 27.03.2011 16:45, schrieb Klaus Schmidinger:
> Can you please rewrite your patch so that it keeps the original 'd'
> variable? I liked the fact that the 'nextUpdate' variable was incremented
> in *one* place, and not in several places. Made the whole thing more
> transparent to me. Besides, I co
Am Montag, 28. März 2011, um 18:17:50 schrieb Klaus Schmidinger:
> void cRecorder::Action(void)
> {
>...
>if (frameDetector->Synced()) {
> if (!InfoWritten) {
> cRecordingInfo RecordingInfo(recordingName);
> if (Recordi
On 28.03.2011 11:24, Tim wrote:
Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger:
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
I just made a recording from "arte HD" with VDR 1.7.17 and everything
worked fine. It played correctly (on a TT-S2 6400 prot
On 28.03.2011 11:24, Tim wrote:
Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger:
- Fixed detecting frames on channels that broadcast with 50 or 60 fps.
I just made a recording from "arte HD" with VDR 1.7.17 and everything
worked fine. It played correctly (on a TT-S2 6400 prot
On Mon, Mar 28, 2011 at 2:24 AM, Tim wrote:
>> >> - Fixed detecting frames on channels that broadcast with 50 or 60 fps.
>
>> I just made a recording from "arte HD" with VDR 1.7.17 and everything
>> worked fine. It played correctly (on a TT-S2 6400 prototype), the current
>> and total times displa
Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger:
> >> - Fixed detecting frames on channels that broadcast with 50 or 60 fps.
> I just made a recording from "arte HD" with VDR 1.7.17 and everything
> worked fine. It played correctly (on a TT-S2 6400 prototype), the current
> and to
On 20.03.2011 21:07, Udo Richter wrote:
Am 20.03.2011 13:31, schrieb Klaus Schmidinger:
On 20.03.2011 12:46, Klaus Schmidinger wrote:
I have attached a patch that implements this.
Would this be ok?
Sorry, there was a line missing that makes sure the initial load
takes place. Attached is a rev
Am 20.03.2011 13:31, schrieb Klaus Schmidinger:
> On 20.03.2011 12:46, Klaus Schmidinger wrote:
>> I have attached a patch that implements this.
>> Would this be ok?
>
> Sorry, there was a line missing that makes sure the initial load
> takes place. Attached is a revised version of the patch.
You
On 20.03.2011 12:46, Klaus Schmidinger wrote:
> On 19.03.2011 22:42, Klaus Schmidinger wrote:
>> On 19.03.2011 21:56, Udo Richter wrote:
>>> Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
- While replaying, the editing marks are now updated every 10 seconds
(based on a
patch from
On 19.03.2011 22:42, Klaus Schmidinger wrote:
> On 19.03.2011 21:56, Udo Richter wrote:
>> Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
>>> - While replaying, the editing marks are now updated every 10 seconds
>>> (based on a
>>> patch from Manuel Reimer).
>>
>> Thanks for this! With it, the
On 19.03.2011 21:56, Udo Richter wrote:
> Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
>> - While replaying, the editing marks are now updated every 10 seconds (based
>> on a
>> patch from Manuel Reimer).
>
> Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I
> only use
Am 13.03.2011 12:46, schrieb Klaus Schmidinger:
> - While replaying, the editing marks are now updated every 10 seconds (based
> on a
> patch from Manuel Reimer).
Thanks for this! With it, the jumpplay-patch gets obsoleted for me, as I
only used the marks reloading. (As a good-bye, I've posted
In article <4d84ee1d.8090...@gmx.de> you write:
>Am 19.03.2011 18:40, schrieb Juergen Lock:
>> There is one remaining bug tho: After playback of a short recording
>> (sd in this case, 20s or so), vdr seems to kind of hang and I have
>> to kill it... Can you reproduce that? Longer recordings are
Am 19.03.2011 18:40, schrieb Juergen Lock:
> There is one remaining bug tho: After playback of a short recording
> (sd in this case, 20s or so), vdr seems to kind of hang and I have
> to kill it... Can you reproduce that? Longer recordings are not
> affected.
This is probably an old bug: For m
In article <201103191519.p2jfjkzw037...@triton8.kn-bremen.de> you write:
>In article <4d849b3a.6060...@tvdr.de> you write:
>>On 17.03.2011 22:36, Juergen Lock wrote:
>>> In article <4d7caea2.9050...@tvdr.de> you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.t
On 19.03.2011 16:19, Juergen Lock wrote:
> In article <4d849b3a.6060...@tvdr.de> you write:
>> On 17.03.2011 22:36, Juergen Lock wrote:
>>> In article <4d7caea2.9050...@tvdr.de> you write:
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.1
In article <4d849b3a.6060...@tvdr.de> you write:
>On 17.03.2011 22:36, Juergen Lock wrote:
>> In article <4d7caea2.9050...@tvdr.de> you write:
>>> VDR developer version 1.7.17 is now available at
>>>
>>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2
>>>
>>> A 'diff' against the previous v
On 17.03.2011 22:36, Juergen Lock wrote:
> In article <4d7caea2.9050...@tvdr.de> you write:
>> VDR developer version 1.7.17 is now available at
>>
>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2
>>
>> A 'diff' against the previous version is available at
>>
>> ftp://ftp.tvdr.de/vdr/
In article <4d7caea2.9050...@tvdr.de> you write:
>VDR developer version 1.7.17 is now available at
>
> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2
>
>A 'diff' against the previous version is available at
>
> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff
>
>
>
>WARNING:
>==
Hi,
Am 14.03.2011 09:54, schrieb Simon Baxter:
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter
wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting
these error
messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching
to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [1072
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter
wrote:
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error
messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Th
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter wrote:
> Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error
> messages.
>
> Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
> mode
> Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error
messages.
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2
mode
Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2
mode
Mar 14 20:08:55 freddy vdr: [10728] cVideoRepacker: swi
On 13.03.2011 14:38, Matti Lehtimäki wrote:
> On 2011-03-13 13:46, Klaus Schmidinger wrote:
>
>> - Changed the compiler optimization flag to -O3, which gives quite a
>> performance
>>boost in the AlphaBlend() function.
>
> I noticed that this change was not made to Make.config.template as it
On 2011-03-13 13:46, Klaus Schmidinger wrote:
- Changed the compiler optimization flag to -O3, which gives quite a performance
boost in the AlphaBlend() function.
I noticed that this change was not made to Make.config.template as it
should be since Make.config overrides CFLAGS and CXXFLAGS
On 13.03.2011 14:11, Luca Olivetti wrote:
> Al 13/03/11 12:46, En/na Klaus Schmidinger ha escrit:
>
>> This version introduces support for TrueColor OSD.
>> Note, though, that output plugins need to be enhanced in order
>> to support actual TrueColor display (if the device they control
>> can hand
Al 13/03/11 12:46, En/na Klaus Schmidinger ha escrit:
> This version introduces support for TrueColor OSD.
> Note, though, that output plugins need to be enhanced in order
> to support actual TrueColor display (if the device they control
> can handle TrueColor).
And if it cannot, will it work wi
VDR developer version 1.7.17 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff
WARNING:
This is a *developer* version. Even though *I* use it
28 matches
Mail list logo
