:·)
:·)
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. …
[View More]That would allow the
rotor to do its job (with the existing diseqc.conf
[View Less]
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 …
[View More]don't know what to do with this...
Regards,
Lars.
[View Less]
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
&…
[View More]gt; 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
[View Less]
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/…
[View More]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
[View Less]
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 …
[View More]such a mechanism.
BR,
--
rofa
[View Less]
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
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.
:…
[View More]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
[View Less]
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) …
[View More]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
[View Less]
--- 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 …
[View More]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.
[View Less]
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 …
[View More]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
[View Less]