vdr October 2010

vdr@linuxtv.org

55 participants
49 discussions

Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
by Luca Olivetti 08 Oct '10

08 Oct '10

Hello, this has been bugging me for a while, but since it happens on channels I don't usually watch, I didn't ask before. There are some channels that are completely unwatchable: even with a perfect signal (at least according to femon) I can only see blocking artefacts and chirping sound. I tried vdr-xine, the dxr3 or vlc/mplayer through streamdev, the result is always the same. Here are some of the channels where this is happening right now: Mirabelle TV;EUTELSAT:10972:VC78M2O0S0:S5.0W:29950:1061=2:1062=@3:0:0:4134:1375:20600:0 Normandie TV;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:851=2:852=fra@3:0:0:405:1375:20400:0 TV8 MONT BLANC;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:881=2:882=fra@3,883=ita@3:0:0:408:1375:20400:0 TVN Warszawa;TVN:11508:VC56M2O0S0:S13.0E:27500:512=2:650=pol@4:572:0:15801:318:1600:0 TVP Kultura;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:172=2:128=pol@4:513:0:5113:318:1500:0 PULS;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:171=2:124=pol@4:0:0:5112:318:1500:0 TRACE TV;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:164=2:96=eng@4,97=fra@4:0:0:5105:318:1500:0 (in fact all polish channels on this transponder do the same) RTV;Harmonic:11471:VM2O0S0:S13.0E:27500:611=2:612=@3:0:0:10622:318:1400:0 and many more. Any idea? -- Luca

6 31

reelbox plugin devel
by Придворов Андрей 08 Oct '10

08 Oct '10

Hi all I want get framerate (ex. 50 or 60 fps) of video data in ReelBoxDevice.c, int ReelBoxDevice::PlayTsVideo(const uchar *Data, int length) Need know framerate realtime. How I can do it? Can eHD hardware detect framerate of video, and give to me? (like Sigma Realmagick x-card em84xx) Or can vdr give me this info, but how? Can I use cFrameDetector. Analyze() in this function, or there is no relevant information for it. Give me an idea please :-)

1 0

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

Re: [vdr] VDR 1.7.16 fast forward / backward (DVB-S/FF/SDTV)
by Alexander Weber 04 Oct '10

04 Oct '10

Hi Tobias, please try the most recent Firmware for your FF card. It should work then. http://www.escape-edv.de/endriss/firmware/ Best, Alexander Message: 7 Date: Sun, 03 Oct 2010 19:16:55 +0200 From: Tobi <listaccount(a)e-tobi.net> Subject: [vdr] VDR 1.7.16 fast forward / backward (DVB-S/FF/SDTV) To: VDR Mailing List <vdr(a)linuxtv.org> Message-ID: <4CA8BA87.4090104(a)e-tobi.net> Content-Type: text/plain; charset=ISO-8859-1 Hi! Playing a PES recording, I can fast forward in trick speed, but as soon as I pause the fast forward mode and resume the normal playback, I'm back where I started. Going backwards in trick speed mode works fine. When playing a TS recording it's the other way around. Fast forward in trick speed mode works fine but going backward fails when resuming normal playback. In the cases where it doesn't work, the time index in the OSD and the progress bar are not updated. I've reproduced this with 1.7.14 and 1.7.16. Is this a (known) VDR bug or a problem with the DVB drivers in 2.6.32? Tobias

2 1

VDR 1.7.16 fast forward / backward (DVB-S/FF/SDTV)
by Tobi 03 Oct '10

03 Oct '10

Hi! Playing a PES recording, I can fast forward in trick speed, but as soon as I pause the fast forward mode and resume the normal playback, I'm back where I started. Going backwards in trick speed mode works fine. When playing a TS recording it's the other way around. Fast forward in trick speed mode works fine but going backward fails when resuming normal playback. In the cases where it doesn't work, the time index in the OSD and the progress bar are not updated. I've reproduced this with 1.7.14 and 1.7.16. Is this a (known) VDR bug or a problem with the DVB drivers in 2.6.32? Tobias

1 0

dvb-s2 missing modulation values
by Luca Olivetti 03 Oct '10

03 Oct '10

Hello, I cannot currently receive dvb-s2 channels, but I'd like to update my plugin to work more or less correctly with it (even if I only have a couple of users). The wikipedia page http://en.wikipedia.org/wiki/DVB-S2 says that dvb-s2 has 4 possible modulations: QPSK, 8PSK, 16APSK and 32APSK. Those are defined in s2api, frontend.h, as QPSK, PSK_8, APSK_16 and APSK_32. There's also a DQPSK, which I suppose is for directv? (see below). But in vdr's dvbdevice.c, ModulationValues only maps to strings QPSK, PSK_8 and APSK_16. APSK_32 and DQPSK are missing. I read transponder information from ini files downloadable from http://www.fastsatfinder.com/transponders.html#transponders-sorted I examined all files there, and for S2 transponders I found these definitions: QPSK (this is easy) 8PSK (supposedly maps to PSK_8) 16APSK (supposedly maps to APSK_16) DIRECTV (supposedly maps to DQPSK) so maybe APSK_32 isn't really needed? Bye -- Luca

1 1

Problem creating index files
by Teemu Suikki 03 Oct '10

03 Oct '10

Hi! I converted all my old MPEG-PES recordings to TS format with a script I posted some time ago. :) I deleted all the index files in the process because I thought VDR would re-create them. For most of the recordings it works as expected, when playing the file VDR says "creating index" and in a few seconds the index file is created. However there are a few cases where it doesn't work. VDR still says "creating index" but it never seems to start creating it! The playback works through the file, so the file is not corrupt or anything. However because there is no index, you can't fast forward or jump or edit, so it's a pain to watch these videos when you can't skip the commercials.. Sometimes if I stop the playback and start again, index creation works that time. But usually it never works if it fails once, for that recording.. When index creation works, you can press OK and see the timeline growing as the index is created. When it doesn't work, OK doesn't bring up the timeline, nothing happens.. -- Teemu Suikki http://www.z-power.fi/

3 3

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

xineliboutput config "video-buffer"
by Bellina Informatica 01 Oct '10

01 Oct '10

i've tried to play smooth HD channels on 919 (ita), but afer 2 min i get scatters (1 -2 secs) digging on /etc/vdr/setup.conf /home/.../.xine/config_xineliboutput i've discover that when the "block" (1 - 2 secs) happen the config option --video-buffer RESET TO 250 (sound impossible for HD content) I've double check that vdr (runvdr) and the front-end where not running. The strange is that if i use the --buffer=800 in the vdr-sxfe, config_xineliboutput don't change, and "scatters" are quite rare. Why ? Atom, ION 1.6 (Giaga) vdr 1.7.14 ffmpeg (cvs -less than 1 month) xine-lib (cvs - less than 1 month) cpu is max 25%, the first CPU-thread (bin vdr) bounce from 5,10% (SD-channels) up to (60-90% HD), dmesg report 4 CPU's top -total CPU usage -> max 25% (HD content)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr October 2010