vdr September 2010

vdr@linuxtv.org

48 participants
72 discussions

cSdtFIlter and LinkChannels
by Luca Olivetti 12 Nov '10

12 Nov '10

Hello, I'm trying to understand cSdtFilter in order to write a channel scanner. I see that when it finds a SI::NVODReferenceDescriptorTag it will add it to the previously found channel with channel->SetLinkChannels, but it only does if it is in the current section (channel is a local variable) while the sdt could span several sections. From the specifications here http://neuron2.net/library/mpeg2/iso13818-1.pdf and here http://www.dvb.org/technology/standards/a005r5.tm1324r13.tr101211.v1.10.1.p… I don't understand if this mechanism is correct, shouldn't the "time_shifted_services" link to the "NVOD_reference"? Besides, I don't see that the relation between a channels and its linkchannels is preserved in channels.conf (though I don't really care). I also see that cSdtFilter starts processing with the first section, and that shouldn't really be necessary as long as one processes all sections. Bye -- Luca

3 4

Recordings Numbering
by Dominic Evans 11 Nov '10

11 Nov '10

Hi all, I was wondering about the recording numbers associated with recordings in the LSTR output. There doesn't seem to be any obvious pattern, is the numbering just random? It'd be preferable if recordings kept a unique number, that didn't change when every time a recording gets deleted, or a new recording is started. Cheers, Dom

11 18

Re: [vdr] ERROR: driver buffer overflow on device 1
by peter 07 Oct '10

07 Oct '10

>Does this happen too when not using vdpau? I'm not using vdpau (haven't got the hardware for it). vdr-1.7.10 xine-lib-1.2 The problem occurs when running xine with dxr3 output (xine --verbose=1 -V dxr3 -A alsa vdr:/tmp/vdr-xi/stream) Mar 18 13:26:43 vdr-desktop kernel: [ 6250.760298] em8300-0: adjusting scr: 30791 Mar 18 13:26:45 vdr-desktop kernel: [ 6252.872307] em8300-0: adjusting scr: 125823 Mar 18 13:27:05 vdr-desktop vdr: [4159] buffer usage: 70% (tid=4158) Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 80% (tid=4158) Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 90% (tid=4158) Mar 18 13:27:07 vdr-desktop vdr: [4159] buffer usage: 100% (tid=4158) Mar 18 13:27:18 vdr-desktop vdr: [4159] ERROR: driver buffer overflow on device 1 Mar 18 13:27:18 vdr-desktop vdr: [4159] buffer usage: 30% (tid=4158) Mar 18 13:27:18 vdr-desktop vdr: [4158] ERROR: skipped 11 bytes to sync on TS packet on device 1 Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (3) Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (11) Mar 18 13:27:18 vdr-desktop vdr: [4158] cAudioRepacker(0xC0): skipped 312 bytes while syncing on next audio frame However: When running without dxr3 (xine --verbose=1 -V xshm -A alsa vdr:/tmp/vdr-xine/stream) everything is fine. Here's gdb output from a bad run: (gdb) thread apply all bt Thread 10 (Thread 0xb7648b70 (LWP 4030)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a56e in cCondVar::TimedWait (this=0x9d7fac4, Mutex=..., TimeoutMs=1000) at thread.c:127 #3 0x080afd3e in cDvbTuner::Action (this=0x9d7f508) at dvbdevice.c:389 #4 0x08119d40 in cThread::StartThread (Thread=0x9d7f508) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 9 (Thread 0xb6e47b70 (LWP 4031)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00741c96 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0x080ff76a in cSectionHandler::Action (this=0x9d6f610) at sections.c:184 #3 0x08119d40 in cThread::StartThread (Thread=0x9d6f610) at thread.c:257 #4 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 8 (Thread 0xb6646b70 (LWP 4032)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00741c96 in poll () from /lib/tls/i686/cmov/libc.so.6 ---Type <return> to continue, or q <return> to quit--- #2 0x0811f97b in cPoller::Poll (this=0x64, TimeoutMs=100) at tools.c:1195 #3 0x002a513d in PluginXine::cXineRemote::Action (this=0x9d842d8) at xineRemote.c:157 #4 0x08119d40 in cThread::StartThread (Thread=0x9d842e8) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 7 (Thread 0xb5e1ab70 (LWP 4033)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a56e in cCondVar::TimedWait (this=0xb5e1d7b8, Mutex=..., TimeoutMs=100) at thread.c:127 #3 0x00298ead in PluginXine::cXineLib::Action (this=0xb5e1d260) at xineLib.c:2632 #4 0x08119d40 in cThread::StartThread (Thread=0xb5e1d260) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 6 (Thread 0xb5619b70 (LWP 4034)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #2 0x0811a56e in cCondVar::TimedWait (this=0xb5e1d310, Mutex=..., TimeoutMs=100) at thread.c:127 #3 0x002a6278 in PluginXine::cXineExternal::Action (this=0xb5e1d2b8) at xineExternal.c:204 #4 0x08119d40 in cThread::StartThread (Thread=0xb5e1d2b8) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 5 (Thread 0xb4e18b70 (LWP 4035)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5ec8b in read () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x00113901 in cRemoteDevInput::getKey() () from /usr/lib/vdr/libvdr-remote.so.1.7.10 #3 0x00113d87 in cRemoteGeneric::Action() () from /usr/lib/vdr/libvdr-remote.so.1.7.10 #4 0x08119d40 in cThread::StartThread (Thread=0x9d867f0) at thread.c:257 #5 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread 0xb4617b70 (LWP 4036)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00741c96 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0x0811f97b in cPoller::Poll (this=0x32, TimeoutMs=50) at tools.c:1195 ---Type <return> to continue, or q <return> to quit--- #3 0x080f9028 in cKbdRemote::ReadKey (this=0x9d86910) at remote.c:296 #4 0x080f90ce in cKbdRemote::ReadKeySequence (this=0x9d86910) at remote.c:312 #5 0x080f97c2 in cKbdRemote::Action (this=0x9d86910) at remote.c:353 #6 0x08119d40 in cThread::StartThread (Thread=0x9d86920) at thread.c:257 #7 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb3cf2b70 (LWP 4070)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5ec0b in write () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0029593a in PluginXine::cXineLib::xwrite (this=0xb5e1d260, f=7, b=0x9f65968, n=585) at xineLib.c:2457 #3 0x0029722b in PluginXine::cXineLib::execFuncStream (this=0xb5e1d260, Data=0x9f65968 "", Length=585) at xineLib.c:2937 #4 0x002972c4 in PluginXine::cXineLib::execFuncStream1 (this=0xb5e1d260, Data=0x9f65968 "", Length=585) at xineLib.c:2906 #5 0x00290072 in PluginXine::cXineDevice::PlayCommon3 (this=0xb5e1b008, Data=0x9f65968 "", Length=585, ptsForce=7920770849) at xineDevice.c:1969 #6 0x002900e5 in PluginXine::cXineDevice::PlayCommon2 (this=0xb5e1b008, Data=0x9f65968 "", Length=585, ptsForce=7920770849) at xineDevice.c:1849 #7 0x00290344 in PluginXine::cXineDevice::PlayCommon1 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, ptsForce=-1) at xineDevice.c:3134 #8 0x0029182a in PluginXine::cXineDevice::PlayCommon (this=0xb5e1b008, ---Type <return> to continue, or q <return> to quit--- Data=0x9e1117c "", Length=2048, stillImageData=false) at xineDevice.c:3092 #9 0x00293dab in PluginXine::cXineDevice::PlayVideo3 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, stillImageData=<value optimized out>) at xineDevice.c:2132 #10 0x0029469a in PluginXine::cXineDevice::PlayVideo2 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, stillImageData=false) at xineDevice.c:2052 #11 0x002948b6 in PluginXine::cXineDevice::PlayVideo1 (this=0xb5e1b008, Data=0x9e1117c "", Length=2048, stillImageData=false) at xineDevice.c:1781 #12 0x00294983 in PluginXine::cXineDevice::PlayVideo (this=0xb5e1b008, Data=0x9e1117c "", Length=2048) at xineDevice.c:1760 #13 0x0029088e in PluginXine::cXineDevice::PlayTsTrampoline (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188, VideoOnly=false) at xineDevice.c:1727 #14 0x002949d1 in PluginXine::cXineDevice::PlayVideo (this=0x249, Data=0xb3cf21dc "", Length=20) at xineDevice.c:1752 #15 0x080a8ad2 in cDevice::PlayPesPacket (this=0xb5e1b008, Data=0xb3cf21dc "", Length=20, VideoOnly=false) at device.c:1174 #16 0x00290a00 in PluginXine::cXineDevice::PlaySingleTs (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022---Type <return> to continue, or q <return> to quit--- ", Length=188, VideoOnly=<value optimized out>) at xineDevice.c:1646 #17 0x0028d838 in PluginXine::cXineDevice::PlayTsImpl (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188, VideoOnly=false) at xineDevice.c:1590 #18 0x0028e77a in PluginXine::cXineDevice::PlayTs (this=0xb5e1b008, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188, VideoOnly=<value optimized out>) at xineDevice.c:1572 #19 0x08123541 in cPlayer::PlayTs (this=0x9da5a50, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188) at player.h:47 #20 cTransfer::Receive (this=0x9da5a50, Data=0xb33023d2 "G\004\067\030Ƒ\243F\226\266\215\032au\243F\030\215\031\272*P\326\030Yl\255\030=\206\214\347\260i\322\207\326\\8\r0\305h\314\304\a22\263B\353\f6\241{н\343\v\375\240\023\200f\204\200h\003\002\031,\254\002$\214\213e1\022", Length=188) at transfer.c:46 #21 0x080a7438 in cDevice::Action (this=0x9d7d250) at device.c:1464 #22 0x08119d40 in cThread::StartThread (Thread=0x9d7d250) at thread.c:257 ---Type <return> to continue, or q <return> to quit--- #23 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #24 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb32f0b70 (LWP 4071)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a650 in cCondWait::Wait (this=0x9d9cc04, TimeoutMs=100) at thread.c:71 #3 0x080fd8d7 in cRingBuffer::WaitForPut (this=0x9d9cc00) at ringbuffer.c:58 #4 0x080fdc5c in cRingBufferLinear::Read (this=0x9d9cc00, FileHandle=13, Max=0) at ringbuffer.c:247 #5 0x080a5982 in cTSBuffer::Action (this=0x9d9cbb8) at device.c:1606 #6 0x08119d40 in cThread::StartThread (Thread=0x9d9cbb8) at thread.c:257 #7 0x00c5780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #8 0x0074f8de in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb77a96d0 (LWP 4026)): #0 0x0018a422 in __kernel_vsyscall () #1 0x00c5c142 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0811a56e in cCondVar::TimedWait (this=0x817e080, Mutex=..., TimeoutMs=1000) at thread.c:127 ---Type <return> to continue, or q <return> to quit--- #3 0x080f9258 in cRemote::Get (WaitMs=1000, UnknownCode=0x0) at remote.c:191 #4 0x08126826 in main (argc=9, argv=0xbfc82424) at vdr.c:920 /Peter Odéus

4 5

Problem with VDR 1.7.15 and dxr3plugin 0.2.10
by Teemu Suikki 02 Oct '10

02 Oct '10

Hi! I have been using ancient versions of VDR 1.4.5 and dxr3plugin 0.2.6 for years now, with no real problems. For some reason I decided to try the recent versions. :) VDR 1.7.15 and dxr3plugin 0.2.10. VDR starts and works. It can record, and with streamdev I can watch live video on my laptop... So VDR is receiving everything correctly. However there's no picture or sound, so dxr3 output is not working. At some point I was able to get OSD up, and it seemed to work ok, but there was no video. After I recompiled dxr3plugin with most recent ffmpeg svn version, I lost OSD too. :D My log is filled with: Aug 23 20:25:38 vdr vdr: [22560] cDxr3DemuxDevice::DemuxPes() ePesFrameError skipping data and resync Aug 23 20:25:41 vdr last message repeated 27 times So basicly dxr3plugin judges all frames invalid? The old VDR (1.4.5) with dxr3 plugin 0.2.6 still works fine, even after full recompile of both.. -- Teemu Suikki http://www.z-power.fi/

5 14

Re: [vdr] Arabic language EPG is inappropriately displayed
by semsem85 sami 30 Sep '10

30 Sep '10

>Please let me know whether it actually works as expected. >Klaus I tested it today by upgrading to yavdr 0.3, and Arabic language is working perfectly:) Thanks alot Klaus for your help. Regards Sami

1 0

.TS recordings
by Dominic Evans 29 Sep '10

29 Sep '10

For reason, when playing back 1 out of every 10 .ts recordings (from vdr 1.7.x) in XBMC, it is unable to skip forwards through the recording, instead it just jumps back to the start of the recording (00:00). Any idea why this might be? Cheers, Dom

1 1

Fwd: Re: vdr xine-lib eac3
by dplu 26 Sep '10

26 Sep '10

Hi I use a "recent" ffmepg , I can use ffplay to play the ts records and I have sound, even with the e-ac3 spectral extention available in France on DVB-T HD Some others French user will try from their side also and I will check asap my patch and libs ... and install the very latest ffmpeg from git Thanks for the job Regards Le Sunday 26 September 2010 20:47:04 Jose Alberto Reguero, vous avez écrit : > El Domingo 26 Septiembre 2010, dplu escribió: > > Hi > > > > I Just test your patch, thanks for it, it applied well but seems not > > working, no e-ac3 sound on sample e-ac3 record for French DVB-T but AC3 > > sound is still OK > > > > Which xine-lib 1.2 did you use ? this one : > > http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ > > is not allways well synchronized, for example the patch for demux_ts on > > 1.1.18 changeset a1ba73e0b475 (april 9) is not on 1.2 > > > > I will check another time to see if I made no error on patching > > > > Regards > > You need a recent ffmpeg. I use latest hg xine-lib-1.2, and latest ffmpeg > svn. > > Jose Alberto. > > > Le Tuesday 21 September 2010 00:57:39 Jose Alberto Reguero, vous avez > > écrit : > > > El Domingo, 13 de Junio de 2010, Luca Olivetti escribió: > > > > Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit: > > > > > Patch for xine-lib that don't need to patch remux.c to work. > > > > > > > > Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but > > > > there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the > > > > ts directly through xine). > > > > Do I need some special options to configure xine-lib for this patch > > > > to take effect? > > > > > > > > Bye > > > > > > With this two patches vdr-xine work with eac3. I can't test if it still > > > work with normal ac3. One patch is for the plugin, and the other is for > > > xine-lib 1.2. > > > > > > Jose Alberto > > > > _______________________________________________ > > vdr mailing list > > vdr(a)linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > _______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -------------------------------------------------------

1 0

streamdev CVS - recent tarball?
by Gavin Hamill 26 Sep '10

26 Sep '10

Hi, I'm trying to compile streamdev 0.5.0 on an elderly 2006 Ubuntu and am getting some compile errors. Frank Schmirler says the current CVS contains fixes for that, but the CVS server at vdr-developer.org is down. Does anyone have a recent CVS checkout they wouldn't mind sending me? streamdev is the last thing I need to finally upgrade from VDR 1.4.7 :) Cheers, Gavin.

3 7

cDvbDevice::Initialize
by syrius.ml＠no-log.org 25 Sep '10

25 Sep '10

Hi, I'm having a setup with 4 dvb cards, and I'm running 3 vdr instances. I'm using an udev rules to make sure adapter numbers don't change. I'm using the -D option the assign cards to vdr instances. I've just discovered that vdr -D 3 would not use the adapter 3 if adapter2 was missing from /dev/dvb/. Here is the patch i'm testing to correct this issue, feel free to comment. --

2 2

Re: [vdr] [PATCH] Add support for shared frondends cards
by support.intranet 25 Sep '10

25 Sep '10

---------- Initial Header ----------- >From : vdr-bounces(a)linuxtv.org To : "VDR Mailing List" vdr(a)linuxtv.org Cc : Date : Wed, 22 Sep 2010 21:41:01 +0100 Subject : Re: [vdr] [PATCH] Add support for shared frondends cards > On 21 Sep 2010, at 16:06, support.intranet wrote: > > > The attached patch (for VDR 1.7.16) implements support for multituner cards where only one tuner can be active at one time, the so called shared frontend cards (notably the HVR-4000 and its derivatives). > > Currently VDR tries to open all the frontends on startup, with the result that the first frontend (usually DVB-S) works, but the second (usually DVB-T) fails with "Device or resource busy" error. The patch adds a new configuration option to setup.conf, called "OnDemand"; it defaults to 0 (exactly the current behaviour). If set to 1, tuners will be appropriately opened and closed when switching channels. I've tested it with the vnsi plugin and XBMC. > > I'd be happy if someone could review it and tell me if there is anything to correct and if it is possible to mainline it. > > Alberto > > <aod.diff>_______________________________________________ > > vdr mailing list > > vdr(a)linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > Ciao Alberto, > > Interesting work. I live in the UK and have an HVR4000 for DVB-S. Unfortunately DVB-T reception is poor where I live (hence the satellite solution - additional multilnb to point at 28.2E and 13.0E for L'Eridita) so I cannot fully test this past patching and compiling which I assume will work as you state you have tested. > > Looking at the patch, there is something about inhibit epgscan. I do not know much about vdr internals. Would patching vdr and enabling the ondemand option stop epg from updating? A slight negative if this is the case. > > > Ian. > > > _______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > Hi Ian, thanks for your answer. The problem with background epg scan is that it tries to access the device you are not using to watch/record as it thinks it is free, so if I don't disable it your favourite program would be stopped every few moments because the scan is taking place (and it closes down all other devices to access its one). I'm currently working on a better approach to this, so that if VDR is opened but you are not using it epg scan is allowed to work. Alberto

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr September 2010