vdr

vdr@linuxtv.org

6731 discussions

[PATCH] jumpplay patch 1.0 for VDR-1.6.0 and VDR-1.7.4
by Thomas Günther 31 Mar '09

31 Mar '09

Hi! Here is a new version of the jumpplay patch: http://toms-cafe.de/vdr/download/vdr-jumpplay-1.0-1.6.0.diff http://toms-cafe.de/vdr/download/vdr-jumpplay-1.0-1.7.4.diff This patch changes the replay behaviour for recordings that contain editing marks. It allows to immediately continue the replay after jumping forward to the next mark, and to automatically jump over the commercial break to the next "start" mark, if an "end" mark is reached. The features of this patch can be turned on or off in the replay setup. See README.jumpplay included in the patch for details, history and contributors. Changes since version 0.9: - Play&Jump: - set resume position to 0 if replay stops at the first mark - Added French language texts (thanks to Michaël Nival) Tom

1 0

Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
by Heinrich Langos 30 Mar '09

30 Mar '09

On Wed, Mar 18, 2009 at 02:40:38PM +0200, Antti Palosaari wrote: > Heinrich Langos wrote: >> I ran "dvbtraffic" (itself causing about 10 wakups but hardly any cpu load) >> on another console to see what is happening and it seems like "femon" >> does only check the receiver's status while "zap" realy causes data to >> be transfered from the USB device to the host. > > yes. femon only reads demodulator status and zap starts transfer. > >> So the rather heavy load that I see with vdr is probably not caused by vdr >> itself but by the USB data transfer. >> >> The new questions are: >> >> Does every USB DVB-T receiver cause the same amount of cpu load? > > Not sure. This device uses USB bulk transfer with packet size 512. This > is most typical packet size and protocol, very many devices are using > just same. Some devices are using different packet size. > There is also isochronous transfer used instead bulk, but it is not very > very common. I have no idea how much load it generates. > > I doubt all USB-transfers will generate almost same load when > transferring same amount of data. In my understanding USB does not use > DMA and that's why it generates high load? DMA is only possible between memory and the USb host controller. The USB device is always polled for data. Even the so called interupt transfer mode is nothing but a high frequency polling mode... well USB sucks compared to firewise but than again, usb devices are cheap as chips because they can be stupid. I ran a couple of tests with a different DVB-T USB stick. The rather old "Fujitsu-Siemens DVB-T Mobile TV". That one turns out to need a lot less system resources. It also transfers the whole transport stream (several video and audio streams) over the USB and leaves demuxing to the host. So we are not comparing apples and oranges. Comparing those numbers seems to indicate that there is room for improvment for the af9015 driver. I'll try to get my hands on a couple more different usb receivers to try out some of the other drivers. What I also found rather scary was the 200 wakups per second that vdr did even when there is no dvb device to read from. So I removed all vdr plugins and started adding them one by one. epgsearch - no problem live - no problem streamdev-server - no problem ffnetdev - BINGO Which makes sense when considering that ffnetdev tries to implement a full featured card in software. I just didn't know they also try to implement an INPUT device! With the usb device enabled, I get various degrees of CPU load, depending on the plugins installed, but in general the number of wakeups per second is constant at about 200 per second. Even without any plugin and with noting to do. In other words: vdr is polling its input devices at 200 Hertz even when is is completely idle! I wonder if that is realy necessary... Some vdr guru willing to enlighten me? (I'm willing to dodge the stones thrown at the heretic :-) ) cheers -henrik PS: I am willing to take the whole driver thread off-list if somebody feels that this is not the proper list for it, but I think the way vdr behaves when it is idle is interesting to more people.

3 22

[FRC] Why are patches for framebuffer not needed anymore in release 0.1.0?
by Paul Menzel 29 Mar '09

29 Mar '09

Dear Thomas, you released version 0.1.0 [1]. Could you please explain to me, why the framebuffer patches (intelfb, radeonfb) are not needed anymore? Thanks a lot, Paul [1] http://lowbyte.de/vga-sync-fields/vga-sync-fields/

3 3

xinelibout --hud + xcompmgr = tearing
by Alex Betis 29 Mar '09

29 Mar '09

Hello all, I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? Without xcompmgr running there is no tearing at all. Thanks.

4 7

[ADMIN] linuxtv.org is moving
by Johannes Stezenbach 28 Mar '09

28 Mar '09

Hi, linuxtv.org will move to a new server machine tomorrow. Expect some downtime during the move and please be patient. Everything on the old machine will be rsynced to the new machine right before the switch so nothing should get lost. Cheers, Johannes

3 5

Where do you live and what kind of broadcast do you receive?
by Petri Helin 28 Mar '09

28 Mar '09

Hi, I have wondered for some time how broad has VDR spread and how is it really used. So, if people could post their location and the type of broadcast they are receiving, we could get some kind of understanding about the state of DVB (or ATSC) as it is now. Just a brief description, using myself as an example: Country: Finland Transmission: DVB-C Encoding: MPEG-2 for SD (tens of channels) and h.264 for HD (less than 10 channels) The main point is to get an idea of the standards used across the globe. I know that wiki etc give some idea, but you can never beat the first hand information. -Petri

30 29

Fix for recordings greater than 2 GB
by Jose Alberto Reguero 28 Mar '09

28 Mar '09

The attached patch fix some problems when playing recordings greater than 2 GB. Jose Alberto

1 0

noad for VDR 1.7.x
by Peter 26 Mar '09

26 Mar '09

Has there been any work to patch noad for new recording format in VDR 1.7.4? Peter

3 3

VDR 1.7.0 & S2API - Channels not Available
by LinuX Oholic 25 Mar '09

25 Mar '09

Hello vdr list I recently bought two Twinhan DVB-T receiver sticks: TwinhanDTV USB-Ter USB1.1 / Magic Box I & Magic Box II They both seem to work well in linux, but for some reason I can only get a picture in stable c't vdr (1.6.0-2) and not in my self compiled vdr 1.7.0. I use s2-liplianin drivers with another Twinhan DVB-S2 card (1041), this one works fine on both vdr versions. Patchlevel on vdr 1.7.0 is: + h264-syncearly-framespersec-audioindexer-fielddetection-speedup +vdr-1.7.0-s2api-07102008-h264-clean.patch >From what I see in the 1.7.0 syslog I can make out a possible reason why it doesn't work in there: vdr: [6675] [general.debug] capturing device 0 vdr: [6678] video directory scanner thread ended (pid=6675, tid=6678) vdr: [6677] video directory scanner thread ended (pid=6675, tid=6677) vdr: [6675] device 1 provides: DVBS DSS vdr: [6680] tuner on device 1 thread started (pid=6675, tid=6680) vdr: [6681] section handler thread started (pid=6675, tid=6681) vdr: [6675] [general.info] captured 1 video device This DVB-T stick is clearly *NOT* DVB-S capable - so this might be part of the problem. I don't get this message in 1.6.0 at all. Is this related to the problem Morfsta had in [1] ? - it is the same QAM 16 modulation I am trying to connect to - but mine is (QAM 16, 8K, 5/6, 1/4). Thanks in advance for any help. I'd like to stay with vdr 1.7.0 as well for plugin compatibility reasons. [1] http://www.linuxtv.org/pipermail/vdr/2009-February/019493.html _________________________________________________________________ http://redirect.gimas.net/?n=M0903xIMTicTacToe Kostenlose Spannung? Spiel jetzt mit Freunden TIC TAC TOE in 3D!

2 1

VDR 1.7.0 & S2API - Channels not Available
by LinuX Oholic 25 Mar '09

25 Mar '09

Hello vdr list I recently bought two Twinhan DVB-T receiver sticks: TwinhanDTV USB-Ter USB1.1 / Magic Box I & Magic Box II They both seem to work well in linux, but for some reason I can only get a picture in stable c't vdr (1.6.0-2) and not in my self compiled vdr 1.7.0. I use s2-liplianin drivers with another Twinhan DVB-S2 card (1041), this one works fine on both vdr versions. Patchlevel on vdr 1.7.0 is: + h264-syncearly-framespersec-audioindexer-fielddetection-speedup +vdr-1.7.0-s2api-07102008-h264-clean.patch >From what I see in the 1.7.0 syslog I can make out a possible reason why it doesn't work in there: vdr: [6675] [general.debug] capturing device 0 vdr: [6678] video directory scanner thread ended (pid=6675, tid=6678) vdr: [6677] video directory scanner thread ended (pid=6675, tid=6677) vdr: [6675] device 1 provides: DVBS DSS vdr: [6680] tuner on device 1 thread started (pid=6675, tid=6680) vdr: [6681] section handler thread started (pid=6675, tid=6681) vdr: [6675] [general.info] captured 1 video device This DVB-T stick is clearly *NOT* DVB-S capable - so this might be part of the problem. I don't get this message in 1.6.0 at all. Is this related to the problem Morfsta had in [1] ? - it is the same QAM 16 modulation I am trying to connect to - but mine is (QAM 16, 8K, 5/6, 1/4). Thanks in advance for any help. I'd like to stay with vdr 1.7.0 as well for plugin compatibility reasons. [1] http://www.linuxtv.org/pipermail/vdr/2009-February/019493.html _________________________________________________________________ http://redirect.gimas.net/?n=M0903xWLM2009 Neu: Messenger 2009! Hier kostenlos downloaden!

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr