Hi !
After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way.
Plug-ins which possibly could make use of that are: * live * extrecmenu * restfulapi
I'm sure there are more of it.
Has someone allready thought of this ? Are there any plans to have that or someone allready using a patch for this ?
Thanks !
Steffen
Hi Steffen,
On 19.08.2011 11:46, Steffen Barszus wrote:
Hi !
After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way.
Plug-ins which possibly could make use of that are:
- live
- extrecmenu
- restfulapi
I'm sure there are more of it.
Has someone allready thought of this ? Are there any plans to have that or someone allready using a patch for this ?
Please correct me, if I am wrong, but I think vdr-1.7.20 has this feature. Take a look at recording.h:
static int GetLength(const char *FileName, bool IsPesRecording = false); ///< Calculates the recording length (numer of frames) without actually reading the index file. ///< Returns -1 in case of error.
Regards André
On 08/19/11 11:46, Steffen Barszus wrote:
Hi !
After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way.
Plug-ins which possibly could make use of that are:
- live
- extrecmenu
- restfulapi
I'm sure there are more of it.
Has someone allready thought of this ? Are there any plans to have that or someone allready using a patch for this ?
How about cIndexFile::GetLength()? This was newly added in version 1.7.20.
Klaus
On Fri, 19 Aug 2011 12:21:24 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 08/19/11 11:46, Steffen Barszus wrote:
Hi !
After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way.
How about cIndexFile::GetLength()? This was newly added in version 1.7.20.
Not yet - its returning the number of frames - to have one calculation, length in seconds would be required (Ok, its available as well).
Also it reads the index directly (if i'm not mistaken, i can barely read C), which would then be read x-times , where x is the number of plugins using it ( + vdr ? I'm not sure of it ).
I would think that in recording.h as public member of class cRecordingInfo would make sense. In my understanding the recordings information are held in memory after reading it with ScanVideoDir, this should be part of that information in memory (not reading file from disk for this separately).
On 19.08.2011 14:39, Steffen Barszus wrote:
On Fri, 19 Aug 2011 12:21:24 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 08/19/11 11:46, Steffen Barszus wrote:
Hi !
After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way.
How about cIndexFile::GetLength()? This was newly added in version 1.7.20.
Not yet - its returning the number of frames - to have one calculation, length in seconds would be required (Ok, its available as well).
Also it reads the index directly (if i'm not mistaken, i can barely read C), which would then be read x-times , where x is the number of plugins using it ( + vdr ? I'm not sure of it ).
I would think that in recording.h as public member of class cRecordingInfo would make sense. In my understanding the recordings information are held in memory after reading it with ScanVideoDir, this should be part of that information in memory (not reading file from disk for this separately).
I don't want to make this part of the 'info' file. Besides, it's only the directory entry that gets read, not the file itself.
Klaus
On Fri, 19 Aug 2011 14:48:46 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 19.08.2011 14:39, Steffen Barszus wrote:
On Fri, 19 Aug 2011 12:21:24 +0200 Klaus SchmidingerKlaus.Schmidinger@tvdr.de wrote:
On 08/19/11 11:46, Steffen Barszus wrote:
Hi !
After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way.
How about cIndexFile::GetLength()? This was newly added in version 1.7.20.
Not yet - its returning the number of frames - to have one calculation, length in seconds would be required (Ok, its available as well).
Also it reads the index directly (if i'm not mistaken, i can barely read C), which would then be read x-times , where x is the number of plugins using it ( + vdr ? I'm not sure of it ).
I would think that in recording.h as public member of class cRecordingInfo would make sense. In my understanding the recordings information are held in memory after reading it with ScanVideoDir, this should be part of that information in memory (not reading file from disk for this separately).
I don't want to make this part of the 'info' file. Besides, it's only the directory entry that gets read, not the file itself.
Where it gets stored is not my point, that it can be served from in meory data read by ScanVideoDir is my point.
- read&compute by the core - dont access harddisk for known recordings - dont do it multiple times, if more then one part of vdr wants to know it.
If its only in memory and read by the scanner its fine with me.
for medium to large recording base we speak about minutes not milliseconds for reading that data.
Am 19.08.2011 15:30, schrieb Steffen Barszus:
On 08/19/11 11:46, Steffen Barszus wrote:
i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins.
Where it gets stored is not my point, that it can be served from in meory data read by ScanVideoDir is my point.
- read&compute by the core
- dont access harddisk for known recordings
- dont do it multiple times, if more then one part of vdr wants to know it.
If its only in memory and read by the scanner its fine with me.
for medium to large recording base we speak about minutes not milliseconds for reading that data.
Maybe some kind of caching mechanism, but please don't calculate the length every time while doing the scan of the video directory. The directory scanner is already slow enough, no need to add these minutes to it.
Cheers,
Udo
On Fri, 19 Aug 2011 22:18:03 +0200 Udo Richter udo_richter@gmx.de wrote:
Am 19.08.2011 15:30, schrieb Steffen Barszus:
On 08/19/11 11:46, Steffen Barszus wrote:
i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins.
Where it gets stored is not my point, that it can be served from in meory data read by ScanVideoDir is my point.
- read&compute by the core
- dont access harddisk for known recordings
- dont do it multiple times, if more then one part of vdr wants to
know it.
If its only in memory and read by the scanner its fine with me.
for medium to large recording base we speak about minutes not milliseconds for reading that data.
Maybe some kind of caching mechanism, but please don't calculate the length every time while doing the scan of the video directory. The directory scanner is already slow enough, no need to add these minutes to it.
It's slow since it needs to iterate through all recordings and check file size of the index file (thats what i understand from Klaus comment), so divide that by number of frames of the recording and thats it. the directory scanner is anyway doing the same (iterating the video directory and pick up necessary information). So it wouldn't add anything substantially.
On 19.08.2011 23:56, Steffen Barszus wrote:
On Fri, 19 Aug 2011 22:18:03 +0200 Udo Richterudo_richter@gmx.de wrote:
Am 19.08.2011 15:30, schrieb Steffen Barszus:
On 08/19/11 11:46, Steffen Barszus wrote: > i would like to request, that > vdr is storing the length of a recording and make it accessible > to the plug-ins.
Where it gets stored is not my point, that it can be served from in meory data read by ScanVideoDir is my point.
- read&compute by the core
- dont access harddisk for known recordings
- dont do it multiple times, if more then one part of vdr wants to
know it.
If its only in memory and read by the scanner its fine with me.
for medium to large recording base we speak about minutes not milliseconds for reading that data.
Maybe some kind of caching mechanism, but please don't calculate the length every time while doing the scan of the video directory. The directory scanner is already slow enough, no need to add these minutes to it.
It's slow since it needs to iterate through all recordings and check file size of the index file (thats what i understand from Klaus comment), so divide that by number of frames of the recording and thats it. the directory scanner is anyway doing the same (iterating the video directory and pick up necessary information). So it wouldn't add anything substantially.
Would the attached patch work for you? Line numbers may be off a little.
Klaus
On Sun, 21 Aug 2011 15:45:18 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 19.08.2011 23:56, Steffen Barszus wrote:
It's slow since it needs to iterate through all recordings and check file size of the index file (thats what i understand from Klaus comment), so divide that by number of frames of the recording and thats it. the directory scanner is anyway doing the same (iterating the video directory and pick up necessary information). So it wouldn't add anything substantially.
Would the attached patch work for you? Line numbers may be off a little.
Tested and looks good to me. Shows the correct result, where possible, no delay in getting the result and doesnt crash on strange recordings.
Perfect :)
Would love to see this in next developer version :)