vdr

vdr@linuxtv.org

6731 discussions

Re: [vdr] CAM/CI Dumb Question
by Simon Baxter 17 Apr '07

17 Apr '07

> > Question is, when you're using a CAM to decrypt channels, can it decrypt > > multiple channels simultaneously like the above for FTA??? > > AFAIK, yes, under certain conditions: > 1) vdr 1.5.x needed > 2) your CAM must support multiple streams > 3) your CAM must respond to query request Thanks Any known working DVB-C/CAM/CI combinations?

2 1

Question about audio on FF C2300/Nexus-CA
by Simon Baxter 17 Apr '07

17 Apr '07

Hi everyone. Can you use a fully-featured card (with MPEG decoder) without using the decoder? I've read you need to attach an external cable from the card audio output to the PC soundcard. Is this necessary??? Can you just use xineliboutput or vdr-xine as a soft device instead??

3 2

Suffering from continuous vdr restarts in various situations
by Hans-Peter Jansen 16 Apr '07

16 Apr '07

Hi, we're suffering from continuous vdr restarts every few minutes during recording of certain programs, while this is spat into syslog: Apr 16 20:56:26 ziggy vdr: [9916] switching device 2 to channel 7 Apr 16 20:56:26 ziggy vdr: [9916] timer 13 (7 2009-2132 'Die ProSieben M344rchenstunde~Mon 16.04.2007-20:14') start Apr 16 20:56:26 ziggy vdr: [9916] Title: 'Die ProSieben M344rchenstunde' Subtitle: '(null)' Apr 16 20:56:26 ziggy vdr: [9916] record /video0/Die_ProSieben_M344rchenstunde/Mon_16.04.2007-20:14/2007-04-16.20.09.50.99.rec Apr 16 20:56:26 ziggy vdr: [9916] recording to '/video0/Die_ProSieben_M344rchenstunde/Mon_16.04.2007-20:14/2007-04-16.20.09.50.99.rec/020.vdr' Apr 16 20:56:26 ziggy vdr: [9943] file writer thread started (pid=9916, tid=9943) Apr 16 20:56:26 ziggy vdr: [9944] recording thread started (pid=9916, tid=9944) Apr 16 20:56:26 ziggy vdr: [9945] receiver on device 2 thread started (pid=9916, tid=9945) Apr 16 20:56:26 ziggy vdr: [9946] TS buffer on device 2 thread started (pid=9916, tid=9946) Apr 16 20:56:26 ziggy vdr: [9944] cAudioRepacker(0xC0): skipped 576 bytes to sync on next audio frame Apr 16 20:56:26 ziggy vdr: [9943] ERROR: unknown picture type '6' Apr 16 20:56:27 ziggy vdr: [9936] channel 7 (ProSieben) event Mon 16.04.2007 20:14-21:21 'Die ProSieben M344rchenstunde' status 4 Apr 16 20:56:27 ziggy vdr: [9943] ERROR: unknown picture type '6' Apr 16 20:56:28 ziggy vdr: [9944] PES packet shortened to 3343 bytes (expected: 3470 bytes) Apr 16 20:56:28 ziggy vdr: [9944] cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Apr 16 20:56:33 ziggy vdr: [9944] PES packet shortened to 3347 bytes (expected: 3470 bytes) Apr 16 20:56:34 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:56:35 ziggy vdr: [9944] PES packet shortened to 3372 bytes (expected: 3470 bytes) Apr 16 20:56:35 ziggy vdr: [9944] PES packet shortened to 3394 bytes (expected: 3470 bytes) Apr 16 20:56:35 ziggy vdr: [9944] PES packet shortened to 3312 bytes (expected: 3470 bytes) Apr 16 20:56:39 ziggy vdr: [9944] PES packet shortened to 3379 bytes (expected: 3470 bytes) Apr 16 20:56:39 ziggy vdr: [9944] PES packet shortened to 3390 bytes (expected: 3470 bytes) Apr 16 20:56:39 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:56:40 ziggy vdr: [9944] PES packet shortened to 3431 bytes (expected: 3470 bytes) Apr 16 20:56:42 ziggy vdr: [9938] EPGSearch: search timer update started Apr 16 20:56:42 ziggy vdr: [9938] EPGSearch: search timer update finished Apr 16 20:56:44 ziggy vdr: [9944] PES packet shortened to 3325 bytes (expected: 3470 bytes) Apr 16 20:56:45 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:56:49 ziggy vdr: [9944] PES packet shortened to 3394 bytes (expected: 3470 bytes) Apr 16 20:56:49 ziggy vdr: [9944] PES packet shortened to 3369 bytes (expected: 3470 bytes) Apr 16 20:56:53 ziggy vdr: [9944] PES packet shortened to 3451 bytes (expected: 3470 bytes) Apr 16 20:56:54 ziggy vdr: [9944] PES packet shortened to 3348 bytes (expected: 3470 bytes) Apr 16 20:56:57 ziggy vdr: [9944] PES packet shortened to 3374 bytes (expected: 3470 bytes) Apr 16 20:57:02 ziggy vdr: [9944] PES packet shortened to 3343 bytes (expected: 3470 bytes) Apr 16 20:57:02 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:57:03 ziggy vdr: [9944] PES packet shortened to 3312 bytes (expected: 3470 bytes) Apr 16 20:57:04 ziggy vdr: [9944] PES packet shortened to 3463 bytes (expected: 3470 bytes) Apr 16 20:57:06 ziggy vdr: [9944] PES packet shortened to 2252 bytes (expected: 3470 bytes) Apr 16 20:57:06 ziggy vdr: [9944] PES packet shortened to 3354 bytes (expected: 3470 bytes) Apr 16 20:57:07 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:57:08 ziggy vdr: [9944] PES packet shortened to 3451 bytes (expected: 3470 bytes) Apr 16 20:57:08 ziggy vdr: [9944] PES packet shortened to 1691 bytes (expected: 3470 bytes) Apr 16 20:57:09 ziggy vdr: [9944] PES packet shortened to 3353 bytes (expected: 3470 bytes) Apr 16 20:57:10 ziggy vdr: [9944] PES packet shortened to 3377 bytes (expected: 3470 bytes) Apr 16 20:57:11 ziggy vdr: [9944] PES packet shortened to 3385 bytes (expected: 3470 bytes) Apr 16 20:57:16 ziggy vdr: [9944] PES packet shortened to 3329 bytes (expected: 3470 bytes) Apr 16 20:57:16 ziggy vdr: [9944] PES packet shortened to 3312 bytes (expected: 3470 bytes) Apr 16 20:57:17 ziggy vdr: [9943] ERROR: unknown picture type '6' Apr 16 20:57:17 ziggy vdr: [9944] PES packet shortened to 3446 bytes (expected: 3470 bytes) Apr 16 20:57:17 ziggy vdr: [9944] PES packet shortened to 3276 bytes (expected: 3470 bytes) Apr 16 20:57:18 ziggy vdr: [9944] PES packet shortened to 3416 bytes (expected: 3470 bytes) Apr 16 20:57:18 ziggy vdr: [9944] PES packet shortened to 3453 bytes (expected: 3470 bytes) Apr 16 20:57:19 ziggy vdr: [9944] PES packet shortened to 1814 bytes (expected: 3470 bytes) Apr 16 20:57:21 ziggy vdr: [9944] PES packet shortened to 3460 bytes (expected: 3470 bytes) Apr 16 20:57:23 ziggy vdr: [9944] PES packet shortened to 3312 bytes (expected: 3470 bytes) Apr 16 20:57:23 ziggy vdr: [9944] PES packet shortened to 3312 bytes (expected: 3470 bytes) Apr 16 20:57:23 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:57:26 ziggy vdr: [9944] PES packet shortened to 3463 bytes (expected: 3470 bytes) Apr 16 20:57:27 ziggy vdr: [9944] PES packet shortened to 3286 bytes (expected: 3470 bytes) Apr 16 20:57:28 ziggy vdr: [9944] PES packet shortened to 3441 bytes (expected: 3470 bytes) Apr 16 20:57:28 ziggy vdr: [9944] PES packet shortened to 3381 bytes (expected: 3470 bytes) Apr 16 20:57:30 ziggy vdr: [9944] PES packet shortened to 3353 bytes (expected: 3470 bytes) Apr 16 20:57:30 ziggy vdr: [9944] PES packet shortened to 3460 bytes (expected: 3470 bytes) Apr 16 20:57:32 ziggy vdr: [9944] PES packet shortened to 3378 bytes (expected: 3470 bytes) Apr 16 20:57:32 ziggy vdr: [9944] PES packet shortened to 3315 bytes (expected: 3470 bytes) Consequently, the recording looks like this: -rw-r--r-- 1 root root 46206106 16. Apr 20:10 001.vdr -rw-r--r-- 1 root root 74572590 16. Apr 20:13 002.vdr -rw-r--r-- 1 root root 66506990 16. Apr 20:16 003.vdr -rw-r--r-- 1 root root 26305741 16. Apr 20:17 004.vdr -rw-r--r-- 1 root root 52148572 16. Apr 20:20 005.vdr -rw-r--r-- 1 root root 44534932 16. Apr 20:22 006.vdr -rw-r--r-- 1 root root 46697082 16. Apr 20:25 007.vdr -rw-r--r-- 1 root root 44775953 16. Apr 20:27 008.vdr -rw-r--r-- 1 root root 89219748 16. Apr 20:31 009.vdr -rw-r--r-- 1 root root 64450050 16. Apr 20:34 010.vdr -rw-r--r-- 1 root root 62903307 16. Apr 20:37 011.vdr -rw-r--r-- 1 root root 62823090 16. Apr 20:40 012.vdr -rw-r--r-- 1 root root 76741400 16. Apr 20:43 013.vdr -rw-r--r-- 1 root root 43414533 16. Apr 20:45 014.vdr -rw-r--r-- 1 root root 48439977 16. Apr 20:47 015.vdr -rw-r--r-- 1 root root 69417766 16. Apr 20:50 016.vdr -rw-r--r-- 1 root root 30641331 16. Apr 20:52 017.vdr -rw-r--r-- 1 root root 33559155 16. Apr 20:54 018.vdr -rw-r--r-- 1 root root 38918804 16. Apr 20:56 019.vdr -rw-r--r-- 1 root root 66729752 16. Apr 20:59 020.vdr -rw-r--r-- 1 root root 42214919 16. Apr 21:01 021.vdr -rw-r--r-- 1 root root 7577021 16. Apr 21:01 022.vdr The signal quality looks fine. Since this problem already destroyed the "Deutschland sucht den Superstar" recording from saturday, the household peace is in danger. Any idea, whats going wrong here, is appreciated. Sys info: openSUSE 10.2, pretty actual vdr drivers from hg server, vdr 1.46, 2 Hauppauge FF 2.1 dvb-s cards. TIA, Pete

3 4

CAM/CI Dumb Question
by Simon Baxter 16 Apr '07

16 Apr '07

Hi I'm looking to use a budget DVB-C card with a CAM/CI module to watch/decrypt. I've used a DVB-T card to watch FTA channels, and really liked the ability to watch/record any combination of channels within the same boquet/TS. Question is, when you're using a CAM to decrypt channels, can it decrypt multiple channels simultaneously like the above for FTA??? Thanks Simon

2 1

VDR gets stuck in a reload-loop
by Matthias Schniedermeyer 15 Apr '07

15 Apr '07

Hi I have recently updated from VDR 1.2.6 to 1.4.6 I have the problem that once VDR emergency exists, for whatever reason, it never gets the recording started again in time, so it emergency exists again and again until the recording has ended. If i manually disable the timer, wait a few seconds and reenable timer the recording works. Added note: It is an encrypted channel and the CAM-found-message always appears a few seconds after VDR started, but before VDR tunes the channel and starts the timer. A few seconds later a: 'ERROR: no useful data seen within 10498860 byte of video stream' message appears and VDR emergency exists. According to UPDATE-1.4.0 VDR supposedly has to wait for the CAM to be initialized before it starts a recording, but it doesn't appear to do so for me. I have my own start-script, which does about the same as the runvdr example. (It reloads the driver before VDR is started again) Until a few minutes ago it didn't start VDR with the watchdog-parameter, which i added after looking into the runvdr-example. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.

1 1

plugin writing - need help with C
by Simon Baxter 13 Apr '07

13 Apr '07

Hi. I'm modifying a non-published pvrinput variation which sends IR commands to a set box box - specifically, the channel number stored in channels.conf. 12345J2:6:C12:C:0:301:300:305:A1:62006:0:1009:0 FOODJ2:63:C12:C:0:301:300:305:A1:62008:0:1019:0 ^^ - channel number to send to external digi-box It works fine, sending single-digit channel numbers but fails to send double digit. i.e. channels 1-9 are ok, but 10+ fail. This fails because there are only codes in the lircd.conf for 0-9. Here's an excerpt from the plugin which sends the commands: redremote.h <snip> class cRedRemote : public cThread { public: cRedRemote(); ~cRedRemote(); int Open(); void Tune(int channel); void Send(char *text); <snip> redremote.c <snip> void cRedRemote::Send(char *text) { char buf[100]; snprintf(buf,sizeof(buf), "SEND_ONCE ADB_ICAN3000 %s\n",text); write(fd,buf,strlen(buf)); close(fd); fd = -1; } <snip> My question is this. I need to modify the channel sent, so that double (or triple) channel numbers are sent as '6 3' or '1 1 7' rather than '63' or '117'. i.e. put spaces between the letters. I'm really out of my depth - can anyone point me in the right direction? Thanks Simon

2 4

Problem with epg PUTE
by Simon Baxter 12 Apr '07

12 Apr '07

I'm having problems processing epg into VDR. I have the following channels: LSTC 250-1 TV1-Cable:112250:C0:C:0:301:300:305:A1:1796:0:0:0 250-2 TV2-Cable:119250:C0:C:0:301:300:305:A1:1908:0:0:0 250-3 TV3-Cable:126250:C0:C:0:301:300:305:A1:2020:0:0:0 250-4 Prime-Cable:189250:C0:C:0:301:300:305:A1:3028:0:0:0 250-5 C4-Cable:203250:C0:C:0:301:300:305:A1:3252:0:0:0 250-6 Saturn Weather-Cable:147250:C0:C:0:301:300:305:A1:2356:0:0:0 250-7 Unknown-Cable:224250:C0:C:0:301:300:305:A1:3588:0:0:0 250-8 Sky Box Office-Cable:245250:C0:C:0:301:300:305:A1:3924:0:0:0 250-9 Sky Box Office Collage-Cable:252250:C0:C:0:301:300:305:A1:4036:0:0:0 250-10 Saturn Choose-Cable:259250:C0:C:0:301:300:305:A1:4148:0:0:0 250-99 S-Video 1;w_pvrscan:1:C12:C:0:301:300:305:A1:9001:0:0:0 250 100 Composite 1;w_pvrscan:1:C23:C:0:301:300:305:A1:9002:0:0:0 and the current date is: [vdruser@media xmltv2vdr-1.0.6]$ date +%s 1175557509 But when I try and input EPG it doesn't show up: PUTE 354 Enter EPG data, end with "." on a line by itself C C-0-112250-1796 TV1-Cable E 0 0 1175578200 0 T Neighbours D Sandy's life lies in Lolly's hands. Boyd fears Janae has been driven to murder. Ringo's secret shame prevents him from kissing Rachel. e c . 250 EPG data processed LSTE 215 End of EPG data This epg data is being processed by xmltv2vdr-1.0.6. Any ideas?

2 3

[ANNOUNCE] vdr-softdevice-0.4.0
by Stefan Lucke 11 Apr '07

11 Apr '07

Hello, the softdevice team (Torgeir Veimo, Martin Wache and me, Stefan Lucke) is pleased to announce a new release of vdr's softdevice plugin. General info: Softdevice plugin enables vdr to run on your desktop with so called budget cards. You'll get vdr output via framebuffer or X11-Xv or DirectFB or vidix to your screen. Decoding is done via ffmpeg. Support of vdr versions earlier than vdr-1.3.7 has been removed. Supported vdr versions: 1.3.x, 1.4.x and 1.5.x Plugin's homepage is located at: http://softdevice.berlios.de/ Changelog since last release: 2007-04-11: softdevice-0.4.0 - xv-out: activate suspend/resume key (r/R) via configure (by Artur Skawina). - i18n: some german translations. - osd: moved aspect detection entry to "Cropping" sub menu. 2007-04-03: - add automatic border detection, based on a patch by Roland Praml. - altivec needs 16 byte alignment - compile fix for Darwin - make flag for shared linking a variable - add BGRA32 mode to SoftOsd - compile linux RTC syncing mode support only on Linux. - detect cpu endianness and define CPU_BIGENDIAN if necessary. - add video-quartz and audio-macos for Mac Os X support 2007-03-25: - fix types in GetTime(). - pts values are stored in uint64_t - almost complete rewrite of video-fb. Supported are now 15,16,24 and 32 bit depth framebuffers. The osd is rendered with software alpha blending, and it is even faster :-) 2007-03-12: - compile fix for recent ffmpeg SVN - include ffmpeg headers as 'extern "C"' - enable and use as default the software mixer. The old behaviour (use the system's mixer) can be selected via -vo oss:mixer. - increase the stepsize of the software mixer. - don't scale audio if the volume is at maximum. - set edge_width/_height always to zero. Fixes picture shiftes with the ShmClient. This is not the optimal(/final) solution... 2007-03-04: - video-dfb: Make use of SetSourceRectangle() runtime selectable, changed *SetSourceLocation* to SetSourceRectangle. 2007-02-26: - softlog: sanitycheck for zero length filenames and fix use filename member when changeing append mode. - video-dfb: shifted most prints via softlog. - video sync: preparation for new changeable sync parameters. 2007-02-24: - Makefile: add --remove-destination , so that "make plugins" does not disturb a running vdr. - softlog: added indicator for priority I(nfo), E(rror), D(ebug), T(race). - video-vidix: shifted prints via softlog. 2007-02-13: - fix gettid compile error on some systems. 2007-02-11: - Some more options selectable via log menu. 2007-02-10: - Pause the playback of recordings when suspended (by Marko Mäkelä) - add configurable logging - report Xrun audio duration 2007-01-28: - don't lock NULL pictures in cVideo::GetLockLastPic(). - implement avcodec_decode_audio2() interface to libavcodec. - set ic->bp.is_streamed to true, to avoid calls to unimlemented seek method. - add architecture "x86_64" to configure and report unsupported architectures. - add StealToBitmap() for OSD in grabbed image. - add OSD with alpha blending to grabbed images. 2007-01-27: - video-dfb: - Limit VIA-unichrome name compare to 19 chars. - Detect a patched DirectFB version for VIA CN700 support, and set some parameters for video layer V3: pixelformat YUY2, NO hardware decoding support . 2007-01-20: - Fixed video-dfb for VIA-unichrome with current DirectFB cvs. In directfbrc pixelformat=AiRGB must be specified. 2007-01-15: - introduce yuv420_to_rgb15() (mmx acceleration still missing). - properly start cShmRemote thread in ShmClient. - avoid "BadWindow" errors by using an errror handler. Also fix "BadWindow" errors which occur after the xscreensaver has once been active. - fix vidWin for non zero VidX1 and VidY1. 2006-12-17: - Silence some warnings with gcc 4.1.1. - Adjust MMX and C version of fast_memcpy() to the same return type. - Fix wrong colors in yuv420_to_yuy2() when all MMX is disabled. 2006-12-13: - don't undefine X cursur on keypresses, to prevent the fake shift key press from producing flickering of the mouse cursor. - fix possible segfault. - fix possible division by zero. - comment out fake key sending syslog message - add cOSSAudioOut::GetDelay() (supplied by Lubos Novak). 2006-12-03: - applied patch from Matthias Schwarzott for vdr uint64 change. - unify yuv420_to_rgbXX() and yv12_to_yuy2_line() functions to allow usage in CopyScalePicBuf() - change CopyPicBuf_YUV420P_to_YUY() to a general YUV420P to planar conversion method - introduce the possibility to scale the video window (for yaepg). - detection of and support for the yaepg-patch. - add open sound system support (contributed by Lubos Novak). GetDelay() is commented out, this means the A/V synchronization is broken. - add open sound system detection to configure 2006-11-26: - use brackets in WRITE_RGB16 macro, introduce WRITE_RGB15 (untested) and ARGB_TO_RGB. - introduce FillPicBuffer() - make it possible to use a color key other than 0x000000 for video-xv, video-shm and ShmClient - change the default color key of xv-out to 0x001a0f00LL - add support for X11 drivers without xv support 2006-11-22: - remove cShmVideo::Process() method, and instead signal PICT_SIG from cShmRemote to simulate a timeout. - fix ShmClient not forwarding to key presses to vdr on AMD64 (patch by peterw2k@vdr-portal) 2006-11-20: - send fake key events to disable any screen saver (patch by peterw2k@vdr-portal) 2006-11-16: - fix wrong colors when using GRAB with the cle266 hardware decoder (patch by Laz) - better colorkey support in SoftOsd.c, with interface to video.c - fix a bug which causes bad resolution on upscaling - fix a bug which causes segfaults when upscaling to huge images - reintroduce the chessboard pattern for pseudo alpha blending - use WRITE_RGB macros from utils.h 2006-11-11: - !! removed support for vdr versions older than vdr-1.3.7 !! 2006-11-08: - change PIX_FMT_RGB32 to PIX_FMT_RGBA32 to support older ffmpeg versions 2006-11-07: - add yuv to rgb conversion routines for rgb32, rgb24, bgr24 and rgb16 - audio-alsa: restore samplerate after a unsuccessfull change request - add scaling methods with yuv to rgb conversion - add packed pixel format support to ClearPicBuffer() - move AllocatePicBuffer(), DeallocatePicBuffer(), GetFormatBPP and GetChromaSubSample() out of cPicBufferManager - add packed pixel format to PicBuffer - add GetLockLastPic() to video.h - add GrabImage() support. Currently there is no OSD in the grabbed images. - some more debugging info in softdevice.c - add explanations to error messages in ShmClient.c - use SEM_UNDO on PICT_MUT semaphore -- Stefan Lucke

1 0

xmltv2vdr 1.0.6 "channel=" problems
by Simon Baxter 11 Apr '07

11 Apr '07

Hi - I've been using xmltv2vdr for years. It's great! I'm now getting my xml EPG from a different source, and am having problems getting the perl script to run properly. My perl knowledge is poor (to say the least!!) The problem is, the epg xml I'm getting has the "channel=" at the wrong end of the "<programme" sequence. So instead of: <programme start="20070412060000 +1200" stop="20070412061000 +1200" channel="1031.dvb.guide"> it has : <programme channel="1031.dvb.guide" start="20070412060000 +1200" stop="20070412061000 +1200"> This results in the wrong SVRDP messages being produced. I get: CLRE PUTE C C-0-112250-1796 TV1-Cable E 0 0 1176231600 0 T Breakfast D Breakfast e c . so no program ID# and the start/duration is broken. I've tested this by manually changing a programme sequence in the xml, moving the "channel=" to the end - and it works fine. CLRE PUTE C C-0-112250-1796 TV1-Cable E 8895 1176231600 7200 0 T Breakfast D Breakfast e c . QUIT Can anyone help me?? Thanks heaps!!! Simon

2 2

[PATCH] limit streamdev client's ringbuffer timeouts to more sane values
by Artur Skawina 07 Apr '07

07 Apr '07

Well, the streamdev-client reads data from a ringbuffer and when there isn't anything to read it tries to sleep for 1us and loops. This wasn't a problem when the timer resolution was in the 1000..10000us range (1000..100Hz); the usleep(1) call slept for one or more milliseconds. With the high-res timers in kernel 2.6.21+ usleep(1) is no longer treated as usleep(10000) and the streamdev client is almost unusable; it uses most of the cpu and causes hundreds of thousands context switches per second. This gets rid of the almost-busy-loop. artur diff -urNp streamdev.org/client/filter.c streamdev/client/filter.c --- streamdev.org/client/filter.c 2005-11-06 17:43:58.000000000 +0100 +++ streamdev/client/filter.c 2007-04-05 23:25:11.000000000 +0200 @@ -57,6 +57,7 @@ cStreamdevFilters::cStreamdevFilters(voi cThread("streamdev-client: sections assembler") { m_Active = false; m_RingBuffer = new cRingBufferLinear(MEGABYTE(1), TS_SIZE * 2, true); + m_RingBuffer->SetTimeouts(10, 10); Start(); } @@ -111,8 +112,7 @@ void cStreamdevFilters::Action(void) { } } m_RingBuffer->Del(TS_SIZE); - } else - usleep(1); + } } }

2 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr