vdr May 2007

vdr@linuxtv.org

76 participants
78 discussions

[ANNOUNCE] VDR version 1.4.7 released
by Klaus Schmidinger 12 May '07

12 May '07

VDR version 1.4.7 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.7.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.6-1.4.7.diff A 'diff' against the latest maintenance patch is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.6-1-1.4.7.diff A summary of all the major changes since the last stable version can be found at http://www.cadsoft.de/vdr/download.htm This version is binary compatible with the previous version, so plugins don't need to be recompiled. Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR. Have fun! Klaus

1 0

CAM not work - anyone help??
by Simon Baxter 11 May '07

11 May '07

Hi. I've posted loads of posts on this and the linux-dvb forums, trying to get help with my Irdeto CAM and TechnoTrend 1500-C. I've had almost no responses, and certainly found no help anywhere.

1 0

A few observations on the vdr project
by mikke＠ihku.org 11 May '07

11 May '07

Hello! I would like to share some of thoughts on what I have observed over a short periode of time. I've been following the mailing list, I don't have practically any knowledge in programming so I won't even try to comment on the technical details of the vdr project itself. I would also like to point out that this is not an invitation to a discussion from my part as I wont be able to participate due to time constraint in my private life. I am also a huge fan of the vdr project and I'm in the process of building a htpc running vdr myself :) This is how I feel I am able to contribute to the project without having actual coding knowledge. Hopefully no one is offended by anything I say, as I'm not trying to point out any incompetence in anyone. Enough jibberish, I'll get to the point at hand, now. In my opinion the vdr project is sliding into a bad direction, not code wise. I don't know if an actual roadmap exists somewhere about the planned features for the 1.5-devel series but there should be one. The devel series looks like it's getting flooded with new features, which is great ofcourse and shows that people are contributing to the project. But this is where I see a risk and it looks something like this: The stable version of vdr (1.4.6.something at the time being afaik) get's "older" all the time and only the most vital parts from the devel-branch get backported. Now that is not a problem on it's own, stability is good, but if the 1.5 devel branch gets new features constantly with no feature freeze in site...hopefully people understand where I'm going with this. I'll once again remind everyone reading this that I don't have all the facts concerning this project at hand and there might very well be a roadmap which is strictly followed, and if this is the case all is good and you can ignore this message =) Last but not least, Huge Props to all the people working on this project, contributing in whatever way they can and thanks for creating something I can put on a computer, hand the remote to the mrs and tell her to record whatever she wants and not have to worry about it breaking down. This was my attempt to contribute to this project. -- gnarlie PS. I didn't spellcheck this!

11 27

mplayer with dvd-menu support
by Igor Nikanov 11 May '07

11 May '07

Hello are there any plans to include in the mplayer-plugin a possibility for dvd play with dvd-menu support ? regards Igor

2 2

RE: [vdr] 4:3 stretched to 16:9?
by Martin 10 May '07

10 May '07

Hey Simon,my answer sounds maybe stupid, but I always have all output to 720x576. I use vdr-xine, xine is set to "no scale". So for example: we have shows on RTL or arte in 16:9 amorph which means, that we have 16:9 but with 720x576 pixels. My Sony 16:9 TV takes then the PAL and shows it in "wide".Regards,Martin> Date: Mon, 7 May 2007 23:55:20 +0100> From: linuxtv(a)nzbaxters.com> To: vdr(a)linuxtv.org> Subject: [vdr] 4:3 stretched to 16:9?> > Is there a way in VDR to reformat recordings made in 4:3 to play back in> 16:9 ?> > -Simon> > > _______________________________________________> vdr mailing list> vdr(a)linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _________________________________________________________________ Windows Live Hotmail: Der kostenlose E-Mail-Dienst - schnell, einfach & sicher! http://mail.live.com

3 4

[PATCH] dynamically sized ringbuffers v1
by Artur Skawina 09 May '07

09 May '07

