vdr

vdr@linuxtv.org

2 participants
6731 discussions

streamdev-client and softdevice
by Henrik Niehaus 19 Aug '05

19 Aug '05

hi, im trying to create a vdr-client on my workstation. i have: vdr 1.3.25 softdevice-0.1.2 i compiled vdr and the plugins without error. then i have started vdr with this command: vdr --video=/video --epgfile=/etc/vdr/epg.data --config=/etc/vdr --lib=/usr/lib/vdr -P"softdevice -vo xv: -L /usr/lib/vdr" -P"streamdev-client" and that worked fine, too. i had video and audio output including epg info. after closing this window and restarting vdr, i got the xv window with epg data, but no video and no audio. i have rebooted both, my workstation and the vdr-host. still the same problem. any clue? greetings, henrik

2 7

Looking for a mpeg demuxer under GPL
by Christian Gmeiner 19 Aug '05

19 Aug '05

Hi all, i am looking for a robust and well coded mpeg demuxer. I want to replace the current demuxer of the dxr3 plugin with a newer and better designed one. Maybe somebody can give me a hint?! Greets, Christian -- Christian Gmeiner Developer for Rockbox (http://www.rockbox.org) Maintainer of the DXR3-Plugin for VDR: http://sourceforge.net/projects/dxr3plugin/ Maintainer of VDR-Ebuilds at Gentoo.de

2 1

Picture hangs from time to time, no freeze
by Sebastian 19 Aug '05

19 Aug '05

Hello all! Like some other users I experience channel freezes sporadically since 1.3.29. Some have this since 1.3.28 or even 1.3.24. For me it happened looking WDR, others reported the same (on vdr-portal.de) with Pro7/Sat1/NDR. I experienced this behaviour on a small Epia ME6000 with a TT rev. 1.6 and kernel 2.6.13-rc6, but the problem doesn't seem to be related to drivers nor firmware (that's the consensus on vdr-portal.de). The picture hangs, but after some time it starts playing again. You can change to other channels no problem (and of course they work). I don't know about messages in the log because I ran vdr with -l0 at the time (sorry ;-)). Reception was normal, no rain but some clouds (but we had this kind of weather before and it didn't happen). Someone suggested to remove #define TEST_cVideoRepacker in remux.c, but apparently this didn't help. Thanks Sebastian -- "What the f*** are we doing out here in the middle of the desert?" - A foreigner, probably Samoan

2 2

RE: [vdr] VDR LiveBuffer Patch
by jori.hamalainen＠teliasonera.com 18 Aug '05

18 Aug '05

> A nice new patch arrived at VDR-Portal: > http://www.vdr- > portal.de/board/thread.php?threadid=37309&sid=&hilight=live%2A > With this Patch VDR can do permanent timeshift, so you can see the last > scene again whenever you want :-) The patch in theory seems very interesting (didn't compile & try it). Nice work. I have additional question, if I see "interesting scene" it is nice I can rewind it. But can I also via menu/red button record it to disk? Best regards, Jori

2 1

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr