vdr January 2011

vdr@linuxtv.org

64 participants
52 discussions

Re: [vdr] Request for rotor/actuator support integration to, vdr
by Arturo Martinez 24 Jan '11

24 Jan '11

:·) :·) I would also like some support for rotors in vdr, I can offer Klaus a free sat dish and an old rotor if that would motivate him... Klaus, as a minimum in vdr core we need the ability to specify a ´lapse value´ between a diseq command being sent (for non rotor users this would be zero, I´d imagine) and vdr tuning to a transponder or trying to add new channels. So in short if this value say was set to 30 seconds, then vdr would not add new channels or try to tune to a transponder. That would allow the rotor to do its job (with the existing diseqc.conf

3 3

[1.7.16] problem with GetClippedNumProvidedSystems
by L. Hanisch 24 Jan '11

24 Jan '11

Hi, I get log messages like: ERROR: device 1 supports 7 modulation systems but cDevice::GetDevice() currently only supports 4 delivery systems which should be fixed It's a Satelco EasyWatch (DVB-C): frontend 0/0 provides DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Philips TDA10023 DVB-C") But AvailableBits is 4, MaxNumProvidedSystems computes to 15 and NumProvidedSystems is 7 if I write them with isyslog to the log. Is it a fault of gcc 4.4.3? Has anyone any idea? I just don't know what to do with this... Regards, Lars.

2 2

Re: [vdr] [ANNOUNCE] naludump 0.0.1
by Rolf Ahrenberg 22 Jan '11

22 Jan '11

On Sat, 22 Jan 2011, Udo Richter wrote: > Thought of that too, for a longer perspective. However, what do you > think where to add such a hook ideally? My original idea was to hook in cDevice::Action() as it would bring most flexible setup to blacklist/rewrite pids. However, I forgot the current section mechanism and pat/pmt parsing. > Adding a hook to cDevice::Action would affect all streams, including > transfer mode and streaming etc., but has no known relation between PID > and stream type. Also, there may be several video streams in parallel > here. And I wouldn't consider it good style to provide just filtered > streams for all in any case. Wouldn't stripping NALU fill data help to reduce the required network bandwidth for streamdev, xineliboutput, and vnsi plugins? I do see many benefits using filtered streams everywhere. You could also transcode only certain video/audio pids as the device class know its' transponder/channel parameters. > Adding a hook to cRecorder::Receive() would be nice, as (although not > explicitly specified) the data is received as single TS packets, which > would allow packet dropping easily. Also, the packets can easily be > checked for the (one and only) video PID and video type. However, > Receive() is supposed to return immediately, esp. since its called > within a Lock() of the device. You could simply hook up into the ringbuffer methods used in cRecorder. > A more flexible way would be to add yet another ring buffer between the > receiving buffer and the frame detector, and do the hook between the > buffers. But another buffer will be additional overhead... ..and you already thought about it. :) Anyway, it's up to the plugin how big the overhead will be and it wouldn't hurt when recording. It's up to the user how many recording filters she's going to chain... BR, -- rofa

2 1

Re: [vdr] [ANNOUNCE] naludump 0.0.1
by Rolf Ahrenberg 22 Jan '11

22 Jan '11

On Sat, 22 Jan 2011, Timothy D. Lenz wrote: > Has anyone here every used or seen an STB's rotor support? The one I have is > a first gen Neusat SP-6000. Maybe those of you with the interest in doing it > and programing skill to tackle it have a sat store near by where you can see > one and get a look at the setup functions. OR find a cheap one on ebay. Ask > in the forum at http://www.satelliteguys.us/ for which units are good > examples or for recomendations of options/functions that are useful. Might > even be able to get some screen shots for ref design. Combine the best of has > been done. A lot of those guys have several STB's and have seen/tried many > more. Well, this looks like hijacking a thread, but I'll give my 2 cents anyway. Howabout just polising the current GotoX patch and convince Klaus to merge it into upcoming developer versions. IMO, it should be simple enough for a core feature in both feature and setup wise. BR, -- rofa

1 0

Re: [vdr] [ANNOUNCE] naludump 0.0.1
by Rolf Ahrenberg 22 Jan '11

22 Jan '11

On Fri, 21 Jan 2011, Udo Richter wrote: >> On 01.01.2011 22:29, Udo Richter wrote: >>> Later versions will also integrate into VDR as a patch, and will filter >>> out these fillers while recording. > > I had some issues integrating it properly into the recording function of > VDR, and then ran out of time. But I think I'll find some time this weekend. Howabout just adding a filter API and do the actual job in a plugin - I have some ideas where I could reuse such a mechanism. BR, -- rofa

3 2

[patch] pin & epgsearch plugins compatibility
by jdobry＠centrum.cz 22 Jan '11

22 Jan '11

Hello all, I found that pin & epgsearch plugins are not compatible if it is compiled on 1.7.16 (maybe more versions). Patch for epgsearch-0.9.25.beta18 is in attachment Jiri Dobry

3 3

VDR deleting channels it shouldn't
by Timothy D. Lenz 21 Jan '11

21 Jan '11

Using vdr-1.7.15. 3 of the local networks have duplicate transmitters. 1 is a bit too weak get right now and because of a bug in atsc, I can't rescan right now (crashes vdr, reported in another post). I pulled the entries for the secondary transmitters for two of the networks from the last scan I was able to make a few months ago. Added them back in, but vdr promptly deletes them even though they are on different real channels. Below is the revised conf followed by what vdr did to it. :Locals :@41 KVOA-DT,KVOA-DT:527028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:211:0 :@61 PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0 :@62 V-Me,V-Me:569028615:M10:A:0:65=2:0;68=esl@106,72=esl@106:0:0:2:0:213:0 :@63 CREATE,CREATE:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0 :@91 KGUN-DT,KGUN-DT:189028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:215:0 :@92 MEXI ,MEXI :189028615:M10:A:0:65=2:0;68=esl@106:0:0:4:0:215:0 :@93 COOLTV ,COOLTV :189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0 :@94 KGUN2,KGUN2:485028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:215:0 :@95 Mexi2,Mexi2:485028615:M10:A:0:65=2:0;68=spa@106:0:0:4:0:215:0 :@96 COOLTV2,COOLTV2:485028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0 :@111 KMSB-DT,KMSB:539028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:217:0 :@112 THIS,THIS:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0 :@131 KOLD-DT,KOLD-DT:581028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:219:0 :@132 Weather,Weather:581028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0 :@133 Tube,Tube:581028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0 :@134 KOLD-DT,KOLD-DT:213028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:219:0 :@135 Weather,Weather:213028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0 :@136 Tube,Tube:213028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0 :@181 KTTU-DT,KTTU-DT:503028615:M10:A:0:49=2:0;53=eng@106:0:0:1:0:221:0 :@182 Estrell,Estrell:503028615:M10:A:0:65=2:0;68=esl@106:0:0:2:0:221:0 :@271 PBS HD,PBS HD:557028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:223:0 :@272 KIDS,KIDS:557028615:M10:A:0:65=2:0;68=eng@106,72=fra@106:0:0:2:0:223:0 :@273 WORLD,WORLD:557028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:223:0 :@401 KHRR-40, Telemundo, Tucson, AZ,KHRR-DT:629028615:M10:A:0:49=2:0;52=eng@106,54=fra@106:0:0:3:0:225:0 :@461 Univision,KUVE-DT:665028615:M10:A:0:49=2:0;52=eng@106:0:0:1:0:179:0 :@462 TeleFutura,KFTU-CA:665028615:M10:A:0:65=2:0;68=esl@106:0:0:2:0:179:0 :@581 KWBA-DT,KWBA-DT:653028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:207:0 :@582 LATV,LATV:653028615:M10:A:0:65=2:0;68=esl@106:0:0:4:0:207:0 ----------------------------------------------------------------------- :Locals :@41 KVOA-DT,KVOA-DT:527028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:211:0 :@61 PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0 :@62 V-Me,V-Me:569028615:M10:A:0:65=2:0;68=esl@106,72=esl@106:0:0:2:0:213:0 :@63 CREATE,CREATE:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0 :@91 KGUN-DT,KGUN-DT:189028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:215:0 :@92 MEXI ,MEXI :189028615:M10:A:0:65=2:0;68=esl@106:0:0:4:0:215:0 :@93 COOLTV ,COOLTV :189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0 :@94 :@95 :@96 :@111 KMSB-DT,KMSB:539028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:217:0 :@112 THIS,THIS:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0 :@131 KOLD-DT,KOLD-DT:581028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:219:0 :@132 Weather,Weather:581028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0 :@133 Tube,Tube:581028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0 :@134 :@135 :@136 :@181 KTTU-DT,KTTU-DT:503028615:M10:A:0:49=2:0;53=eng@106:0:0:1:0:221:0 :@182 Estrell,Estrell:503028615:M10:A:0:65=2:0;68=esl@106:0:0:2:0:221:0 :@271 PBS HD,PBS HD:557028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:223:0 :@272 KIDS,KIDS:557028615:M10:A:0:65=2:0;68=eng@106,72=fra@106:0:0:2:0:223:0 :@273 WORLD,WORLD:557028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:223:0 :@401 KHRR-40, Telemundo, Tucson, AZ,KHRR-DT:629028615:M10:A:0:49=2:0;52=eng@106,54=fra@106:0:0:3:0:225:0 :@461 Univision,KUVE-DT:665028615:M10:A:0:49=2:0;52=eng@106:0:0:1:0:179:0 :@462 TeleFutura,KFTU-CA:665028615:M10:A:0:65=2:0;68=esl@106:0:0:2:0:179:0 :@581 KWBA-DT,KWBA-DT:653028615:M10:A:0:49=2:0;52=eng@106:0:0:3:0:207:0 :@582 LATV,LATV:653028615:M10:A:0:65=2:0;68=esl@106:0:0:4:0:207:0

3 5

XBMC vnsi dts/pts errors on ATSC Channel through VDR
by Rob Davis 21 Jan '11

21 Jan '11

Using VDR 1.7.16 and the vnsi plugin, xbmc seems to be struggling to play one particular channel. Unfortunetly, it's the channel I'm doing a temporary admin contract for, so I kind of need to see it. vdr-sxfe plays it OK, but I get too much video stuttering on it, and all other channels play ok on xbmc/vdr. Working at the station, if the problem is there, I have a hope of getting it fixed. Their sister station using the same equipment but on a different frequency and antenna (transmitter) is fine. I get the same symptoms using both OTA (8vsb) and via Comcast QAM256, so am fairly sure the problem is specific to something at the station. The code from demuxer.c (in vnsi plugin) that's being triggered is this: else if(checkTimestamp) { int d = dts + m_epochDTS - m_LastDTS; if (d < 0 || d > 90000) { if (d < -PTS_MASK || d > -PTS_MASK + 180000) { m_badDTS++; if (m_badDTS < 5) { dsyslog("VNSI-Error: DTS discontinuity. DTS = %10lu, last = %10lu", dts, m_LastDTS); } } else { /* DTS wrapped, increase upper bits */ m_epochDTS += PTS_MASK + 1; m_badDTS = 0; } } I get my logs filled with the VNSI-Error, DTS discontinuity. The audio stutters. It appears to be AC-3 Stereo, but may be labelled 5.1? I have audio passthrough to my amp. On another laptop with analog output it seems to stutter in a different way.. I'm fairly happy putting some kind of checking in VDR or VNSI and recompiling if it'll help. I have two ATSC tuners, it happens to both tuners. Thanks Rob

2 3

Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
by Stuart Morris 19 Jan '11

19 Jan '11

--- On Wed, 19/1/11, Niko Mikkilä <nm(a)phnet.fi> wrote: > From: Niko Mikkilä <nm(a)phnet.fi> > Subject: Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2) > To: "VDR Mailing List" <vdr(a)linuxtv.org> > Date: Wednesday, 19 January, 2011, 10:48 > ke, 2011-01-19 kello 10:18 +0000, > Stuart Morris kirjoitti: > > My experience with an nVidia GT220 has been less than > perfect. It can > > perform temporal+spatial+inverse_telecine on HD video > fast enough, but > > my PC gets hot and it truly sucks at 2:2 pulldown > detection. The > > result of this is when viewing progressive video > encoded as interlaced > > field pairs (2:2 pulldown), deinterlacing keeps > cutting in and out > > every second or so, ruining the picture quality. > > I think VDPAU's inverse telecine is only meant for non-even > cadences > like 3:2. Motion-adaptive deinterlacing handles 2:2 pullup > perfectly > well, so try without IVTC. > > > > IMHO the best way to go for a low power HTPC is to > decode in hardware > > e.g. VDPAU, VAAPI, but output interlaced video to your > TV and let the > > TV sort out deinterlacing and inverse telecine. > > Well, flat panel TVs have similar deinterlacing algorithms > as what VDPAU > provides, but it would certainly be a nice alternative. > > > These are the key requirements to achieve interlaced > output: > > > > Get the right modelines for your video card and TV. > Draw interlaced > > fields to your frame buffer at field rate and in the > correct order > > (top field first or bottom field first). When drawing > the field to the > > frame buffer, do not overwrite the previous field > still in the frame > > buffer. Maintain 1:1 vertical scaling (no vertical > scaling), so you > > will need to switch video output to match the source > video height > > (480i, 576i or 1080i). Display the frame buffer at > field rate and > > synchronised to the graphics card vertical sync. > Finally, there is NO > > requirement to synchronise fields, fields are always > displayed in the > > same order they are written to the frame buffer, even > if occasionally > > fields are dropped. > > Interesting. Could you perhaps write full instructions to > some suitable > wiki and post the code that you used to do this? I'm sure > others would > like to try it too. I can provide the simple bit of source code I have used to demonstrate the basic principle. Please see attached.

1 0

Re: [vdr] vdr segfaults with glibc 2.12.2
by gimli 18 Jan '11

18 Jan '11

I'm on Archlinux 32bit and there it works fine. Am 06.01.2011 um 22:19 schrieb scott(a)waye.co.uk: > Funny, I tried to change my system to Archlinux last weekend and had the same problem. I gave up in the end and will try Opensuse 11.3 now. I also tried recompiling glibc from source but it gave the same error. Would be to have a test suite for pthread. Could be a 64bit problem... if I was going to pursue it I would create a test program that made the same call as vdr to submit to the Archlinux guys. > > Sent from my HTC > > ----- Reply message ----- > From: "David Spicer" <azleifel(a)googlemail.com> > Date: Thu, Jan 6, 2011 20:53 > Subject: [vdr] vdr segfaults with glibc 2.12.2 > To: <vdr(a)linuxtv.org> > > Hi, > > I'm not a programmer and I'm not sure where to go with this but I > thought that I'd try here first. I'm running vdr 1.6.0-2 on Arch Linux > x86_64. The Arch glibc package was upgraded from 2.12.1 to 2.12.2 > recently, with associated toolchain package updates. After the upgrade, > vdr started segfaulting when it was run so I recompiled it with > debugging symbols and got the following backtrace from gdb: > > (gdb) bt > #0 0x0000000000000001 in ?? () > #1 0x00000000004f2d06 in ?? () > #2 0x00007fff1bb0269f in ?? () > #3 0x00000000004c2775 in cRwLock::Lock (this=0x72bb40, Write=true, > TimeoutMs=<value optimized out>) at thread.c:163 > #4 0x000000000047d382 in cSchedulesLock::cSchedulesLock > (this=0x7fff1bb0269f, WriteLock=<value optimized out>, TimeoutMs=<value > optimized out>) at epg.c:911 > #5 0x000000000047dd06 in cSchedules::Read (f=0x0) at epg.c:1014 > #6 0x00000000004cc304 in main (argc=<value optimized out>, argv=<value > optimized out>) at vdr.c:604 > > If I've done this properly then problem seems to be with the glibc, > specifically pthread, functions that vdr uses to lock the epg data file > for reading and writing but I have no idea whether the problem is with > the vdr code or with glibc. The only workaround I have at the moment is > to downgrade to glibc 2.12.1, after which vdr works again. > > Can anybody help please? > > TIA, > > David Spicer > > _______________________________________________ > vdr mailing list > vdr(a)linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr January 2011