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 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
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
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
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
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
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
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
On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de 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
On 16.01.2009 16:07, Tony Houghton wrote: On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de 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
On Fri, 16 Jan 2009 16:19:27 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 16.01.2009 16:07, Tony Houghton wrote: On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de 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
On 16.01.2009 18:14, Tony Houghton wrote: On Fri, 16 Jan 2009 16:19:27 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 16.01.2009 16:07, Tony Houghton wrote: On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de 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
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
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
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 (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.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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 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 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
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 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 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
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
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
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 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
On Mon, Jan 12, 2009 at 9:58 AM, Magnus Hörlin mag...@alefors.se 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
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
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
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
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
On 08.01.2009 18:50, user.vdr wrote: On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger 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 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
On 08.01.2009 20:41, Alex Betis wrote: On Thu, Jan 8, 2009 at 7:50 PM, user. vdr user@gmail.com mailto:user@gmail.com wrote: On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger klaus.schmidin...@cadsoft.de 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
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 user@gmail.com mailto:user@gmail.com wrote: On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger klaus.schmidin...@cadsoft.de 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
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, 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
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
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
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
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
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
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
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
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
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
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 no longer a binary file, but contains tagged lines to be able to store additional information, like the selected audio or
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 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
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
