Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 06.01.2009 16:06, Klaus Schmidinger wrote: > ... > The "frame duration" (in multiples of 1/9) is stored in the info.vdr > file using the new tag F Sorry, this is actually the "frames per second" ("frame duration" was my initial approach, and apparently I haven't updated the HISTORY

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Tue, 6 Jan 2009, Klaus Schmidinger wrote: - cDvbDevice now uses the FE_CAN_2G_MODULATION flag to determine whether a device can handle DVB-S2. The #define is still there to allow people with older drivers who don't need DVB-S2 to use this version without pathcing. Sorry for hijacking th

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 06.01.2009 17:32, Rolf Ahrenberg wrote: > On Tue, 6 Jan 2009, Klaus Schmidinger wrote: > >> - cDvbDevice now uses the FE_CAN_2G_MODULATION flag to determine >> whether a device >> can handle DVB-S2. The #define is still there to allow people with >> older drivers >> who don't need DVB-S2 to u

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 07.01.2009 12:42, lucian orasanu wrote: > Hy Klaus, > > So with this version we wont need h264 patch? No, because the parts that patch addressed are gone. It's not yet totally clear, though, whether the new cFrameDetector actually works as expected for all HD broadcasts, but it did work as fa

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus, I get a error while compiling this version: g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVIDEODIR=\"/video\" -DCONFDIR=\

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 07.01.2009 13:43, jean-p...@goedee.nl wrote: > Klaus, > > I get a error while compiling this version: > > g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD > -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SO

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

>> Try typecasting the first parameter, as in > >> off_t headdrop = min(off_t(curpos - totwritten), off_t(totwritten * 2)); > >> Klaus > > > I think the compiler is not the problem (same version). Trying the > next option. > > gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 1

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 07.01.2009 15:14, Mika Laitio wrote: >>> Try typecasting the first parameter, as in >>> off_t headdrop = min(off_t(curpos - totwritten), off_t(totwritten * 2)); >>> Klaus >> >> I think the compiler is not the problem (same version). Trying the >> next option. >> >> gcc (SUSE Linux) 4.3.1 200805

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Hi >>> I think the compiler is not the problem (same version). Trying the >>> next option. >>> >>> gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision >>> 135036] >>> Copyright (C) 2008 Free Software Foundation, Inc. >> >> I had same problem with gcc 4.3.2 on Mandriva. (x86_64

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

>>> gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision >>> 135036] >>> Copyright (C) 2008 Free Software Foundation, Inc. >> >> I had same problem with gcc 4.3.2 on Mandriva. (x86_64 env) >> Adding off_t() typecasting for the first parameter as you suggested fixed >> it. Klaus do

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 07.01.2009 15:35, jean-p...@goedee.nl wrote: > I'm using SuSe linux > > openSUSE 11.0 (X86-64) > VERSION = 11.0 > > with > > Linux Baby 2.6.25.11-0.1-default #1 SMP 2008-07-13 20:48:28 +0200 > x86_64 x86_64 x86_64 GNU/Linux > > and make for compiling. Noting spacial I guess I see now: the

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger a écrit : > If you're using the same compiler as I do, I don't see why such > a typecast is necessary on your side, while on my side it compiles > just fine. > > Are you using any different compiler options than me? Didn't I read x86_64 for Mika, when you may use x86_32, Klaus ?

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 07.01.2009 18:58, Nicolas Huillard wrote: > Klaus Schmidinger a écrit : >> If you're using the same compiler as I do, I don't see why such >> a typecast is necessary on your side, while on my side it compiles >> just fine. >> >> Are you using any different compiler options than me? > > Didn't

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Hi, Compiling on ARCH Linux x86_64 with gcc 4.3.2 also fails. So it must be the 64 bit compiler. mfg Edgar (gimli) Hucek > On 07.01.2009 18:58, Nicolas Huillard wrote: >> Klaus Schmidinger a écrit : >>> If you're using the same compiler as I do, I don't see why such >>> a typecast is necessary

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Hi, according to documentation, cTsToPes::GetPes() shall return a complete PES packet. The attached diff fixes this. cDevice::PlayTsAudio() and cDevice::PlayTsSubtitle() have to return the Length passed as parameter. But cTsToPes::GetPes() modified this parameter. The attached diff fixes this lik

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Hi, on playback old HDTV recordings the timline is wrong. >From a first look it seems to show the double length of the recording. cu Edgar (gimli) Hucek > VDR developer version 1.7.3 is now available at > > ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.3.tar.bz2 > > A 'diff' against the prev

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Tue, 06 Jan 2009 16:06:02 +0100, Klaus Schmidinger wrote > Instead of Priority and Lifetime, the directory name now contains the > channel number from which the recording was made, and the "resume > id" of this instance of VDR. This avoids problems if several VDR > instances record the same

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger wrote: > + The directory name for a recording has been changed from >-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to >-MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resumeId). Is the channel number even necessary information to st

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Thu, Jan 8, 2009 at 7:50 PM, user. vdr wrote: > On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger > wrote: > > + The directory name for a recording has been changed from > >-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to > >-MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resum

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 08.01.2009 18:50, user.vdr wrote: > On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger > wrote: >> + The directory name for a recording has been changed from >>-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to >>-MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resumeId). > > Is the

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 08.01.2009 20:41, Alex Betis wrote: > On Thu, Jan 8, 2009 at 7:50 PM, user. vdr > wrote: > > On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger > mailto:klaus.schmidin...@cadsoft.de>> > wrote: > > + The directory name for a recording has been changed

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Thu, Jan 8, 2009 at 11:17 PM, Klaus Schmidinger < klaus.schmidin...@cadsoft.de> wrote: > On 08.01.2009 20:41, Alex Betis wrote: > > On Thu, Jan 8, 2009 at 7:50 PM, user. vdr > > wrote: > > > > On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger > > mailto:klaus

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 08.01.2009 20:41, Alex Betis wrote: > > If the recording timer was set manualy, maybe it should include all > > programs that lay between start and end of the recording. On Thu, Jan 08, 2009 at 10:17:45PM +0100, Klaus Schmidinger wrote: > It stores the EPG data of the longest broadcast within t

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

reinhard.buch...@rw-buchner.de schrieb: > Hmm, I thought it wasn't possible to have two > identical channels (even IF soley the name is > different). Has this changed? You can have multiple channels with the same name, i.e.: Das Erste;ARD:11837:hC34M2O0S0:S19.2E:27500:101=2:102=deu,103=2ch;106=dd

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Hi, there seems to be problem in pausing replays of new recordings (output to FF). 4 out of 5 times vdr freezes when trying to continue the replay. Poll in PlayVideo runs into a timeout and a new write gives EAGAIN. This does not happen with old recordings. Most likely splitting long PES-packets n

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 10.01.2009 21:58, Johann Friedrichs wrote: > there seems to be problem in pausing replays of new recordings (output > to FF). 4 out of 5 times vdr freezes when trying to continue the replay. > Poll in PlayVideo runs into a timeout and a new write gives EAGAIN. This > does not happen with old rec

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Mon, Jan 12, 2009 at 10:27:42AM +0100, jean-p...@goedee.nl wrote: > What must I do to make it work with 64bits system? I?m a simple user > with no coding experience. Could you post your error, I am under x86_64 and only patch I needed was one found on vdrportal.de : --- tools.c 2009-0

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger a écrit : > On 08.01.2009 18:50, user.vdr wrote: >> On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger >> wrote: >>> + The directory name for a recording has been changed from >>>-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to >>>-MM-DD-hh.mm.ch-ri.rec (ch

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 12.01.2009 13:41, Nicolas Huillard wrote: > Klaus Schmidinger a écrit : >> On 08.01.2009 18:50, user.vdr wrote: >>> On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger >>> wrote: + The directory name for a recording has been changed from -MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, l

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger a écrit : > On 12.01.2009 13:41, Nicolas Huillard wrote: >> -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR >> instances recording the same show. >> This is a usual problem of multiple instances sharing a single /video dir. >> As we're talking about safety h

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 12.01.2009 16:01, Nicolas Huillard wrote: > Klaus Schmidinger a écrit : >> On 12.01.2009 13:41, Nicolas Huillard wrote: >>> -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR >>> instances recording the same show. >>> This is a usual problem of multiple instances sharing a si

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Mon, 12 Jan 2009 16:04:09 +0100, Klaus Schmidinger wrote > On 12.01.2009 16:01, Nicolas Huillard wrote: > > The resume ID is described excactly as I use it : > > "Defines an additional ID that can be used in a multi user > > "environment, so that every user has his/her own resume > > "files for

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger wrote: > On 12.01.2009 16:01, Nicolas Huillard wrote: > > Well, I thought that this id could also be used here, but apparently > I was wrong. > > Ok, then let's have another id for this... > > Klaus > > Thanks. There aren't too many projects of this magnitude that responds

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Mon, Jan 12, 2009 at 9:58 AM, Magnus Hörlin wrote: > Thanks. There aren't too many projects of this magnitude that responds > this quickly to user wishes. Even though I would have liked to see > teletext subs recorded by default and multiple frontend support I > fully understand your priori

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger wrote: [...] > Ok, then let's have another id for this... What about an id which can be set in the config-file? Should be the easiest thing to implement. Olli ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mai

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Hi, with vdr 1.7.3 I had no directory display in the pictures-plugin and crashes in dvdswitch, while it initially scanned the defined base directory for DVD-Images. I found, that with the LARGEFILE options I had to change cReadDir accordingly to use dirent64 and readdir64_r (tools.h, tools.c) Th

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 08.01.2009 07:32, gimli wrote: > Hi, > > on playback old HDTV recordings the timline is wrong. >>From a first look it seems to show the double length > of the recording. I assume those "old HDTV" recordings were done in PES. VDR 1.7.3 and up is probably not compatible with such recordings. Kl

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger wrote: > I assume those "old HDTV" recordings were done in PES. > VDR 1.7.3 and up is probably not compatible with such recordings. Are you planning to add backwards compatibility or will we need to convert our old recordings? -- TH * http:/

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 16.01.2009 16:07, Tony Houghton wrote: > On Fri, 16 Jan 2009 15:53:36 +0100 > Klaus Schmidinger wrote: > >> I assume those "old HDTV" recordings were done in PES. >> VDR 1.7.3 and up is probably not compatible with such recordings. > > Are you planning to add backwards compatibility or will w

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On Fri, 16 Jan 2009 16:19:27 +0100 Klaus Schmidinger wrote: > On 16.01.2009 16:07, Tony Houghton wrote: > > On Fri, 16 Jan 2009 15:53:36 +0100 > > Klaus Schmidinger wrote: > > > >> I assume those "old HDTV" recordings were done in PES. > >> VDR 1.7.3 and up is probably not compatible with such

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 16.01.2009 18:14, Tony Houghton wrote: > On Fri, 16 Jan 2009 16:19:27 +0100 > Klaus Schmidinger wrote: > >> On 16.01.2009 16:07, Tony Houghton wrote: >>> On Fri, 16 Jan 2009 15:53:36 +0100 >>> Klaus Schmidinger wrote: >>> I assume those "old HDTV" recordings were done in PES. VDR 1.

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 13.01.2009 10:44, Oliver Joa wrote: > Klaus Schmidinger wrote: > > [...] > >> Ok, then let's have another id for this... > > What about an id which can be set in the config-file? Should be the > easiest thing to implement. I was more thinking of a command line option, because this is an "in

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 06.01.2009 16:06, Klaus Schmidinger wrote: > - Recording files larger than 4GB or with more than 255 separate >files hasn't been tested yet. > + The index file format has been changed to support file sizes of up to 1TB > (previously 2GB), and up to 65535 separate files per recording (previ

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 24.01.2009 15:19, Udo Richter wrote: > On 06.01.2009 16:06, Klaus Schmidinger wrote: >> - Recording files larger than 4GB or with more than 255 separate >>files hasn't been tested yet. >> + The index file format has been changed to support file sizes of up to 1TB >> (previously 2GB), and u

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger a écrit : > On 24.01.2009 15:19, Udo Richter wrote: > >> On 06.01.2009 16:06, Klaus Schmidinger wrote: >> >>> - Recording files larger than 4GB or with more than 255 separate >>>files hasn't been tested yet. >>> + The index file format has been changed to support file

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

On 24.01.2009 23:23, Guy Roussin wrote: > ... > Why this 1TB limitation ? The index file uses 8 byte per entry, two of which are now used for the file number, one bit is used to identify "independent" frames, and 40 bits are used for the actual file offset. The remaining 7 bits are reserved for fu

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

Klaus Schmidinger a écrit : > On 24.01.2009 23:23, Guy Roussin wrote: > >> ... >> Why this 1TB limitation ? >> > > The index file uses 8 byte per entry, two of which are now > used for the file number, one bit is used to identify "independent" > frames, and 40 bits are used for the actual f

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3 (streamdev)

On Mon, 12 Jan 2009 11:30:36 +0100, jean-paul wrote > Thanks its compiling but I get now a error with compiling streamdev. Patch: http://www.vdr-developer.org/mantisbt/view.php?id=506 Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxt