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

[Guy Roussin]

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 file offset. The
> remaining 7 bits are reserved for future use ;-)
>   

Good to know there is 7 bits reserved.
In less than ten years we can buy hard drives (or other media) from
one petabyte. We will have to fill them ;-)
I suppose future vdr user want to record some channels for one year or 
more ...

Guy


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 future use ;-)

40 bit allows access to 1TB, which, assuming 2GB per hour (for current
SD recordings) means a single file recording can be some 500 hours
long. That makes 20 whole days in a single recording. Ok, let's assume
HD recordings need like 4GB per hour, then you still have 10 days
in a single recording.

If you actually have a need to record more than that in one single
recording, we can use some of the reserved bits to increase that
number ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Guy Roussin]

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 sizes of up to 1TB
>>>   (previously 2GB), and up to 65535 separate files per recording (previously
>>>   255).
>>>   
>> Untested indeed. Theres still this line in recording.h:
>>
>> #define MAXVIDEOFILESIZE 2000 // MB
>>
>> Just in case it slipped through.
>> 
>
> Thanks. I forgot to make this two, one for PES and one for TS.
>
>   
Hi Klaus,

Why this 1TB limitation ?

Guy


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 up to 65535 separate files per recording (previously
>>   255).
> 
> Untested indeed. Theres still this line in recording.h:
> 
> #define MAXVIDEOFILESIZE 2000 // MB
> 
> Just in case it slipped through.

Thanks. I forgot to make this two, one for PES and one for TS.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Udo Richter]

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 (previously
>   255).

Untested indeed. Theres still this line in recording.h:

#define MAXVIDEOFILESIZE 2000 // MB

Just in case it slipped through.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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
"instance specific" option and doesn't need to be changed at runtime.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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.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?
>> The official VDR never recorded any HDTV PES data, so there will be
>> no backwards compatibility.
> 
> Oh, I missed the bit about HDTV. PES SD recordings are still supported
> then?

Of course - and always will be.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Tony Houghton]

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 recordings.
> > 
> > Are you planning to add backwards compatibility or will we need to
> > convert our old recordings?
> 
> The official VDR never recorded any HDTV PES data, so there will be
> no backwards compatibility.

Oh, I missed the bit about HDTV. PES SD recordings are still supported
then?

-- 
TH * http://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 we need to
> convert our old recordings?

The official VDR never recorded any HDTV PES data, so there will be
no backwards compatibility.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Tony Houghton]

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://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Johann Friedrichs]

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)

Those Plugins, using cReadDir like pictures, epgsearch, dvdswitch then
also had to change dirent to dirent64. With these changes the plugins
are working again (Base system is Debian etch).

Regards
Johann

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Oliver Joa]

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/mailman/listinfo/vdr

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

[user . vdr]

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 priorities.

Why not 'include teletext/closed-captioning in recordings?' as a setup option?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Magnus Hörlin]

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 
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 priorities.
/Magnus H


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Frank Schmirler]

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 each recording. The valid range is 0...99, with
> > "0 resulting in a file named 'resume.vdr', and any other
> > "value resulting in 'resume.n.vdr'.
> > 
> > ie. it does not define the VDR instance, but the "user instance"...
> > In practice, I set this to the same 0 value on every VDR, because I want 
> > to be able to stop a replay on one VDR, and continue viewing it on 
> > another VDR, starting at the position I stopped it...
> 
> 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...

Much appreciated - thanks!

Frank

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 single /video dir.
>>> As we're talking about safety here, why not address it right now, once 
>>> and for all ?
>> I did - by using the "resume id". This should be unique for any VDR instance
>> accessing a common video directory.
> 
> Well, I re-read the MANUAL regarding this issue before my posting above ;-)
> 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 each recording. The valid range is 0...99, with
> "0 resulting in a file named 'resume.vdr', and any other
> "value resulting in 'resume.n.vdr'.
> 
> ie. it does not define the VDR instance, but the "user instance"...
> In practice, I set this to the same 0 value on every VDR, because I want 
> to be able to stop a replay on one VDR, and continue viewing it on 
> another VDR, starting at the position I stopped it...

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Nicolas Huillard]

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 here, why not address it right now, once 
>> and for all ?
> 
> I did - by using the "resume id". This should be unique for any VDR instance
> accessing a common video directory.

Well, I re-read the MANUAL regarding this issue before my posting above ;-)
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 each recording. The valid range is 0...99, with
"0 resulting in a file named 'resume.vdr', and any other
"value resulting in 'resume.n.vdr'.

ie. it does not define the VDR instance, but the "user instance"...
In practice, I set this to the same 0 value on every VDR, because I want 
to be able to stop a replay on one VDR, and continue viewing it on 
another VDR, starting at the position I stopped it...

-- 
NH

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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, lt=lifetime) to
-MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resumeId).
>>> Is the channel number even necessary information to store in a
>>> dirname?  I've experienced many times where channels have been
>>> shuffled (requiring a rescanning & a new channels.conf)
>>> so channel 100 could be one network today and a different one
>>> tomorrow.  Maybe a better choice would be using the channel shortname,
>>> for example:
>>>
>>> -MM-DD-hh.mm.CNN-ri.rec
>>> -MM-DD-hh.mm.BBC-ri.rec
>> The channel number would be unnecessary, because that information
>> is stored in the 'info' file. However, it is contained in the
>> recording's directory name, so that in case two timers of the same VDR
>> instance record the exact same programme, but on different channels,
>> they don't mix their data into one big pile of goo (which could have
>> happenend in VDR 1= 1.7.2). No need to make this a string - it's just
>> a safety precaution (besides, two channels might have the *same* name,
>> but never the same number).
> 
> -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 here, why not address it right now, once 
> and for all ?

I did - by using the "resume id". This should be unique for any VDR instance
accessing a common video directory.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Nicolas Huillard]

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=channel, ri=resumeId).
>> Is the channel number even necessary information to store in a
>> dirname?  I've experienced many times where channels have been
>> shuffled (requiring a rescanning & a new channels.conf)
>> so channel 100 could be one network today and a different one
>> tomorrow.  Maybe a better choice would be using the channel shortname,
>> for example:
>>
>> -MM-DD-hh.mm.CNN-ri.rec
>> -MM-DD-hh.mm.BBC-ri.rec
> 
> The channel number would be unnecessary, because that information
> is stored in the 'info' file. However, it is contained in the
> recording's directory name, so that in case two timers of the same VDR
> instance record the exact same programme, but on different channels,
> they don't mix their data into one big pile of goo (which could have
> happenend in VDR 1= 1.7.2). No need to make this a string - it's just
> a safety precaution (besides, two channels might have the *same* name,
> but never the same number).

-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 here, why not address it right now, once 
and for all ?

If you do not have a unique identifier for each VDR instance yet, the 
only thing I can think of is "hostname" + "SVDRP port number" (this 
identifies both "single instance on many hosts", and "multiple instances 
on a single host").

-- 
NH

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Frank Schmirler]

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.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Gregoire Favre]

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-01-06 23:09:35.0 +0100
+++ tools.c.mod 2009-01-06 23:09:43.0 +0100
@@ -1608,7 +1608,7 @@
   // kind of write gathering enabled), but the syncs cause (io) 
load..
   // Uncomment the next line if you think you need them.
   //fdatasync(fd);
-  off_t headdrop = min(curpos - totwritten, off_t(totwritten * 2));
+  off_t headdrop = min(off_t(curpos - totwritten), 
off_t(totwritten * 2));
   posix_fadvise(fd, curpos - totwritten - headdrop, totwritten + 
headdrop, POSIX_FADV_DONTNEED);
   totwritten = 0;
   }

(Well I also use patch to allow more features...).
-- 
Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org
   http://picasaweb.google.com/Gregoire.Favre

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Udo Richter]

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 recordings.

I don't like the whole rewrite of PlayVideo/PlayAudio at all. As already 
written in the VDR-1.7.2 topic of VDR portal [1], even playback of PES 
recordings is unstable for me when using the looped PlayVideo functions, 
no matter what fixes were applied. My vote would be to return to the 
simple non-looped version of VDR 1.7.1 and before, where partly written 
buffers timeout after 1s and non-written buffers are rejected instantly.

However, this requires more complex PlayTs functions, as they would 
have to check whether PlayVideo/PlayAudio have read some of the buffers, 
and re-offer the rest on next call, while not accepting any more data 
until the whole buffer got accepted by PlayVideo/PlayAudio. (PutTs 
resets the buffer.)


[1] http://www.vdr-portal.de/board/thread.php?threadid=82622


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Johann Friedrichs]

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 not on frame-boundaries prevents
the FF-driver from finding a good start-point after DvbDevice->Freeze().
A rough workaround is attached, but maybe the idea to dump the old remux
code was not the best one, as long as the FF and some plugins need
PES-output.

Replaying TS with VLC gives lots of TS discontinuities for PID 0 and
132. Attached is a fix.

Regards
Johann
--- vdr-1.7.3/dvbdevice.c.dist	2009-01-10 21:46:50.0 +0100
+++ vdr-1.7.3/dvbdevice.c	2009-01-10 20:39:32.0 +0100
@@ -1302,14 +1302,24 @@ bool cDvbDevice::Flush(int TimeoutMs)
   return true;
 }
 
+#define MAXPOLLTIMEOUTS 10
+
 int cDvbDevice::PlayVideo(const uchar *Data, int Length)
 {
   int w;
+  int PollTimeouts = 0;
   do {
  w = WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
+ if (w < 0 && FATALERRNO) return w;
  if (w < 0 && errno == EAGAIN) {
 cPoller Poller(fd_video, true);
-Poller.Poll(200);
+	if (Poller.Poll(200)) PollTimeouts = 0;
+	else PollTimeouts++;
+	if (PollTimeouts == MAXPOLLTIMEOUTS) {
+	   dsyslog("PlayVideo returns -%d and reached PollTimeouts", -w);
+	   Clear();
+	   return w;
+   }
 }
  } while (w != Length);
   return w;
--- vdr-1.7.3/remux.c.dist	2009-01-07 20:40:53.0 +0100
+++ vdr-1.7.3/remux.c	2009-01-10 14:48:31.0 +0100
@@ -320,7 +320,7 @@ uchar *cPatPmtGenerator::GetPat(void)
 uchar *cPatPmtGenerator::GetPmt(int &Index)
 {
   if (Index < numPmtPackets) {
- IncCounter(patCounter, pmt[Index]);
+ IncCounter(pmtCounter, pmt[Index]);
  return pmt[Index++];
  }
   return NULL;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Christian Tramnitz]

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:104:0:28106:1:1101:0
Das Erste;ARD:10723:hC34M2O0S0:S13.0E:29900:0=2:0:0:0:28106:1:1101:0

If you want to have a unique id for a channel, that would be that 
channel ID, not its name, man 5 vdr states:
A particular channel can be uniquely identified by its channel ID, 
which  is  a  string  that looks like this:
S19.2E-1-1089-12003-0

In this particular case however using the channel number serves the only 
purpose to prevent multiple recordings writing into the same directory 
and for this purpose using the sole channel number is sufficient.


> 
> Another question: what happens to the info file
> when I make an instant recording (or a timer for
> that matter) than spans across more than one
> "show"? VDR used to only store the info (epg
> data) from the first show. Personally, I think
> VDR should record ALL show info (epg data) as
> long as the timer or instant recording is
> running. Perhaps with a divider between the
> multiple shows.
> 
> Of course the question is how to distinguish
> between simple pre and post timer times and
> true multiple shows (perhaps only record the
> info if the multiple show has finished being
> aired or a similiar mechanism.

Just follow the other posts in this thread, the exact same discussion is 
already going on with a comment from Klaus regarding the current behaviour.


Best regards,
   Christian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Richard Lithvall]

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 the timer window.

I often schedule short cartoon episodes for the kids and with 5 min margins
before and after the schedule it most often ends up with EPG data from
the broadcast before or after the scheduled one.
With that said I think that Alex's proposal sounds good (but it should
not be limited to manually set timers).
Another idea would be to pick the EPG data from the broadcast that
occurs in the middle of the scheduled timer (but that would not be ideal
in the case when you manually schedule several broadcasts in a single
timer)

/Richard

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Alex Betis]

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.schmidin...@cadsoft.de>>
> > 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 store in a
> > dirname?  I've experienced many times where channels have been
> > shuffled (requiring a rescanning & a new channels.conf)
> > so channel 100 could be one network today and a different one
> > tomorrow.  Maybe a better choice would be using the channel
> shortname,
> > for example:
> >
> > -MM-DD-hh.mm.CNN-ri.rec
> > -MM-DD-hh.mm.BBC-ri.rec
> >
> >
> > I don't know how VDR work, but I think it will be wise to have a file
> > with the same filename and ".info" or even ".epg" extension that will
> > have relevant EPG section for the recorded program including full
> > channel name.
>
> That's all already contained in the 'info' file of a recording.

Great! So I didn't reinvent the wheel :)


