vdr November 2005

vdr@linuxtv.org

144 participants
178 discussions

Start a nNew thread

OT: Offsett angle
by Lauri Tischler 19 Nov '05

19 Nov '05

Does anybody know the offsetangle for Maximum T-85 dish

1 0

[ANNOUNCE] kvdrmon-0.3
by Bernd Juraschek 19 Nov '05

19 Nov '05

Hi, there is an updated version of kvdrmon. There was a missing icon in the tarball ... This icon is only needed if the next recording starts not in the next 24 hours and we are not in countdown mode. In this case the day will be shown and the dot icon was not present. You can download the new files (tarball and ebuild) at http://sourceforge.net/project/showfiles.php?group_id=88863&package_id=1695… Greetings, Bernd -- Es gibt 10 verschiedene Arten von Menschen: Die einen verstehen das Binärsystem und die anderen verstehen es nicht.

1 0

[ANNOUNCE] kvdrmon - a KDE vdr monitor applet
by Bernd Juraschek 19 Nov '05

19 Nov '05

Hello list, running vdr on a monitorless machine, I ever want to know what my vdr is doing whithout the need to use XXV or df. Now after a little programming I want to announce the first version of the kvdrmon KDE kicker applet. This program monitors some vdr activities. It creates an icon in the KDE system tray showing some informations about the VDR: - The current state (playing, recording, idle) - The time of the next scheduled recording(s) or the time to this recording(s) - A tooltip displays the name(s) of the running recording(s) - A window pops up if a recording has started or finished You can select sound files for playing on started or finished recordings. For further informations, download links and installation hints you can look at http://vdr-statusleds.sourceforge.net/vdr . Have fun, Bernd

3 5

Re: [vdr] a little delete recordings doubt
by Hardy Flor 17 Nov '05

17 Nov '05

Hello leo, > When I delete recordings via osd or vdradmin the time remaining are not > updated. What time have I to wait to see the free time available updated? > Can I force this refresh? You can use the undelete-olugin from http://www.fast-info.de/vdr/undelete/index.htm Hardy

1 0

Will we get a Christmas present (1.4) ?
by Ondrej Wisniewski 17 Nov '05

17 Nov '05

Hello, I know I shouldn't ask but I get the impression that we are close to the next stable VDR version 1.4. New problems still pop up but nothing serious it seems. I might be wrong, though. I already added that to the wishlist I sent to Santa Claus but what are the chances we'll find 1.4 under the Christmas tree ? Malden

3 2

[ANNOUNCE] vdr-autosort-0.0.6
by CopyPoint 17 Nov '05

17 Nov '05

...first steps to usability... http://www.copypointburscheid.de/linux/vdr-autosort-0.0.6.tgz ------------------------------------------------------------------------------------------------------------------------------ 2005-11-14: Version 0.0.6 - Added a Setup Menu (described in README) - Added multi-level OSD-Messages to let you know whats going on - You can reload config and start a complete AutoSort-Run from mainmenu, but VDR is unusable for this time (20min here). !!! USE WITH CARE !! - Housekeeping will be interrupted by any remote key now - Implemented 'SetCaFF' and 'SetCa0'. You need the patch to delete Ca special values (autosort will tell you) ------------------------------------------------------------------------------------------------------------------------------ I hope it's a bit more comfortable now. Thorsten =============================================================== Project's homepage: http://www.copypointburscheid.de/linux/autosort.htm Latest version: http://www.copypointburscheid.de/linux/vdr-autosort-0.0.6.tgz ===============================================================

2 4

receiver and SwitchChannel
by Patrick Fischer 17 Nov '05

17 Nov '05

