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 00001.ts (previously 001.vdr). + The frame rate is now detected by looking at two subsequent PTS values. The "frame duration" (in multiples of 1/90000) 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 YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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 subtitle track. + cDevice::StillPicture() will now be called with either TS or PES data. + cDvbPlayer::Goto() no longer appends a "sequence end code" to the data. If the output device needs this, it has to take care of it by itself. - Fixed cPatPmtParser::ParsePmt() to reset vpid and vtype when switching from a video to an audio channel (thanks to Reinhard Nissl). - 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.
Have fun!
Klaus
On 06.01.2009 16:06, Klaus Schmidinger wrote:
... The "frame duration" (in multiples of 1/90000) 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
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, -- rofa
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
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.
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.bz2A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.2-1.7.3.diffWARNING:
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 00001.ts (previously
001.vdr).
- The frame rate is now detected by looking at two subsequent PTS
values. The "frame duration" (in multiples of 1/90000) 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 YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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 subtitle track.
- cDevice::StillPicture() will now be called with either TS or PES data.
- cDvbPlayer::Goto() no longer appends a "sequence end code" to the
data. If the output device needs this, it has to take care of it by itself.
- Fixed cPatPmtParser::ParsePmt() to reset vpid and vtype when switching
from a video to an audio channel (thanks to Reinhard Nissl).
- 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.
Have fun!
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger Klaus.Schmidinger@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?
On 16.01.2009 16:07, Tony Houghton wrote:
On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger Klaus.Schmidinger@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
On Fri, 16 Jan 2009 16:19:27 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 16.01.2009 16:07, Tony Houghton wrote:
On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger Klaus.Schmidinger@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?
On 16.01.2009 18:14, Tony Houghton wrote:
On Fri, 16 Jan 2009 16:19:27 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 16.01.2009 16:07, Tony Houghton wrote:
On Fri, 16 Jan 2009 15:53:36 +0100 Klaus Schmidinger Klaus.Schmidinger@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
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
On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
- The directory name for a recording has been changed from YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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:
YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-MM-DD-hh.mm.BBC-ri.rec
On Thu, Jan 8, 2009 at 7:50 PM, user. vdr user.vdr@gmail.com wrote:
On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
- The directory name for a recording has been changed from YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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:
YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-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
On 08.01.2009 20:41, Alex Betis wrote:
On Thu, Jan 8, 2009 at 7:50 PM, user. vdr <user.vdr@gmail.com mailto:user.vdr@gmail.com> wrote:
On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de <mailto:Klaus.Schmidinger@cadsoft.de>> wrote: > + The directory name for a recording has been changed from > YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to > YYYY-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: YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-MM-DD-hh.mm.BBC-ri.recI 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
On Thu, Jan 8, 2009 at 11:17 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> wrote:
On 08.01.2009 20:41, Alex Betis wrote:
On Thu, Jan 8, 2009 at 7:50 PM, user. vdr <user.vdr@gmail.com mailto:user.vdr@gmail.com> wrote:
On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de <mailto:Klaus.Schmidinger@cadsoft.de>> wrote: > + The directory name for a recording has been changed from > YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to > YYYY-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 channelshortname,
for example: YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-MM-DD-hh.mm.BBC-ri.recI 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
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
On 08.01.2009 18:50, user.vdr wrote:
On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
- The directory name for a recording has been changed from YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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:
YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-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
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.Schmidinger@cadsoft.de wrote:
- The directory name for a recording has been changed from YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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:
YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-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).
YYYY-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").
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.Schmidinger@cadsoft.de wrote:
- The directory name for a recording has been changed from YYYY-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to YYYY-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:
YYYY-MM-DD-hh.mm.CNN-ri.rec YYYY-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).
YYYY-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
Klaus Schmidinger a écrit :
On 12.01.2009 13:41, Nicolas Huillard wrote:
YYYY-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...
On 12.01.2009 16:01, Nicolas Huillard wrote:
Klaus Schmidinger a écrit :
On 12.01.2009 13:41, Nicolas Huillard wrote:
YYYY-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
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
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
On Mon, Jan 12, 2009 at 9:58 AM, Magnus Hörlin magnus@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?
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
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
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
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
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
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
-
Alex Betis -
Frank Schmirler -
gimli -
Guy Roussin -
Klaus Schmidinger -
Magnus Hörlin -
Nicolas Huillard -
Oliver Joa -
Reinhard Nissl -
Richard Lithvall -
Rolf Ahrenberg -
Tony Houghton -
Udo Richter -
user.vdr