vdr uses quite a lot of memory, RSS here used to be ~70M, so i decided to see if it could be reduced a bit. First suspects became the ringbuffers, cause i was seeing a lot of log lines such as "buffer stats: 96068 (1%) used". Turns out many buffers are way over sized, only a few percent of the memory are typically used, yet because of how a ringbuffer works _all_ of it is constantly accessed. I first tried to make the ringbuffer users smarter about picking the size and eg after changing the transfer buffer to start out small and use bigger sizes only when the current one isn't large enough it seemed a more reasonable size for that vdr instance was 384k instead of 2M. Similarly the TS buffer could be just a few hundred K instead of 2M. But that approach was not ideal as there isn't anything one could do after realizing the buffer is too small, it could be grown next time, after channel switch etc, but that's it. Also some of the huge buffers came from plugins, and I wasn't all that excited about fixing all of them (one example w/ the one-digit % fill was streamdev-server). It is hard to estimate what the proper size would be under load, with many simultaneous recordings. So I did attack this issue differently -- by making the ringbuffers themselves smarter. Patch below changes the interpretation of the 'Size' parm given when creating a buffer from a fixed length to a max limit. The buffers start out much smaller (currently 128k, instead of many megabytes) and grow automatically when they become almost full. This way all callers benefit, and they don't have to be modified at all. The buffers are actually always allocated using the max size, but only the necessary buffer part is used, the rest of the memory is never accessed; this is done this way so that no extra locking is necessary. I've tested this on two vdrs for a few hours and it seems to work, but it needs a lot more testing. There is some extra logging in this patch so that you can see what's going on; every time a ring buffer gets deleted it logs a line which tells you exactly how much memory was requested and how much was really needed. vdr: [19729] Deleting ring buffer "TS" size: 196608 / 2097152 (used 9.375% of requested size) vdr: [19718] Deleting ring buffer "Result" size: 262144 / 262144 (used 100% of requested size) vdr: [19718] Deleting ring buffer "Recorder" size: 442368 / 5242880 (used 8.4375% of requested size) vdr: [19718] Deleting ring buffer "Result" size: 262144 / 262144 (used 100% of requested size) vdr: [19718] Deleting ring buffer "Recorder" size: 131072 / 5242880 (used 2.5% of requested size) vdr: [19733] Deleting ring buffer "TS" size: 131072 / 2097152 (used 6.25% of requested size) vdr: [19718] Deleting ring buffer "Result" size: 262144 / 262144 (used 100% of requested size) vdr: [19718] Deleting ring buffer "Recorder" size: 442368 / 5242880 (used 8.4375% of requested size) So each of the several 'Recorder' buffers was an order of magnitude smaller than w/o this patch and several megabytes less ram was used. artur diff --git a/ringbuffer.c b/ringbuffer.c index 0633bd3..8dd1efe 100644 --- a/ringbuffer.c +++ b/ringbuffer.c @@ -151,13 +151,29 @@ void cRingBufferLinear::PrintDebugRBL(void) } #endif +// cRingBufferLinear are dynamically sized, or at least we can pretend they are ;) +// We treat 'Size' as the maximum size, but start with a small buffer, which can +// grow later as it fills up. Memory is always allocated for the full buffer, but +// the unused RAM portion remains untouched until (if at all) it is actually needed. +// Note that we can not start with a larger than requested buffer because there are +// ring buffer users that cause crashes then (eg softdevice mpegdecoder absolutely +// needs 32/64k). + +// Startup size. 64k still causes overflows before buffer starts to grow, 128k doesn't. +// The buffers grow to 200..500k anyway, so maybe increasing this a bit more would +// make sense, but let's first see if it's really needed. +#define DEFRBSIZE KILOBYTE(128) + cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description) -:cRingBuffer(Size, Statistics) +:cRingBuffer(min(Size,DEFRBSIZE), Statistics) { description = Description ? strdup(Description) : NULL; tail = head = margin = Margin; gotten = 0; buffer = NULL; + maxsize = Size; + growbuf = 0; + dsyslog("New ring buffer \"%s\" size: %d margin: %d", description, Size, Margin ); if (Size > 1) { // 'Size - 1' must not be 0! if (Margin <= Size / 2) { buffer = MALLOC(uchar, Size); @@ -183,6 +199,8 @@ cRingBufferLinear::~cRingBufferLinear() #ifdef DEBUGRINGBUFFERS DelDebugRBL(this); #endif + dsyslog("Deleting ring buffer \"%s\" size: %d / %d (used %g%% of requested size)", description, + size, maxsize, size/(double)maxsize*100.0 ); free(buffer); free(description); } @@ -207,6 +225,13 @@ void cRingBufferLinear::Clear(void) int cRingBufferLinear::Read(int FileHandle, int Max) { + if (Available() >= size*2/4) + growbuf = 1; + if (growbuf && head>=tail && size<maxsize) { + size = min(size+size/2, maxsize); + dsyslog("Enlarging ring buffer \"%s\": %d bytes (Read())", description, size); + growbuf = 0; + } int Tail = tail; int diff = Tail - head; int free = (diff > 0) ? diff - 1 : Size() - head; @@ -236,6 +261,8 @@ int cRingBufferLinear::Read(int FileHandle, int Max) lastHead = head; lastPut = Count; #endif + if (Available() >= size*3/4) + growbuf = 1; EnableGet(); if (free == 0) WaitForPut(); @@ -245,6 +272,13 @@ int cRingBufferLinear::Read(int FileHandle, int Max) int cRingBufferLinear::Put(const uchar *Data, int Count) { if (Count > 0) { + if (Available()+Count >= size*2/4) + growbuf = 1; + if (growbuf && head>=tail && size<maxsize) { + size = min(size+size/2, maxsize); + dsyslog("Enlarging ring buffer \"%s\": %d bytes", description, size); + growbuf = 0; + } int Tail = tail; int rest = Size() - head; int diff = Tail - head; diff --git a/ringbuffer.h b/ringbuffer.h index dba0e61..f417d57 100644 --- a/ringbuffer.h +++ b/ringbuffer.h @@ -18,11 +18,11 @@ private: cCondWait readyForPut, readyForGet; int putTimeout; int getTimeout; - int size; time_t lastOverflowReport; int overflowCount; int overflowBytes; protected: + int size; tThreadId getThreadTid; int maxFill;//XXX int lastPercent; @@ -59,6 +59,8 @@ private: int margin, head, tail; int gotten; uchar *buffer; + int growbuf; + int maxsize; char *description; public: cRingBufferLinear(int Size, int Margin = 0, bool Statistics = false, const char *Description = NULL);