I have a questions about switching channels. Maybe I have 3 devices (D1(Primary), D2 and D3) And maybe 4 Channels (C1, C2, C3 and C4) the channels contains VPIDs: (just examples) C1 : 0x001, 0x002, 0x003, 0x004 C2 : 0x005, 0x006, 0x007, 0x008 C3 : 0x009, 0x010, 0x011, 0x012 C4 : 0x013, 0x014, 0x015, 0x016 I want the primary device(D1) to handle the wishes of the user. The last device(D3) should to be locked to Channel C3. (always stay there, LOCKED) The D2 can be set to each channel. If I want to receive VPID 0x004 then my Plugin should test if I can receive the VPID over D1 or D3. If not it should tune D2 to the Channel and receive the data. If I want to add an other receiver to receive VPID 0x016, then my Plugin also test D1 and D3. if not it should test if D2 can be tuned to C4. In this case he cant tune because D2 is tuned to C1 and receive data. --- An other view: 1)D1 is tuned to C1(show a program to user) 2)D3 is locked to C4 (and locked) 3)I create a receiver for 0x005, now D2 tune to C2 and the receiver can receive the data 4)I create a receiver for 0x006, the test resulted that the receiver can be added the D2 5)I create a receiver for 0x010, the test resulted that no device can be tuned. An error produced Can anybody explain me how to create this scenario? Greeting Patrick

1 0

Accidental No Signal after channel switch
by Maarten Wisse 17 Nov '05

17 Nov '05

Dear VDR-experts, I've been running my VDR for some time now, with basically only one problem left. The setup is budget card only with a Skystar2 card running on kernel 2.6.13 b2c2-flexcop-pci drivers. This outputs to vdr-1.3.34-vanilla (only dvbplayerpatch from Reinhard Nissl) with vdr-xine-0.7.6 (xxmc enabled output to monitor). The one single problem: at unpredictable moments, VDR-Xine keeps giving the NO SIGNAL message after a channel switch. VDR keeps responding to the remote, reporting channel swithes and menus, but neither video nor audio is displayed anymore (replaying recordings works). A restart of the /etc/init.d/vdr script solves the problem. It seems impossible to predict when it will happens. Fast zapping or slow zapping doesn't seem to trigger the problem. Is this a timeout problem or the like? And if so how to solve it? Is it the driver or vdr? Anyone clues? Best regards, Maarten Wisse

3 9

[PATCH] prevent vdr from using system caches for video data
by Artur Skawina 16 Nov '05

16 Nov '05

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/tools.h 2005-11-05 11:54:39.000000000 +0100 +++ vdr-1.3.36/tools.h 2005-11-16 15:51:27.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(); --- vdr-1.3.36.org/tools.c 2005-11-04 17:33:18.000000000 +0100 +++ vdr-1.3.36/tools.c 2005-11-16 16:06:26.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,13 @@ 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) { + posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL); + } return fd; } @@ -880,10 +885,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 +904,92 @@ 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 = end - pos; // 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(512))) + end = ahead+KILOBYTE(512); + } + // jumped backward? - drop both last read _and_ read-ahead + if (pos < begin) + end = ahead+KILOBYTE(512); + // 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... + + if ( !jumped ) { + if ( readahead <= Size ) // automagically tune readahead size. + readahead = Size*2; + posix_fadvise(fd, pos, readahead, POSIX_FADV_WILLNEED); + ahead = pos + readahead; + } + else { + // flush it all; mostly to get rid of nonflushed readahead + // coming from _previous_ jumps. possibly ratelimit this in + // some way (bytes prefetched? nr of jumps? time?) + + //// first-jump-after-every-60s seemed as good as any :^) + //time_t t = time(NULL); + //if (t >= nextflush) { + // posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + // nextflush = t+60; + // } + + // 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(1)) { + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + pendingreadahead = 0; + } + ahead = pos; + } } - else - end = pos; + end = pos; return bytesRead; } return -1; @@ -950,12 +1012,18 @@ 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); - begin = end = -1; + if (begin >= 0 && end > begin) { + off_t headdrop = max((long)begin,(long)WRITE_BUFFER*2); + posix_fadvise(fd, (begin&~4095)-headdrop, end - begin + headdrop, POSIX_FADV_DONTNEED); + } + begin = end = -1; + totwritten += written; written = 0; } + if (totwritten > MEGABYTE(10)) { + posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + totwritten = 0; + } } return bytesWritten; }

1 0

Re: problems with radio recordings
by Andreas Regel 16 Nov '05

16 Nov '05

Andreas Regel schrieb: > 2. When replaying a radio recording and doing a fast forward, vdr exits > with a segfault. The progress bar always shows a value between 10 and 11 > minutes. Here is the backtrace for this error: > > [..] > > I'm using vanilla vdr 1.3.19 with a single DVB card. > > Andreas This is now fixed in 1.3.24. I guess it is related to the fix in cPesAssembler. Andreas

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2005