vdr November 2005

vdr@linuxtv.org

144 participants
178 discussions

CAM problems
by Timo J. Rinne 23 Nov '05

23 Nov '05

Timo wrote: > Yes, I can see distortions, as a mather of fact there is jump > in recording and screen after that is mixture of previuos "old" > stream and new one with distortions between them. I've also seen this artifact even without multicam stuff a couple of times with a latest few vdr versions, mainly 1.3.34-1.3.36. I think that order of events leading to this has been such that at some point CAM (I have Conax 4.00) has just somehow disappeared and after making a CAM reset it has reappeared after a while. But instead of working correctly, it shows the same kind of symptoms that my namesake above described. Actually since 1.3.33 or so I've had much more problems with CAM than before. After reboot it takes often 15-45 minutes for CAM to be found by vdr. Then after a couple of days it can just disappear. Sometimes when the timer starts to record from encrypted channel, vdr crashes and after it has restarted, CAM isn't on the setup page. Annoying. Anyways, _everything_ else seems to work much better than before. In my setup I've one Hauppauge full with CI and two budget cards. All DVB-C. My stuff runs in 2.4GHz P4 with SUSE 10.0 (linux-2.6.13 kernel). Regards, //Rinne

2 2

vdrconvert activate divx
by Leo Márquez 23 Nov '05

23 Nov '05

Hi!, I'm with vdrconvert. I have a divx list created but when I do activate divx the osd disapear and I continue viewing in the vdrconvert status 'waiting'. I have noticed that the reccmds.conf example file that comes with vdrconvert have: Activate Divx? : printf "\n" >> /usr/bin/vdr2divx (without .sh) The executable file I have after vdrconvert installation is /usr/bin/vdr2divx.sh Are the same this two files? I have tried to change the reccmds.conf file to match my vdr2divx.sh file but don't work. The vdrconvert log is empty. What more can I try? Thanks

2 9

Re: Technotrend Premium DVB-C 2300 OT success stories
by Martin Dauskardt 22 Nov '05

22 Nov '05

> Date: Tue, 22 Nov 2005 16:27:24 +0200 > From: Mika Lehtinen <tengam(a)gmail.com> > Subject: [vdr] Technotrend Premium DVB-C 2300 OT success stories > To: Klaus Schmidinger's VDR <vdr(a)linuxtv.org> > Message-ID: > <b69428070511220627l57ef838kdf9771f710593772(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Can anyone recomend buying a Technotrend Premium DVB-C 2300 OT card > for use with VDR? Can you get it working? I can't seem to be able to > figure out the current driver status from anywhere. It seems, that > there are or at least have been tuning and audio issues. > > It would be great to hear, if someone has had success (tuning, digital > & analogue audio, etc.) with the above card and even better to get > pointers to working Linux kernel versions / patches. > > Thanks, > Mika Hi Mika, you should also ask the guys in the linuxtv mailing list (linux-dvb(a)linuxtv.org) ! this is what I know from www.vdrportal.de: -the card (also known as Nexus-CA) works :-) -sound via the analog output is only possible with patched drivers. There exists an older "quick-and-dirty"-patch, but this patch doesn`t work with the current dvb-kernel CVS. I compiled a kernel 2.6.14 with this patched driver for LinVDR, and the tester said it works ! You can find the patch at http://www.sroegner.de/vdr/patches.php -sound via the digital output works since one or two weeks with the current dvb-kernel drivers. To get both working (analog + digital sound with the same driver) there are two possibilities: -find somebody who is able to modify the "dirty" analog-patch so that it works with the current dvb-kernel -wait until a "clean" solution for analog audio is found, so that it can be integrated officially in the dvb-kernel CVS Hope this helps you!

3 3

[PATCH] UnbufferedFile improvements v2
by Artur Skawina 22 Nov '05

22 Nov '05

This version adds a few minor fixes + cutting speed improvement. well, vdr w/ the recent cUnbufferedFile changes was flushing the data buffers in huge burst; this was even worse than slowly filling up the caches -- the large (IIRC ~10M) bursts caused latency problems (apps visibly freezing etc). This patch makes vdr use a much more aggressive disk access strategy. Writes are flushed out almost immediately and the IO is more evenly distributed. While recording and/or replaying the caches do not grow and when vdr is done accessing a video file all cached data from that file is dropped. I've tested this w/ both local disks and NFS mounted ones, and it seems to do the right thing. Writes get flushed every 1..2s at a rate of .5..1M/s instead of the >10M bursts. For async mounted NFS servers the writes get collected by the NFS server and normally written out. Local disks get an extra feature -- you can use the HD activity LED as a "recording" indicator :^) As posix_advice requires kernel v2.5.60 and glibc v2.2, you'll need at least those versions to see any difference. (w/o posix_advice you will not get the fdatasyncs every 10M - if somebody really wants them they should be controlled by a config option) Possible further improvements could be: switch from POSIX_FADV_SEQUENTIAL to POSIX_FADV_RANDOM, since we're doing manual readahead anyway (or just leave this as is, and drop the readahead) (not using POSIX_FADV_RANDOM is probably one of the causes of the "leaks", so some of the workarounds could then go too) artur --- vdr-1.3.36.org/cutter.c 2005-10-31 13:26:44.000000000 +0100 +++ vdr-1.3.36/cutter.c 2005-11-18 03:20:50.000000000 +0100 @@ -66,6 +66,7 @@ void cCuttingThread::Action(void) toFile = toFileName->Open(); if (!fromFile || !toFile) return; + fromFile->setreadahead(MEGABYTE(10)); int Index = Mark->position; Mark = fromMarks.Next(Mark); int FileSize = 0; @@ -90,6 +91,7 @@ void cCuttingThread::Action(void) if (fromIndex->Get(Index++, &FileNumber, &FileOffset, &PictureType, &Length)) { if (FileNumber != CurrentFileNumber) { fromFile = fromFileName->SetOffset(FileNumber, FileOffset); + fromFile->setreadahead(MEGABYTE(10)); CurrentFileNumber = FileNumber; } if (fromFile) { --- vdr-1.3.36.org/tools.c 2005-11-04 17:33:18.000000000 +0100 +++ vdr-1.3.36/tools.c 2005-11-18 20:33:46.000000000 +0100 @@ -851,8 +851,7 @@ bool cSafeFile::Close(void) // --- cUnbufferedFile ------------------------------------------------------- -#define READ_AHEAD MEGABYTE(2) -#define WRITE_BUFFER MEGABYTE(10) +#define WRITE_BUFFER KILOBYTE(800) cUnbufferedFile::cUnbufferedFile(void) { @@ -869,7 +868,15 @@ int cUnbufferedFile::Open(const char *Fi Close(); fd = open(FileName, Flags, Mode); begin = end = ahead = -1; + readahead = 16*1024; + pendingreadahead = 0; written = 0; + totwritten = 0; + if (fd >= 0) { + // we really mean POSIX_FADV_SEQUENTIAL, but we do our own readahead + // so turn off the kernel one. + posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM); + } return fd; } @@ -880,10 +887,10 @@ int cUnbufferedFile::Close(void) end = ahead; if (begin >= 0 && end > begin) { //dsyslog("close buffer: %d (flush: %d bytes, %ld-%ld)", fd, written, begin, end); - if (written) + if (0 && written) fdatasync(fd); - posix_fadvise(fd, begin, end - begin, POSIX_FADV_DONTNEED); } + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); begin = end = ahead = -1; written = 0; } @@ -899,35 +906,89 @@ off_t cUnbufferedFile::Seek(off_t Offset return -1; } +// when replaying and going eg FF->PLAY the position jumps back 2..8M +// hence we might not want to drop that data at once. +// Ignoring for now to avoid making this even more complex, but we could +// at least try to handle the common cases +// (PLAY->FF->PLAY, small jumps, moving editing marks etc) + ssize_t cUnbufferedFile::Read(void *Data, size_t Size) { if (fd >= 0) { off_t pos = lseek(fd, 0, SEEK_CUR); - // jump forward - adjust end position - if (pos > end) - end = pos; - // after adjusting end - don't clear more than previously requested - if (end > ahead) - end = ahead; - // jump backward - drop read ahead of previous run - if (pos < begin) - end = ahead; + off_t jumped = pos-end; // nonzero means we're not at the last offset - some kind of jump happened. + if (jumped) { + pendingreadahead += ahead-end+KILOBYTE(64); + // jumped forward? - treat as if we did read all the way to current pos. + if (pos > end) { + end = pos; + // but clamp at ahead so we don't clear more than previously requested. + // (would be mostly harmless anyway, unless we got more than one reader of this file) + // add a little extra readahead, JIC the kernel prefethed more than we requested. + if (end > (ahead+KILOBYTE(128))) + end = ahead+KILOBYTE(128); + } + // jumped backward? - drop both last read _and_ read-ahead + if (pos < begin) + end = ahead+KILOBYTE(128); + // jumped backward, but still inside prev read window? - pretend we read less. + if ((pos >= begin) && (pos < end)) + end = pos; + } + + ssize_t bytesRead = safe_read(fd, Data, Size); + + // now drop all data accesed during _previous_ Read(). if (begin >= 0 && end > begin) - posix_fadvise(fd, begin - KILOBYTE(200), end - begin + KILOBYTE(200), POSIX_FADV_DONTNEED);//XXX macros/parameters??? + posix_fadvise(fd, begin, end-begin, POSIX_FADV_DONTNEED); + begin = pos; - ssize_t bytesRead = safe_read(fd, Data, Size); if (bytesRead > 0) { pos += bytesRead; - end = pos; // this seems to trigger a non blocking read - this // may or may not have been finished when we will be called next time. // If it is not finished we can't release the not yet filled buffers. // So this is commented out till we find a better solution. - //posix_fadvise(fd, pos, READ_AHEAD, POSIX_FADV_WILLNEED); - ahead = pos + READ_AHEAD; + + // Hmm, it's obviously harmless if we're actually going to read the data + // -- the whole point of read-ahead is to start the IO early... + // The comment above applies only when we jump somewhere else _before_ the + // IO started here finishes. How common would that be? Could be handled eg + // by posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) called some time after + // we detect a jump. Ignoring this for now. /AS + + // Ugh, it seems to cause some "leaks" at every jump... Either the + // brute force approach mentioned above should work (it's not like this is + // much different than O_DIRECT) or keeping notes about the ahead reads and + // flushing them after some time. the latter seems overkill though, trying + // the former... + + //syslog(LOG_DEBUG,"jump: %06ld ra: %06ld size: %ld", jumped, (long)readahead, (long)Size); + + // no jump? also permit small jump still inside readahead window (FF). + if (jumped>=0 && jumped<=(off_t)readahead) { + if ( readahead <= Size*4 ) // automagically tune readahead size. + readahead = Size*4; + posix_fadvise(fd, pos, readahead, POSIX_FADV_WILLNEED); + ahead = pos + readahead; + } + else { + // jumped - we really don't want any readahead now. otherwise + // eg fast-rewind gets in trouble. + ahead = pos; + + // flush it all; mostly to get rid of nonflushed readahead coming + // from _previous_ jumps. ratelimited. + // the accounting is _very_ unaccurate, i've seen ~50M get flushed + // when the limit was set to 4M. As long as this triggers after + // _some_ jumps we should be ok though. + if (pendingreadahead > MEGABYTE(2)) { + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + pendingreadahead = 0; + } + } } - else - end = pos; + end = pos; return bytesRead; } return -1; @@ -950,11 +1011,19 @@ ssize_t cUnbufferedFile::Write(const voi end = pos + bytesWritten; if (written > WRITE_BUFFER) { //dsyslog("flush buffer: %d (%d bytes, %ld-%ld)", fd, written, begin, end); - fdatasync(fd); - if (begin >= 0 && end > begin) - posix_fadvise(fd, begin, end - begin, POSIX_FADV_DONTNEED); + totwritten += written; + if (begin >= 0 && end > begin) { + off_t headdrop = max((long)begin&~4095,(long)WRITE_BUFFER*2); + posix_fadvise(fd, (begin&~4095)-headdrop, end - begin + headdrop, POSIX_FADV_DONTNEED); + } begin = end = -1; written = 0; + // the above fadvise() works when recording, but seems to leave cached + // data around when writing at a high rate (eg cutting). Hence... + if (totwritten > MEGABYTE(20)) { + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + totwritten = 0; + } } } return bytesWritten; --- vdr-1.3.36.org/tools.h 2005-11-05 11:54:39.000000000 +0100 +++ vdr-1.3.36/tools.h 2005-11-18 03:13:31.000000000 +0100 @@ -209,6 +209,9 @@ private: off_t end; off_t ahead; ssize_t written; + ssize_t totwritten; + size_t readahead; + size_t pendingreadahead; public: cUnbufferedFile(void); ~cUnbufferedFile(); @@ -218,6 +221,7 @@ public: ssize_t Read(void *Data, size_t Size); ssize_t Write(const void *Data, size_t Size); static cUnbufferedFile *Create(const char *FileName, int Flags, mode_t Mode = DEFFILEMODE); + void setreadahead(size_t ra) { readahead = ra; }; }; class cLockFile {

6 9

Technotrend Premium DVB-C 2300 OT success stories
by Mika Lehtinen 22 Nov '05

22 Nov '05

Hi, Can anyone recomend buying a Technotrend Premium DVB-C 2300 OT card for use with VDR? Can you get it working? I can't seem to be able to figure out the current driver status from anywhere. It seems, that there are or at least have been tuning and audio issues. It would be great to hear, if someone has had success (tuning, digital & analogue audio, etc.) with the above card and even better to get pointers to working Linux kernel versions / patches. Thanks, Mika

1 0

transfron is obsolete?
by Leo Márquez 22 Nov '05

22 Nov '05

Hi, i'm trying to compress my recordings in mpeg4/xvid. I know the existence of the transfron plugin but I have downloaded it and have seen that the past version is: 2003-07-25: version 0.3.1 I have tried to compile the plugins but it fails. My VDR version is 1.3.31. There is an actual better way to encode recordings in mpeg4 with vdr? Thanks.

2 4

Problems using cMenuEditTimer in own plugin
by Martin Prochnow 22 Nov '05

22 Nov '05

Hi, i'm using the class cMenuEditTimer to set timer in my epg-plugin. My problem is that i can't use the direction keys of the remote control to select or edit the items within this class. The only thing that works is 'Ok'. I can set a timer but i can't edit the given values. The order of the used classes is the same as in vdr: vdr: cMenuMain (cOsdMenu) -> cMenuWhatsOn (cOsdMenu) -> cMenuEvent (cOsdMenu) -> cMenuEditTimer (cOsdMenu) my plugin: cMenuMain (cOsdMenu) -> myMenuWhatsOn (cOsdMenu) -> myMenuEvent (cOsdMenu) -> cMenuEditTimer (cOsdMenu) The ProcessKey-methods of my classes are nearly the same as in vdr, only some more keys are processed. I'm a beginner in c++, i have my problems with the oop-concepts. It would be great if anybody can help me. Greats Martin P.S.: Sorry for my english. --------------------------------- Gesendet von Yahoo! Mail - Jetzt mit 1GB kostenlosem Speicher

2 2

Re: vdr Digest, Vol 10, Issue 53
by João Mamede 21 Nov '05

21 Nov '05

I really don't know if this is the best place to ask, or a stupid question but...Does vdr works on freeBSD?(or is there anything that does the same)

1 0

[PATCH] UnbufferedFile improvements v3
by Artur Skawina 21 Nov '05

21 Nov '05

Jon Burgess wrote: > > This reminds me of a recent LKML thread. It noted that under some > circumstances the kernel seems to forget to flush the dirty data. It > didn't come to any particular conclusion but maybe there is a problem in > the kernel. It might be an interesting read for you... Hmm, i don't remember exactly how flushing happened before the fdatasyncs appeared; it's possible that that thread could be relevant. So.. here's a version of the patch which lets you choose the strategy at runtime. Simply set the menuitem Setup->Recording->WriteStrategy to 0, 1 or 2 to try them. 0 - STREAM 1 - NORMAL (no fadvise and no fdatasync) 2 - BURST (fadvise plus fdatasync) it's a quick hack, it compiles, but i haven't tested it at all yet... I will probably not be to play with this more in the next days, but maybe somebody else wants to test it... artur --- vdr-1.3.36.org/config.c 2005-09-09 17:08:59.000000000 +0200 +++ vdr-1.3.36/config.c 2005-11-21 22:17:55.000000000 +0100 @@ -453,6 +453,7 @@ bool cSetup::Parse(const char *Name, con else if (!strcasecmp(Name, "UseSmallFont")) UseSmallFont = atoi(Value); else if (!strcasecmp(Name, "MaxVideoFileSize")) MaxVideoFileSize = atoi(Value); else if (!strcasecmp(Name, "SplitEditedFiles")) SplitEditedFiles = atoi(Value); + else if (!strcasecmp(Name, "WriteStrategy")) WriteStrategy = atoi(Value); else if (!strcasecmp(Name, "MinEventTimeout")) MinEventTimeout = atoi(Value); else if (!strcasecmp(Name, "MinUserInactivity")) MinUserInactivity = atoi(Value); else if (!strcasecmp(Name, "MultiSpeedMode")) MultiSpeedMode = atoi(Value); @@ -518,6 +519,7 @@ bool cSetup::Save(void) Store("UseSmallFont", UseSmallFont); Store("MaxVideoFileSize", MaxVideoFileSize); Store("SplitEditedFiles", SplitEditedFiles); + Store("WriteStrategy", WriteStrategy); Store("MinEventTimeout", MinEventTimeout); Store("MinUserInactivity", MinUserInactivity); Store("MultiSpeedMode", MultiSpeedMode); --- vdr-1.3.36.org/config.h 2005-11-04 16:55:05.000000000 +0100 +++ vdr-1.3.36/config.h 2005-11-21 21:57:52.000000000 +0100 @@ -249,6 +249,7 @@ public: int UseSmallFont; int MaxVideoFileSize; int SplitEditedFiles; + int WriteStrategy; int MinEventTimeout, MinUserInactivity; int MultiSpeedMode; int ShowReplayMode; --- vdr-1.3.36.org/cutter.c 2005-10-31 13:26:44.000000000 +0100 +++ vdr-1.3.36/cutter.c 2005-11-18 03:20:50.000000000 +0100 @@ -66,6 +66,7 @@ void cCuttingThread::Action(void) toFile = toFileName->Open(); if (!fromFile || !toFile) return; + fromFile->setreadahead(MEGABYTE(10)); int Index = Mark->position; Mark = fromMarks.Next(Mark); int FileSize = 0; @@ -90,6 +91,7 @@ void cCuttingThread::Action(void) if (fromIndex->Get(Index++, &FileNumber, &FileOffset, &PictureType, &Length)) { if (FileNumber != CurrentFileNumber) { fromFile = fromFileName->SetOffset(FileNumber, FileOffset); + fromFile->setreadahead(MEGABYTE(10)); CurrentFileNumber = FileNumber; } if (fromFile) { --- vdr-1.3.36.org/menu.c 2005-11-05 18:29:22.000000000 +0100 +++ vdr-1.3.36/menu.c 2005-11-21 22:14:38.000000000 +0100 @@ -2270,6 +2270,7 @@ cMenuSetupRecord::cMenuSetupRecord(void) Add(new cMenuEditIntItem( tr("Setup.Recording$Instant rec. time (min)"), &data.InstantRecordTime, 1, MAXINSTANTRECTIME)); Add(new cMenuEditIntItem( tr("Setup.Recording$Max. video file size (MB)"), &data.MaxVideoFileSize, MINVIDEOFILESIZE, MAXVIDEOFILESIZE)); Add(new cMenuEditBoolItem(tr("Setup.Recording$Split edited files"), &data.SplitEditedFiles)); + Add(new cMenuEditIntItem( tr("Setup.Recording$Write strategy"), &data.WriteStrategy, 0, 2)); } // --- cMenuSetupReplay ------------------------------------------------------ --- vdr-1.3.36.org/tools.c 2005-11-04 17:33:18.000000000 +0100 +++ vdr-1.3.36/tools.c 2005-11-21 22:36:11.000000000 +0100 @@ -7,6 +7,7 @@ * $Id: tools.c 1.103 2005/11/04 16:33:18 kls Exp $ */ +#include "config.h" #include "tools.h" #include <ctype.h> #include <dirent.h> @@ -851,8 +852,7 @@ bool cSafeFile::Close(void) // --- cUnbufferedFile ------------------------------------------------------- -#define READ_AHEAD MEGABYTE(2) -#define WRITE_BUFFER MEGABYTE(10) +#define WRITE_BUFFER KILOBYTE(800) cUnbufferedFile::cUnbufferedFile(void) { @@ -869,7 +869,16 @@ int cUnbufferedFile::Open(const char *Fi Close(); fd = open(FileName, Flags, Mode); begin = end = ahead = -1; + readahead = 16*1024; + pendingreadahead = 0; written = 0; + totwritten = 0; + if (fd >= 0) { + // we really mean POSIX_FADV_SEQUENTIAL, but we do our own readahead + // so turn off the kernel one. + if (Setup.WriteStrategy!=1) + posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM); + } return fd; } @@ -882,8 +891,8 @@ int cUnbufferedFile::Close(void) //dsyslog("close buffer: %d (flush: %d bytes, %ld-%ld)", fd, written, begin, end); if (written) fdatasync(fd); - posix_fadvise(fd, begin, end - begin, POSIX_FADV_DONTNEED); } + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); begin = end = ahead = -1; written = 0; } @@ -899,35 +908,89 @@ off_t cUnbufferedFile::Seek(off_t Offset return -1; } +// when replaying and going eg FF->PLAY the position jumps back 2..8M +// hence we might not want to drop that data at once. +// Ignoring for now to avoid making this even more complex, but we could +// at least try to handle the common cases +// (PLAY->FF->PLAY, small jumps, moving editing marks etc) + ssize_t cUnbufferedFile::Read(void *Data, size_t Size) { if (fd >= 0) { off_t pos = lseek(fd, 0, SEEK_CUR); - // jump forward - adjust end position - if (pos > end) - end = pos; - // after adjusting end - don't clear more than previously requested - if (end > ahead) - end = ahead; - // jump backward - drop read ahead of previous run - if (pos < begin) - end = ahead; - if (begin >= 0 && end > begin) - posix_fadvise(fd, begin - KILOBYTE(200), end - begin + KILOBYTE(200), POSIX_FADV_DONTNEED);//XXX macros/parameters??? - begin = pos; + off_t jumped = pos-end; // nonzero means we're not at the last offset - some kind of jump happened. + if (jumped) { + pendingreadahead += ahead-end+KILOBYTE(64); + // jumped forward? - treat as if we did read all the way to current pos. + if (pos > end) { + end = pos; + // but clamp at ahead so we don't clear more than previously requested. + // (would be mostly harmless anyway, unless we got more than one reader of this file) + // add a little extra readahead, JIC the kernel prefethed more than we requested. + if (end > (ahead+KILOBYTE(128))) + end = ahead+KILOBYTE(128); + } + // jumped backward? - drop both last read _and_ read-ahead + if (pos < begin) + end = ahead+KILOBYTE(128); + // jumped backward, but still inside prev read window? - pretend we read less. + if ((pos >= begin) && (pos < end)) + end = pos; + } + ssize_t bytesRead = safe_read(fd, Data, Size); + + // now drop all data accesed during _previous_ Read(). + if (Setup.WriteStrategy!=1 && begin >= 0 && end > begin) + posix_fadvise(fd, begin, end-begin, POSIX_FADV_DONTNEED); + + begin = pos; if (bytesRead > 0) { pos += bytesRead; - end = pos; // this seems to trigger a non blocking read - this // may or may not have been finished when we will be called next time. // If it is not finished we can't release the not yet filled buffers. // So this is commented out till we find a better solution. - //posix_fadvise(fd, pos, READ_AHEAD, POSIX_FADV_WILLNEED); - ahead = pos + READ_AHEAD; + + // Hmm, it's obviously harmless if we're actually going to read the data + // -- the whole point of read-ahead is to start the IO early... + // The comment above applies only when we jump somewhere else _before_ the + // IO started here finishes. How common would that be? Could be handled eg + // by posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) called some time after + // we detect a jump. Ignoring this for now. /AS + + // Ugh, it seems to cause some "leaks" at every jump... Either the + // brute force approach mentioned above should work (it's not like this is + // much different than O_DIRECT) or keeping notes about the ahead reads and + // flushing them after some time. the latter seems overkill though, trying + // the former... + + //syslog(LOG_DEBUG,"jump: %06ld ra: %06ld size: %ld", jumped, (long)readahead, (long)Size); + + // no jump? also permit small jump still inside readahead window (FF). + if (Setup.WriteStrategy!=1 && jumped>=0 && jumped<=(off_t)readahead) { + if ( readahead <= Size*4 ) // automagically tune readahead size. + readahead = Size*4; + posix_fadvise(fd, pos, readahead, POSIX_FADV_WILLNEED); + ahead = pos + readahead; + } + else { + // jumped - we really don't want any readahead now. otherwise + // eg fast-rewind gets in trouble. + ahead = pos; + + // flush it all; mostly to get rid of nonflushed readahead coming + // from _previous_ jumps. ratelimited. + // the accounting is _very_ unaccurate, i've seen ~50M get flushed + // when the limit was set to 4M. As long as this triggers after + // _some_ jumps we should be ok though. + if (Setup.WriteStrategy!=1 && pendingreadahead>MEGABYTE(2)) { + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + pendingreadahead = 0; + } + } } - else - end = pos; + end = pos; return bytesRead; } return -1; @@ -950,11 +1013,21 @@ ssize_t cUnbufferedFile::Write(const voi end = pos + bytesWritten; if (written > WRITE_BUFFER) { //dsyslog("flush buffer: %d (%d bytes, %ld-%ld)", fd, written, begin, end); - fdatasync(fd); - if (begin >= 0 && end > begin) - posix_fadvise(fd, begin, end - begin, POSIX_FADV_DONTNEED); + totwritten += written; + if (Setup.WriteStrategy!=1 && begin >= 0 && end > begin) { + off_t headdrop = max((long)begin&~4095,(long)WRITE_BUFFER*2); + posix_fadvise(fd, (begin&~4095)-headdrop, end - begin + headdrop, POSIX_FADV_DONTNEED); + } begin = end = -1; written = 0; + // the above fadvise() works when recording, but seems to leave cached + // data around when writing at a high rate (eg cutting). Hence... + if (Setup.WriteStrategy!=1 && totwritten>MEGABYTE(20)) { + if (Setup.WriteStrategy==2) + fdatasync(fd); + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + totwritten = 0; + } } } return bytesWritten; --- vdr-1.3.36.org/tools.h 2005-11-05 11:54:39.000000000 +0100 +++ vdr-1.3.36/tools.h 2005-11-18 03:13:31.000000000 +0100 @@ -209,6 +209,9 @@ private: off_t end; off_t ahead; ssize_t written; + ssize_t totwritten; + size_t readahead; + size_t pendingreadahead; public: cUnbufferedFile(void); ~cUnbufferedFile(); @@ -218,6 +221,7 @@ public: ssize_t Read(void *Data, size_t Size); ssize_t Write(const void *Data, size_t Size); static cUnbufferedFile *Create(const char *FileName, int Flags, mode_t Mode = DEFFILEMODE); + void setreadahead(size_t ra) { readahead = ra; }; }; class cLockFile {

1 0

OT: "Hape trifft - 15.10."
by Seeberg, Ingo 21 Nov '05

21 Nov '05

Hello list, I'd like to know, wether somebody has recorded the interview from Hape Kerkeling with David Copperfield. If somebody has: what was the favorite german word of David Copperfield? It's some kind of quiz and it would be great to know ;-) Sorry for disturbance, Ingo Seeberg

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2005