>
>
> > If the recording timer was set manualy, maybe it should include all
> > programs that lay between start and end of the recording.
>
> It stores the EPG data of the longest broadcast within the timer window.

That's fine if only one program is intended to be recorded. What if someone
wants to record a bunch of programs?
There are lots of music shows in the night between 31/12 and 01/01 of every
year. With old tape recorder I just pressed REC and hope that the tape will
contain as many programs as possible. In such case I would like to see all
recorded programs descriptions.



>
> Klaus
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 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 store in a
> dirname?  I've experienced many times where channels have been
> shuffled (requiring a rescanning & a new channels.conf)
> so channel 100 could be one network today and a different one
> tomorrow.  Maybe a better choice would be using the channel shortname,
> for example:
> 
> -MM-DD-hh.mm.CNN-ri.rec
> -MM-DD-hh.mm.BBC-ri.rec
> 
> 
> I don't know how VDR work, but I think it will be wise to have a file
> with the same filename and ".info" or even ".epg" extension that will
> have relevant EPG section for the recorded program including full
> channel name.

That's all already contained in the 'info' file of a recording.

> If the recording timer was set manualy, maybe it should include all
> programs that lay between start and end of the recording.

It stores the EPG data of the longest broadcast within the timer window.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 channel number even necessary information to store in a
> dirname?  I've experienced many times where channels have been
> shuffled (requiring a rescanning & a new channels.conf)
> so channel 100 could be one network today and a different one
> tomorrow.  Maybe a better choice would be using the channel shortname,
> for example:
> 
> -MM-DD-hh.mm.CNN-ri.rec
> -MM-DD-hh.mm.BBC-ri.rec

The channel number would be unnecessary, because that information
is stored in the 'info' file. However, it is contained in the
recording's directory name, so that in case two timers of the same VDR
instance record the exact same programme, but on different channels,
they don't mix their data into one big pile of goo (which could have
happenend in VDR 1= 1.7.2). No need to make this a string - it's just
a safety precaution (besides, two channels might have the *same* name,
but never the same number).

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Alex Betis]

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=resumeId).
>
> Is the channel number even necessary information to store in a
> dirname?  I've experienced many times where channels have been
> shuffled (requiring a rescanning & a new channels.conf)
> so channel 100 could be one network today and a different one
> tomorrow.  Maybe a better choice would be using the channel shortname,
> for example:
>
> -MM-DD-hh.mm.CNN-ri.rec
> -MM-DD-hh.mm.BBC-ri.rec


I don't know how VDR work, but I think it will be wise to have a file with
the same filename and ".info" or even ".epg" extension that will have
relevant EPG section for the recorded program including full channel name.
If the recording timer was set manualy, maybe it should include all programs
that lay between start and end of the recording.


>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[user . vdr]

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 store in a
dirname?  I've experienced many times where channels have been
shuffled (requiring a rescanning & a new channels.conf)
so channel 100 could be one network today and a different one
tomorrow.  Maybe a better choice would be using the channel shortname,
for example:

-MM-DD-hh.mm.CNN-ri.rec
-MM-DD-hh.mm.BBC-ri.rec

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Frank Schmirler]

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 show on different channels, or even on 
> the same channel.

I'd opt for a dedicated "VDR instance" parameter instead of using the resume
ID. In my understanding the resume ID corresponds to the actual user watching,
hence the resume ID is subject to change. At least that's how I use it in the
remotetimers-plugin.

Regards,
Frank

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[gimli]

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 previous version is available at
>
>   ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.2-1.7.3.diff
>
>
>
> WARNING:
> 
>
> This is a *developer* version. Not even *I* use it in my productive
> environment. I strongly recommend that you only use it under controlled
> conditions and for testing and debugging.
>
>
>
> The main focus of this version is the switch to Transport Stream (TS)
> as the recording format. There are still a few glitches, mainly
>
> - Recording/replaying of pure audio broadcasts doesn't work yet.
> - Recording files larger than 4GB or with more than 255 separate
>   files hasn't been tested yet.
> - Recording h.264 broadcasts has been roughly verified to work, but
>   no replaying of such recordings has been tested yet.
> - There is apparently still a problem with editing old PES recordings.
>   An edited recording is created, but it doesn't play.
>
> DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!!
> THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE
> AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT
> WORK WITH FUTURE VERSIONS!
> Despite this, I do hope there will be some people who
> can take a look at the changes and maybe test the new
> recording format - and report bugs or provide fixes ,-)
>
>
>
> The changes since version 1.7.2:
>
> - Updated the Russian OSD texts (thanks to Oleg Roitburd).
> - Fixed handling the 'pointer field' in generating and parsing PAT/PMT
> (thanks to
>   Frank Schmirler).
> - Fixed handling modulation types for DVB-S transponders when processing
> the NIT.
> - Changed cDvbDevice::GrabImage() to use V4L2 (thanks to Marco Schlüßler).
> - Added a poll to cDvbDevice::PlayVideo() and cDvbDevice::PlayAudio() to
> avoid
>   excessive CPU load (this is just a makeshift solution until the FF DVB
> cards
>   can play TS directly).
> - The recording format is now Transport Stream. Existing recordings in PES
> format
>   can still be replayed and edited, but new recordings are done in TS.
>   All code for recording in PES has been removed.
>   The following changes were made to switch to TS recording format:
>   + 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
> (previously
> 255).
>   + The recording file names are now of the form 1.ts (previously
> 001.vdr).
>   + The frame rate is now detected by looking at two subsequent PTS
> values.
> The "frame duration" (in multiples of 1/9) is stored in the
> info.vdr
> file using the new tag F (thanks to Artur Skawina for helping to get
> the
> IndexToHMSF() calculation right).
>   + Several functions now have an additional parameter FramesPerSecond.
>   + Several functions now have an additional parameter IsPesRecording.
>   + The functionality of cFileWriter was moved into cRecorder, and cRemux
> is
> now obsolete. This also avoids one level of data copying while
> recording.
>   + cRemux, cRingBufferLinearPes, cTS2PES and all c*Repacker classes have
> been
> removed.
>   + A PAT/PMT is inserted before every independent frame, so that no extra
> measures need to be taken when editing a recording.
>   + 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).
> Priority and Lifetime are now stored in the info.vdr file with the new
> tags P and L (if no such file exists, the maximum values are assumed
> by
> default, which avoids inadvertently deleting a recording if disk space
> is low). No longer storing Priority and Lifetime in the directory name
> avoids starting a new recording if one of these is changed in the
> timer
> and the recording is re-started for some reason.
> 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 show on different channels, or even on the same channel.
> The '-' between channel number and resumeId prevents older versions of
> VDR from "seeing" these recordings, which makes sure they won't even
> try
> to replay them, or remove them in case the disk runs full.
>   + The semantics of PlayTs*() have been changed. These functions are now
> required to return the given Length (which is TS_SIZE) if they have
> processed the TS packet.
>   + The files "index", "info", "marks" and "resume" within a TS recording
> directory are now created without the ".vdr" extension.
>   + The "resume" file is n

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

[Reinhard Nissl]

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 like for
cDevice::PlayTsVideo().

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../vdr-1.7.3-orig/device.c	2009-01-06 10:55:13.0 +0100
+++ device.c	2009-01-07 23:25:51.0 +0100
@@ -1288,8 +1288,9 @@ int cDevice::PlayTsAudio(const uchar *Da
   for (int Pass = 0; Pass < 2; Pass++) {
   if (Pass == 0 && !PayloadStart) // if no new payload is started, we can always put the packet into the converter
  tsToPesAudio.PutTs(Data, Length);
-  if (const uchar *p = tsToPesAudio.GetPes(Length)) {
- int w = PlayAudio(p, Length, 0);
+  int l;
+  if (const uchar *p = tsToPesAudio.GetPes(l)) {
+ int w = PlayAudio(p, l, 0);
  if (w > 0)
 tsToPesAudio.Reset();
  else if (PayloadStart)
@@ -1306,8 +1307,9 @@ int cDevice::PlayTsSubtitle(const uchar
   if (!dvbSubtitleConverter)
  dvbSubtitleConverter = new cDvbSubtitleConverter;
   tsToPesSubtitle.PutTs(Data, Length);
-  if (const uchar *p = tsToPesSubtitle.GetPes(Length)) {
- dvbSubtitleConverter->Convert(p, Length);
+  int l;
+  if (const uchar *p = tsToPesSubtitle.GetPes(l)) {
+ dvbSubtitleConverter->Convert(p, l);
  tsToPesSubtitle.Reset();
  }
   return Length;
--- ../vdr-1.7.3-orig/remux.c	2009-01-06 15:46:21.0 +0100
+++ remux.c	2009-01-07 23:16:54.0 +0100
@@ -559,8 +559,10 @@ const uchar *cTsToPes::GetPes(int &Lengt
 }
  else {
 Length = PesLength(data);
-offset = Length; // to make sure we break out in case of garbage data
-return data;
+if (Length <= length) {
+   offset = Length; // to make sure we break out in case of garbage data
+   return data;
+   }
 }
  }
   return NULL;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[gimli]

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 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 ?
>
> Yes, mine is a 32 bit system.
> I'm pretty sure that's what makes the difference.
>
> Klaus
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
>



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 I read x86_64 for Mika, when you may use x86_32, Klaus ?

Yes, mine is a 32 bit system.
I'm pretty sure that's what makes the difference.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Nicolas Huillard]

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 ?

-- 
NH

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 problem happens when compiling on 64 bit
platforms only.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Mika Laitio]

>>> 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 you remember to fix it for next version without patch?
>
> 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?

At least not intentionally.
I just
- downloaded and extracted vdr-1.7.3.tar.bz2
- cp Make.config.template Make.config
- added to Make.config: DVBDIR = < ..path to my dvb-v4l driver sources)
- make
--> got the error

Mika

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Oleg Roitburd]

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 env)
>> Adding off_t() typecasting for the first parameter as you suggested fixed
>> it. Klaus do you remember to fix it for next version without patch?
>

Without any problem
Debian/Lenny 5.0 : gcc version 4.3.2 (Debian 4.3.2-1.1)
Ubuntu/Hardy 8.04: gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

Regards
Oleg Roitburd

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 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 you remember to fix it for next version without patch?

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?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Mika Laitio]

>> 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 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 you remember to fix it for next version without patch?

Mika

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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_SOURCE -D_LARGEFILE64_SOURCE  
> -DVIDEODIR=\"/video\" -DCONFDIR=\"/video\"  
> -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\"  
> -I/usr/include/freetype2 timers.c
> 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=\"/video\"  
> -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\"  
> -I/usr/include/freetype2 tools.c
> tools.c: In member function ssize_t cUnbufferedFile::Write(const  
> void*, size_t):
> tools.c:1611: error: no matching function for call to min(long  
> unsigned int, off_t)
> make: *** [tools.o] Error 1

Compiles just fine here with

gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE 
Linux)

Try typecasting the first parameter, as in

  off_t headdrop = min(off_t(curpos - totwritten), off_t(totwritten * 2));

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[jean-paul]

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=\"/video\"  
-DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\"  
-I/usr/include/freetype2 timers.c
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=\"/video\"  
-DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\"  
-I/usr/include/freetype2 tools.c
tools.c: In member function ssize_t cUnbufferedFile::Write(const  
void*, size_t):
tools.c:1611: error: no matching function for call to min(long  
unsigned int, off_t)
make: *** [tools.o] Error 1

Al previous versions compiling fine.

Regards,

Jean-



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 far as I was able to test it.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 use this version without pathcing.
> 
> Sorry for hijacking the thread, but you forgot to rename the old
> #define. Check the attached patch.

Sorry about that. Originally I had totally deleted that, but then
decided to leave it in for convenience - and just copied the
original back without changing it.

I guess I'll totally delete it, since this is now in the driver, anyway.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Rolf Ahrenberg]

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 the thread, but you forgot to rename the old 
#define. Check the attached patch.


BR,
--
rofadiff -Nru vdr-1.7.3-vanilla/dvbdevice.c vdr-1.7.3-dvbdevice/dvbdevice.c
--- vdr-1.7.3-vanilla/dvbdevice.c	2009-01-06 18:12:44.0 +0200
+++ vdr-1.7.3-dvbdevice/dvbdevice.c	2009-01-06 18:28:21.0 +0200
@@ -32,7 +32,7 @@
 // unpatched driver. However, with an unpatched driver it will not support
 // DVB-S2 hardware. If you have DVB-S2 hardware you need to either patch
 // the driver or modify the line that uses this macro in cDvbDevice::cDvbDevice().
-#define FE_CAN_2ND_GEN_MODULATION 0x1000
+#define FE_CAN_2G_MODULATION 0x1000
 
 #define DO_REC_AND_PLAY_ON_PRIMARY_DEVICE 1
 #define DO_MULTIPLE_RECORDINGS 1
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

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

[Klaus Schmidinger]

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 file...).
An of course it's now just the "info" file ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr