vdr August 2005

vdr@linuxtv.org

146 participants
183 discussions

Re: [vdr] How to speed up vdr start ?
by s.huelswitt＠gmx.de 17 Aug '05

17 Aug '05

On 09 Aug 2005 "Christoph Hermanns" <Christoph.Hermanns(a)web.de> wrote: > Am Sun, 7 Aug 2005 20:08:17 +0000 (UTC) schrieb Stefan Huelswitt > <s.huelswitt(a)gmx.de>: > >> On 07 Aug 2005 "Christoph Hermanns" <Christoph.Hermanns(a)web.de> wrote: >> >>> How can i speed up the starting of the dvb driver and vdr ? >> >> If you're using a FF dvb card, loading the firmware takes some >> time. >> >> You can speed up this (or actually hide some time) if you don't >> let runvdr load the driver but rather create an own startup >> script to load the driver and run this one very first after boot >> i.e. S01. You have to background (&) the make insmod call. >> > > > Is this correct: > > 1. Comment out the start of dvb driver in runvdr: > > # Load driver if it hasn't been loaded already: > #if [ $LSMOD -eq 0 ] ; then > # (cd $DVBDIR; make insmod) > # fi > > 2. Create new dvb-start.sh script (is the & at the right place ?): > # Load driver if it hasn't been loaded already: > if [ $LSMOD -eq 0 ] ; then > (cd $DVBDIR; &make insmod) > fi No, won't work that way. One problems is, that if you background the make insmod, the boot process continues while the firmware is loaded. If the rest of the boot script is fast, you may end with the situation that vdr starts up before the make insmod is finished. So I do to load the driver (may be a own script. I do it in boot directly) (you have to adjust the dvb driver path): ( touch /tmp/dvb-insmod; \ cd /usr/local/source/dvb; make insmod; rm /tmp/dvb-insmod ) & In runvdr I check for the existance of the trigger file: while [ -a /tmp/dvb-insmod ]; do sleep1 done This way the vdr startup is delayd until the insmod is finished. (may be there are mor sofisticated method to do this, but it works). > Question: If the dvb-driver hangs, will the restart be unaffected from > this change ? > (I think so, but i'll ask to be sure ;-) No, the restart won't be affected. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

4 3

[ANNOUNCE] VDR developer version 1.3.29
by Klaus Schmidinger 16 Aug '05

16 Aug '05

VDR developer version 1.3.29 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.29.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.28-29.diff The changes since version 1.3.28: - Fixed a race condition in cTransfer (thanks to Klaus ??? for reporting this one). In doing so, the 'active' variables used by the actual derived cThread classes have been replaced by the cThread::Running() function. Plugin authors may want to check their derived cThread classes and replace any 'active' variables the same way as, for instance, done in transfer.c. - Fixed handling EPG data for time shifted events (thanks to Marco Schlüßler). - Increased the default value for 'Min. user inactivity' to 300 minutes (suggested by Helmut Auer). - Now storing the channel id in the info.vdr file even if there is no EPG info available (thanks to Andreas Brachold for reporting that there are empty info.vdr files created in that case). - Added some 'mkdir -p' to the Makefile's 'install' target (thanks to Wayne Keer). - Changed the title of the recording info menu (thanks to Rolf Ahrenberg). - Fixed handling the frame number display if '7' is pressed before the first editing mark, or '9' after the last one (thanks to Thomas Günther). - Now discarding any previous numerical input to switch channels if Up, Down, Channel+, Channel-, Left or Right is pressed (thanks to Wolfgang Rohdewald for reporting a problem with this). - Pressing Ok while entering a channel number now immediately switches to that channel, without waiting for further input. - Avoiding unnecessary OSD draw operations caused by the audio track description display in the ST:TNG skin's channel display (thanks to Oliver Endriss for reporting this). - Removed the VIDEO_STILLPICTURE_WORKS_WITH_VDR_FRAMES stuff from cDvbDevice::StillPicture(), since apparently the VIDEO_STILLPICTURE call works. Have fun! Klaus _______________________________________________ vdr mailing list vdr(a)linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

2 3

zap.tartarus.org currently down (so no new VDR .debs)
by Darren Salt 16 Aug '05

16 Aug '05

zap.tartarus.org is currently down. It was moved last week and hasn't been right since. I can't access it and have no idea when it'll be back up. Until it's back up, you can find my current .diff.gz and .dsc files here: <URL:http://www.youmustbejoking.demon.co.uk/tmp/> You'll need to get source from upstream and build whichever packages you want yourself. I don't have space for all of the source, never mind the .debs... For vdr, the suggested build/install order is this: Build xine-lib Install libxine1, libxine-dev Build vdr Install vdr-dev Build $PLUGINS Install $PLUGINS, vdr For building, I recommend "debuild binary" (you'll need devscripts). -- | Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington, | Debian, | s zap,tartarus,org | Northumberland | RISC OS | @ | Toon Army | <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Brain failure (cortex dumped)

1 1

Re: [vdr] How to speed up vdr start ?
by s.huelswitt＠gmx.de 16 Aug '05

16 Aug '05

On 16 Aug 2005 "Christoph Hermanns" <Christoph.Hermanns(a)web.de> wrote: > Am Tue, 9 Aug 2005 19:17:04 +0000 (UTC) schrieb Stefan Huelswitt > <s.huelswitt(a)gmx.de>: > >> In runvdr I check for the existance of the trigger file: >> >> while [ -a /tmp/dvb-insmod ]; do >> sleep1 >> done >> >> This way the vdr startup is delayd until the insmod is finished. >> (may be there are mor sofisticated method to do this, but it >> works). > > I've tried this and it works with the trigger file, but it's about > 10 seconds slower than without checking the existing of the trigger file. > Strange...don't know.... Probably because without the trigger file, vdr start up before the driver finished loading. If it works it's ok, but I saw the risk that the driver is not "ready enough" and vdr startup fails. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

1 0

VDR-1.3.28: cVideoRepacker sucks (was: Re: [vdr] VDR developer version 1.3.28)
by Reinhard Nissl 16 Aug '05

16 Aug '05

Hi, Dominique Simon wrote: >> VDR developer version 1.3.28 is now available at > > As in 1.3.26 when the cVideoRepacker was introduced, it's making the > same problem again. e.g. when i watch a recording and a timer starts, > VDR crashes like this: [snip] > Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 4 > bytes to sync on next picture > Aug 9 20:12:09 linvdr user.debug vdr[1808]: buffer usage: 70% (tid=66573) > Aug 9 20:12:10 linvdr user.debug vdr[1808]: buffer usage: 80% (tid=66573) > Aug 9 20:12:11 linvdr user.debug vdr[1808]: buffer usage: 90% (tid=66573) > Aug 9 20:12:12 linvdr user.debug vdr[1808]: buffer usage: 100% > (tid=66573) > Aug 9 20:12:12 linvdr user.err vdr[1808]: ERROR: 1 ring buffer > overflow (65 bytes dropped) > Aug 9 20:12:18 linvdr user.err vdr[1808]: ERROR: 14271 ring buffer > overflows (2682948 bytes dropped) > Aug 9 20:12:24 linvdr user.err vdr[1808]: ERROR: 18048 ring buffer > overflows (3393024 bytes dropped) > Aug 9 20:12:30 linvdr user.err vdr[1808]: ERROR: 16976 ring buffer > overflows (3191488 bytes dropped) > Aug 9 20:12:32 linvdr user.err vdr[1806]: ERROR: video data stream broken > Aug 9 20:12:32 linvdr user.err vdr[1806]: initiating emergency exit > How can i turn that cVideoRepacker off again? VDR 1.3.26 worked like a > charm... It's the same switch by which you could enable it in VDR-1.3.27 (TEST_cVideoRepacker, remux.c:1279). But please help me fix this issue instead of turning it off. Strange is the timestamp 20:12:02: at this time, cVideoRepacker seems to be in sync, but for any reason, it seems to process no more data as at 20:12:32 the recording is aborted with "ERROR: video data stream broken" which indidates, that the recorder didn't see any data for 30 seconds. Simon Baxter sent me a similar report, but with debug code inserted which showed that cVideoRepacker wasn't completely stuck. Is it easy for you to trigger this issue? I've tried two simultanuous timers plus watching a recording but couldn't trigger the issue. Please add the following 4 lines, which are marked with "<========" to the appropriate source locations (cRepacker::Put(), cVideoRepacker::Repack()) in remux.c and send me the output when the problem happens again. static int Put(.....) { esyslog(">>>>> cRepacker::Put(%d)", Count); // <============ int n = ResultBuffer->Put(Data, Count); if (n != Count) esyslog(.....); esyslog("<<<<< cRepacker::Put"); // <============ return n; } . . . void cVideoRepacker::Repack(.....) { esyslog(">>>>> cVideoRepacker::Repack(%d)", Count); // <============ // synchronisation is detected some bytes after frame start. const int SkippedBytesLimit = 4; // reset local scanner localStart = -1; . . . // report that syncing dropped some bytes if (skippedBytes > SkippedBytesLimit) { esyslog(.....); skippedBytes = SkippedBytesLimit; } esyslog("<<<<< cVideoRepacker::Repack()"); // <============ } Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de

6 15

Re: [vdr] Watchdog kicks in, 1.3.28, 1.3.29
by Malte Schröder 16 Aug '05

16 Aug '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HGM.bg (GMX) wrote: > Malte Schröder wrote: > > >>when I set the epg-scan timeout to something greater than 0, VDR >>crashes reproducible. Attached is a piece of the log when it >>happened. I was watching a recording. > > > Just a question, what's the setting for the watchdog-timer and how big > is your video-disk and how many recordings you have ? Big disks with > many recording are eating a lot of vdr's power.... Timer is 60 Seconds, I currently have 47 recordings using 57GiB. The disk is a 120GB from Samsung. So Nothing out of the ordenary I think. > > >>Any clue what could cause this? > > > Perhaps, just give some more infos please > > >>Greets > > > /hgm.bg > > > _______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > - -- - --------------------------------------- Malte Schröder MalteSch(a)gmx.de ICQ# 68121508 - --------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDAWtq4q3E2oMjYtURAkYqAKCTlsL21Y9P1BNwaeXMeI9shswPYgCgsNhB Vk4MQpvmOqji/FArgJPlcj0= =5Mn3 -----END PGP SIGNATURE-----

1 0

[PATCH] jumpplay patch for vdr-1.3.29
by Thomas Günther 15 Aug '05

15 Aug '05

Hi! The jumpplay patch for vdr-1.3.29 is available: http://toms-cafe.de/vdr/download/vdr-jumpplay-0.6-1.3.29.diff Tom

1 0

Transfer mode and a motorised dish
by Malcolm Caldwell 15 Aug '05

15 Aug '05

Hello, I get the feeling that 1.4 might be getting close - so I though I should speak up now. I have a request: find a way to fix transfer mode while using a motorised dish. I have a dxr3 based system and a motorized dish. The problem is vdr only waits a few seconds (TUNER_LOCK_TIMEOUT set in device.c) before it reports "ERROR: device %d has no lock" and gives up. This makes it fairly painful. I have to change channel, wait for the dish to move and then go "menu->channels->OK" to re-tune the current channel. My "Fix" is not to return false after the timeout. This causes vdr to try to set up the filters anyway, and things work fine. When the dish moves the channels just starts to work fine. (If I am not wrong, vdr used to have no timeout here but some cards did not like you to set filters when there was no lock... ?) Setting the timeout to a large value is not an option as vdr is unresponsive during this period, making channel surfing 'stick' at various places where channels are un-available. I cannot think of a fix that preserves the "don't set filters without a lock" behaviour without using another thread. The other problem with vdr and motorised dishes is due to the timeout for recordings. If vdr receives no data for MAXBROKENTIMEOUT defined in recording.c it does an emergency restart. Now on the plus side, by the time vdr restarts my dish has (so far) always moved to the correct position! However, I must say it is hard to explain to my wife why the recording we just happened to be watching at the time stopped midway through... Maybe some of this could be fixed by to rotor plugin, however the rotor plugin should not be needed in this setup (I just define things in diseqc.conf). The better fix IMHO would be in vdr itself. I think a parameter that says "maximum timeout when changing source" might help the recording problem. Not so sure for the transfer mode problem.

4 10

vdr rpms on livna
by Pim Zandbergen 15 Aug '05

15 Aug '05

VDR just appeared on rpm.livna.org. Livna is a repository for add-on packages for Fedora Core. For now, only an i386 version appears to be available http://rpm.livna.org/fedora/4/i386/RPMS.lvn/vdr-1.3.28-1.lvn.1.4.i386.rpm http://rpm.livna.org/fedora/4/i386/RPMS.lvn/vdr-devel-1.3.28-1.lvn.1.4.i386… http://rpm.livna.org/fedora/4/i386/SRPMS.lvn/vdr-1.3.28-1.lvn.1.4.src.rpm Pim

2 1

Patch to Makefile so plugins are installed and man dirs are created
by C.Y.M 15 Aug '05

15 Aug '05

Hello, Attached is a patch so VDR does not error during the installation if the man directories do not exist. Also, this patch installs the plugins as well as the vdr binary when "make install" is used. Best Regards, C.Y.M.

3 5

← Newer
1
...
9
10
11
12
13
14
15
...
19
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 August 2005