vdr January 2006

vdr@linuxtv.org

153 participants
203 discussions

Confirm messages
by Peter Juszack 05 Feb '06

05 Feb '06

Hi list, some time ago my girlfriend wanted to record a program via EPG. She has never done that before but managed it easily to program the timer out of the EPG-view. But when she saw the timer-data she did not press OK button to save the timer because there was no hint to do so. She pressed back the menu closed and the timer was lost :( - The question: Bad luck or bad user interface? On many Set Top Boxes I recognized that lots of hints and status messages are displayed. This makes it possible that also unexperienced users can use the device. As long as only 'root' has the remot control in his hands there is no need for messages - but other users seem to have some problems. Since 1.3.40 a message 'Recording started' is displayed when the Record button was pressed. This is the right way. End-user devices give feedback to almost everything My proposal for the timer issue (and maybe in general): - color key to explicitly save and exit the timer editing menu - warning when exiting the timer menu without having saved ( e.g. 'timer not saved. Really exit?' ) that would be common behaviour of almost all end-user applications. I would also wish a confirm message when stopping playback (also plugins mp3 etc.). I often stopped playback accidently when browsing menus during playback. Especially by pressing blue button. I know that the 'Don't ask and do what I say' lobby won't like it but maybe a setup option verbose could be added to control the level of verbosity. What do you think about that? Regards Peter

8 19

[PATCH] UnbufferedFile improvements v7
by Artur Skawina 05 Feb '06

05 Feb '06

this time with a new approach to read caching. Should make watching and editing recordings on a non-idle (and/or slow) machine more comfortable. The difference to previous versions (and stock fadvise-enabled vdr) is that previously, read data was almost immediately forgotten after it was used; now a certain amount of recently accessed data (at most ~16M) is kept around. This means that short seeks (jumps) when replaying do not cause disk accesses. Things like switching play mode, FF, setting and moving editing marks shouldn't usually block waiting for disk IO. The changes are most noticeable when eg. several recordings are happening in the background. I did very little testing, treat this as beta quality at best. Seems to work ok, but i won't probably have time to test it further for a few days; maybe somebody wants to play w/ this, or even better take a look at the Read() path... artur --- vdr-1.3.39.org/cutter.c 2005-10-31 12:26:44.000000000 +0000 +++ vdr-1.3.39/cutter.c 2006-01-28 21:33:39.000000000 +0000 @@ -66,6 +66,8 @@ void cCuttingThread::Action(void) toFile = toFileName->Open(); if (!fromFile || !toFile) return; + fromFile->SetReadAhead(MEGABYTE(20)); + toFile->SetReadAhead(MEGABYTE(20)); int Index = Mark->position; Mark = fromMarks.Next(Mark); int FileSize = 0; @@ -90,6 +92,7 @@ void cCuttingThread::Action(void) if (fromIndex->Get(Index++, &FileNumber, &FileOffset, &PictureType, &Length)) { if (FileNumber != CurrentFileNumber) { fromFile = fromFileName->SetOffset(FileNumber, FileOffset); + fromFile->SetReadAhead(MEGABYTE(20)); CurrentFileNumber = FileNumber; } if (fromFile) { @@ -118,10 +121,11 @@ void cCuttingThread::Action(void) break; if (FileSize > MEGABYTE(Setup.MaxVideoFileSize)) { toFile = toFileName->NextFile(); - if (toFile < 0) { + if (!toFile) { error = "toFile 1"; break; } + toFile->SetReadAhead(MEGABYTE(20)); FileSize = 0; } LastIFrame = 0; @@ -158,10 +162,11 @@ void cCuttingThread::Action(void) cutIn = true; if (Setup.SplitEditedFiles) { toFile = toFileName->NextFile(); - if (toFile < 0) { + if (!toFile) { error = "toFile 2"; break; } + toFile->SetReadAhead(MEGABYTE(20)); FileSize = 0; } } --- vdr-1.3.39.org/tools.c 2006-01-15 14:31:45.000000000 +0000 +++ vdr-1.3.39/tools.c 2006-01-29 15:27:10.000000000 +0000 @@ -1040,10 +1040,9 @@ bool cSafeFile::Close(void) // --- cUnbufferedFile ------------------------------------------------------- -//#define USE_FADVISE +#define USE_FADVISE -#define READ_AHEAD MEGABYTE(2) -#define WRITE_BUFFER MEGABYTE(10) +#define WRITE_BUFFER KILOBYTE(800) cUnbufferedFile::cUnbufferedFile(void) { @@ -1059,8 +1058,20 @@ int cUnbufferedFile::Open(const char *Fi { Close(); fd = open(FileName, Flags, Mode); - begin = end = ahead = -1; + curpos = 0; +#ifdef USE_FADVISE + begin = lastpos = ahead = 0; + cachedstart = 0; + cachedend = 0; + readahead = 128*1024; written = 0; + totwritten = 0; + if (fd >= 0) { + // we could use POSIX_FADV_SEQUENTIAL, but we do our own readahead + // disabling the kernel one. + posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM); + } +#endif return fd; } @@ -1068,16 +1079,9 @@ int cUnbufferedFile::Close(void) { #ifdef USE_FADVISE if (fd >= 0) { - if (ahead > end) - end = ahead; - if (begin >= 0 && end > begin) { - //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); - } - begin = end = ahead = -1; - written = 0; + if (totwritten) // if we wrote anything make sure the data has hit the disk before + fdatasync(fd); // calling fadvise, as this is our last chance to un-cache it. + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); } #endif int OldFd = fd; @@ -1085,45 +1089,81 @@ int cUnbufferedFile::Close(void) return close(OldFd); } -off_t cUnbufferedFile::Seek(off_t Offset, int Whence) -{ - if (fd >= 0) - return lseek(fd, Offset, Whence); - return -1; +// When replaying and going eg FF->PLAY the position jumps back 2..8M +// hence we do not want to drop recently accessed data at once. +// We try to handle the common cases such as PLAY->FF->PLAY, small +// jumps, moving editing marks etc. + +#define FADVGRAN 4096 // AKA fadvise-chunk-size; PAGE_SIZE or + // getpagesize(2) would also work. +#define READCHUNK MEGABYTE(8) + +static inline int fadvise_drop(int fd, off_t offset, off_t len) +{ + // rounding up the window to make sure that + // not PAGE_SIZE-aligned data gets freed. + return posix_fadvise(fd, offset-(FADVGRAN-1), len+(FADVGRAN-1)*2, POSIX_FADV_DONTNEED); } - + ssize_t cUnbufferedFile::Read(void *Data, size_t Size) { if (fd >= 0) { #ifdef USE_FADVISE - 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 = curpos-lastpos; // nonzero means we're not at the last offset + //dsyslog("READ: %d %08ld, jump: %06ld ra: %06ld size: %ld", fd, curpos, jumped, (long)readahead, (long)Size); + + if ( (cachedstart<cachedend) && ((curpos<cachedstart) || (curpos>cachedend)) ) { + //dsyslog("CACHE JUMPED: %d, %08ld %08ld..%08ld", fd, curpos, cachedstart, cachedend); + fadvise_drop(fd, cachedstart, cachedend-cachedstart); + cachedstart = curpos; + cachedend = curpos; + } + + cachedstart = min(cachedstart, curpos); #endif ssize_t bytesRead = safe_read(fd, Data, Size); #ifdef USE_FADVISE 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; + curpos += bytesRead; + cachedend = max(cachedend, curpos); + + // Read ahead: + // no jump? (allow small forward jump still inside readahead window). + if (jumped>=0 && jumped<=(off_t)readahead) { + // Trigger the readahead IO, but only if we've used at least + // 1/2 of the previously requested area. This avoids calling + // fadvise() after every read() call. + if ((ahead-curpos)<(off_t)(readahead-readahead/2)) { + //dsyslog("WILLNEED: %d, %08ld ra: %06ld", fd, curpos, (long)readahead); + posix_fadvise(fd, curpos, readahead, POSIX_FADV_WILLNEED); + ahead = curpos+readahead; + cachedend = max(cachedend, ahead); + } + if (readahead < Size*32) { // automagically tune readahead size. + readahead = Size*32; + //dsyslog("Readahead for fd: %d increased to %ld", fd, (long)readahead); + } + } + else { + // jumped -> we really don't want any readahead. otherwise eg fast-rewind gets + // in trouble. + ahead = curpos; + } } - else - end = pos; + + if (cachedstart<cachedend) { + if ((curpos-cachedstart)>READCHUNK*2) { + //dsyslog("CACHE TSHRINK: %d, %08ld %08ld..%08ld", fd, curpos, cachedstart, cachedend); + fadvise_drop(fd, cachedstart, (curpos-READCHUNK)-cachedstart); + cachedstart = curpos-READCHUNK; + } + else if ((cachedend>ahead)&&(cachedend-curpos)>READCHUNK*2) { + //dsyslog("CACHE HSHRINK: %d, %08ld %08ld..%08ld", fd, curpos, cachedstart, cachedend); + fadvise_drop(fd, curpos+READCHUNK, cachedend-(curpos+READCHUNK)); + cachedend = curpos+READCHUNK; + } + } + lastpos = curpos; #endif return bytesRead; } @@ -1132,29 +1172,37 @@ ssize_t cUnbufferedFile::Read(void *Data ssize_t cUnbufferedFile::Write(const void *Data, size_t Size) { + //dsyslog("Unbuffered:Write: fd: %d %8ld..%8ld size: %5ld", fd, curpos, curpos+Size, (long)Size); if (fd >=0) { -#ifdef USE_FADVISE - off_t pos = lseek(fd, 0, SEEK_CUR); -#endif ssize_t bytesWritten = safe_write(fd, Data, Size); #ifdef USE_FADVISE - if (bytesWritten >= 0) { + if (bytesWritten > 0) { + begin = min(begin, curpos); + curpos += bytesWritten; written += bytesWritten; - if (begin >= 0) { - if (pos < begin) - begin = pos; - } - else - begin = pos; - if (pos + bytesWritten > end) - end = pos + bytesWritten; + lastpos = max(lastpos, curpos); 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); - begin = end = -1; + //dsyslog("flush buffer: %d (%d bytes, %ld-%ld)", fd, written, begin, lastpos); + if (lastpos>begin) { + off_t headdrop = min(begin, WRITE_BUFFER*2L); + posix_fadvise(fd, begin-headdrop, lastpos-begin+headdrop, POSIX_FADV_DONTNEED); + } + begin = lastpos = max(0L, curpos-4095); + totwritten += written; written = 0; + // The above fadvise() works when writing slowly (recording), but could + // leave cached data around when writing at a high rate (cutting). + // Also, it seems in some setups, the above does not trigger any I/O and + // the fdatasync() call below has to do all the work (reiserfs with some + // kind of write gathering enabled). + // We add 'readahead' to the threshold in an attempt to increase cutting + // speed; it's a tradeoff -- speed vs RAM-used. + if (totwritten>(MEGABYTE(32)+readahead)) { + //fdatasync(fd); + off_t headdrop = min(curpos-totwritten, totwritten*2L); + posix_fadvise(fd, curpos-totwritten-headdrop, totwritten+headdrop, POSIX_FADV_DONTNEED); + totwritten = 0; + } } } #endif --- vdr-1.3.39.org/tools.h 2006-01-08 11:40:37.000000000 +0000 +++ vdr-1.3.39/tools.h 2006-01-29 13:29:51.000000000 +0000 @@ -237,22 +237,41 @@ public: /// cUnbufferedFile is used for large files that are mainly written or read /// in a streaming manner, and thus should not be cached. +#include <sys/types.h> +#include <sys/mman.h> +#include <unistd.h> + class cUnbufferedFile { private: int fd; + off_t curpos; + off_t cachedstart; + off_t cachedend; off_t begin; - off_t end; + off_t lastpos; off_t ahead; - ssize_t written; + size_t readahead; + size_t written; + size_t totwritten; public: cUnbufferedFile(void); ~cUnbufferedFile(); int Open(const char *FileName, int Flags, mode_t Mode = DEFFILEMODE); int Close(void); - off_t Seek(off_t Offset, int Whence); + off_t Seek(off_t Offset, int Whence) + { + //dsyslog("Seek: fd: %d offs: %ld whence: %d diff: %ld", fd, (long)Offset, Whence, Offset-curpos); + if (Whence == SEEK_SET && Offset == curpos) + return curpos; + + curpos = lseek(fd, Offset, Whence); + return curpos; + } + 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 {

3 7

[1.3.40] String edit insert mode broken
by Udo Richter 04 Feb '06

04 Feb '06

Hi list, In 1.3.40 and 1.3.41, the arrow key insert mode of edit fields is broken. It inserts a new char after each up/down press. Steps: - Go to some edit field (timer name etc) and start editing - Press 'green' for insert mode - Press 'up' several times Result: aaaaa inserted The attached patch fixes this for now, though its a bit ugly. Simply setting newchar = false like in 1.3.39 now activates the auto-advance timer without setting it, so it advances soon. (I guess this is not expected, though I could get used to it.) The patch sets the timer to some unrealistic high value to avoid advancing for a looong time. Cheers, Udo --- vdr-1.3.40/menuitems.c 2006-01-21 13:27:14.000000000 +0100 +++ vdr-1.3.41/menuitems.c 2006-01-30 01:15:47.000000000 +0100 @@ -427,7 +427,8 @@ value[pos] = toupper(Inc(tolower(value[pos]), NORMALKEY(Key) == kUp)); else value[pos] = Inc( value[pos], NORMALKEY(Key) == kUp); - newchar = true; + newchar = false; + autoAdvanceTimeout.Set(AUTO_ADVANCE_TIMEOUT*100); } else return cMenuEditItem::ProcessKey(Key);

2 2

Bug at fast forward and JumpTo
by Patrick Fischer 04 Feb '06

04 Feb '06

I found a maybe very old bug. If I'm using Multispeed for watching an recording: -I can use left/rigth for fast forward/backword. -I can use the red button to enter a jumpTo position activated by pressing "up" But if Im using fastforward and then enter a jumpTo position the the fastforward speed will be changed to max speed. So if I'm using speed "1" and jumpto Posion 1000 then the player switch to max speed (3) And Control->GetReplayMode(Play, Forward, Speed) will return the wrong values. I have tested it with vdr 1.3.38 Greetings Patrick

3 2

Re: [vdr] REQUEST UI change when OK pressed
by Mike Parker 04 Feb '06

04 Feb '06

> Date: Tue, 31 Jan 2006 22:21:13 +0100 > From: Klaus Schmidinger <Klaus.Schmidinger(a)cadsoft.de> > Subject: Re: [vdr] REQUEST UI change when OK pressed > To: vdr(a)linuxtv.org > Message-ID: <43DFD4C9.3070402(a)cadsoft.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Gunnar Roth wrote: > > Klaus Schmidinger wrote: > > > >> Peter Juszack wrote: > >> > >>> Mike Parker wrote: > >>> > >>>> Just a suggestion / discussion point. > >>>> > >>>> Would it be possible to modify the OK key so that on first press it > >>>> does the > >>>> same as now, but pressing it again brings up the current program > >>>> detailed > >>>> information > >>>> > >>> I would also like a "shortcut" to view the program information. Is > >>> there a way to > >>> do it via keymacros.conf ? > >> > >> > >> Just user the "Info" key in recent developer versions ("Yellow" by > >> default). > >> > > What to use when watching a recording to get the info text? While > > replaying yellow skips a minute forward. > > Maybe when pressing ok , the color buttons could get another meanings, > > shown by rectangles on the screen bottom as usual. > > regards, > > gunnar > > The color buttons are just used via keymacros.conf for > shortcuts when viewing live tv. Of course in replay they > already have a meaning. > > If you want a dedicated Info key, just define one on > your RC. > > Klaus I was unaware of the new Info key (was using vdr-1.3.37) and certainly it does do as described - thank you. You must have had requests for this (or felt it was necessary) and as Gunnar suggests it would also be beneficial in record playback. While this is a key option, it does mean one less key for us to use for macros. If a double press of ok is used in viewing and record, I beleive we improve the UI and reduce 'clutter' on the screen. Do you have any feelings about my other suggestion about showing what is being recorded (either channel or program) when the OK key is pressed?

3 2

kvdr 0.64 released
by Guido Fiala 02 Feb '06

02 Feb '06

new version can be downloaded under http://www.s.netic.de/gfiala/kvdr-0.64.tgz -new feature "Tiny-Sticky-Mode" - it shows a tiny window at all (virtual) desktops always on top and the previous-sized window at its home desktop, to be activated with key "T" -kvdr is now a "KUniqueApplication", meaning it will and can only be started once -some bugfixes with overlay handling as well as positioning and geometry in fullscreen and Xv-Mode

3 6

VDR-1.3.41: speedup for cVideoRepacker
by Reinhard Nissl 01 Feb '06

01 Feb '06

Hi, as you may have noticed: ZDF increased it's bitrate to about 7.5 Mbit/s. As a result, less powerful VDR systems "suffered" when taking a recording or when running in transfer mode. The attached patch speeds up cVideoRepacker by choosing a known art search algorithm for finding start codes in the video stream. With this patch and a similar one for xine-lib I was finally able to watch and record ZDF at the same time on my 600 MHz "budget only" EPIA VDR system. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

3 6

softdevice A/V sync
by Tony Houghton 01 Feb '06

01 Feb '06

Having got softdevice working recently (with Matrox G450 TV out), I've used it to watch a couple of films I've recorded. On one of them it seemed fine, but on the other there was a noticeable delay between audio and video. Every so often the picture would go sort of jerky for a few seconds as if it were dropping frames to try to get back in sync, but failing. The amount of delay seemed fairly consistent. I had a similar problem with MPlayer (except the periods of jerking) until someone told me to try -ao oss because it's buggy with alsa. Is softdevice's audio code based on MPlayer's, perhaps? libsoftmpeg's IDEAS file <http://linuxtv.org/cgi-bin/viewcvs.cgi/libsoftmpeg/IDEAS?view=markup> mentions adjusting the speed of sound playback (presumably by resampling) to avoid buffer xruns if the sound card's clock doesn't quite match the broadcast stream's. I think this resampling idea could be used to approach A/V sync from a different angle. The curent problem is that existing players are designed to play the sound at a certain rate and then sync the picture to it. That means if video playback is also synced to vblank, and you can't control the video card's clock, you have to drop or repeat frames to adjust the picture timing. If you don't bother syncing video frame changeovers to the hardware vblank it tends to cause "tearing" artifacts for progressive scan video, and is pretty disastrous for interlaced video. So seeing as there's a need to keep the video in sync with the hardware, why not base the playback timing on the video and adjust the sound to match it instead of the other way round? There are plenty of resampling libraries already available. You may still need to drop/repeat frames to keep up with a broadcast stream, but this approach could offer an improvement and avoid sound glitches from xruns if the video card's clock is a closer match to the source than the sound card's - in my PC I'd trust the Matrox more than its £5 sound card, but users with good sound cards just may be better off with the current method. For playback of recordings though I think my idea should give smoother results. -- TH * http://www.realh.co.uk

2 6

[1.3.40] Fast channel switching resets
by Udo Richter 01 Feb '06

01 Feb '06

> - Switching channels with the Up/Down or Channel+/Channel- keys now works a lot > faster when the repeat function kicks in, by not actually switching the > channel every time, but rather only displaying the channel info and doing > the final switch when the key is released. Nice idea, but not working for me. If I hold down ChUp on my remote, VDR just goes one channel up. Then, the repeat kicks in and the channel number counts up rapidly, but resets to the current channel after 10-40 channels (1-2 seconds), then starts counting up again. No channel switches after the first one in log files. After releasing ChUp, the final channel switch happens, to the channel that was shown at that time. With keyboard, the ChUp is waaay slower, but works. From the logs, each channel is switched separately, just as without repeat. Remote support is based on remote-0.3.3, keyboard support is VDR-builtin. No other plugins loaded. Cheers, Udo

8 28

LOF/SLOF for none Europe LNBs
by Markus Hahn 01 Feb '06

01 Feb '06

Hi There, to ease settings of DiSEqc/LNBs, I need LOF/SLOF values. E.G MWI circular Universal LNB AP82-T4C for Russia. How does diseqc.conf file looks with mixes Universal LNBs and single range LNBs, like C-Band LNBs. Specaly information (disecq.conf with LNB-Type) from Asia, Africa or South America are nice. thanx for help regards markus

4 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr January 2006