2 4

OT: noad
by Wolfgang Goeller 09 May '07

09 May '07

Hello I just found out: I can't find noad. The old homepage is no longer valid. Does anyone know more Thanks Wolfgang

2 1

4:3 stretched to 16:9?
by Simon Baxter 09 May '07

09 May '07

Is there a way in VDR to reformat recordings made in 4:3 to play back in 16:9 ? -Simon

2 1

CAM/CI Problems
by Simon Baxter 07 May '07

07 May '07

I've been posting a lot of messages lately about problems I'm having getting my TechnoTrend Budget 1500/CI (dvb-c) and Irdeto CAM working, on both this and the linux-dvb lists. As I've not had very many responses, I can only assume there's few people using this combination, and I probably need to look at addressing the problem myself. To summarise my problem: The DVB card registers properly, and I can scan channels etc fine. All the channels available to me are scrambled. The CAM seems to register properly also, but I can't access the CAM menu or decrypt anything. -VDR flip-flops the CAM between ready/present -kernel messages "dvb_ca adapter 0: DVB CAM detected and initialised successfully" repeat over and over -'gnutv -cammenu' reports "en50221_tl_poll: CAWrite failed" and "en50221_stdcam_llci_poll: Error reported by stack:-2" -the card and CAM work fine in a Dreambox and under (Windows) GBPVR My question is, can anyone suggest any other tools which test CAMs? Also, I don't really understand how the CAM is accessed - can anyone point me in the right direction? Thanks! Simon

1 0

Galaxis LinuxTV terminal : IDE connection
by Trick 07 May '07

07 May '07

Hello, Sorry for repeating this message in this mailing list. I realized it was better here than DVB mailing list. I'm using a DVB-C LinuxTv terminal called Galaxis. I bought it on Ebay and apparently it is made for the Austrian market. Everything works great on the French Cable! >From what I understood this terminal has a IDE connection for a hard drive. I opened the terminal and indeed I found the IDE plug. Though I didn't find the electrical plug for the hard drive. Does anybody own this terminal and tried to connect a hard drive? What would be the next step? Hard drive recognition by the BIOS? Software to install to be able to record TV shows? Thank you in advance. Patrick

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr May 2007