On 13.09.2011 14:16, Chris Rankin wrote:
Hi,
Just in case anyone is interested:
There has been a sudden spike in xine development (1.1.19 branch), and
AAC LATM audio should now be working with MPEG-TS streams. You will
also need to be using FFmpeg >= 0.7.
Where can that be found? The repos
On 15.01.2012 22:46, Udo Richter wrote:
Hi list,
And here I was, thinking that I could finally drop support for this old
compatibility patch that noone really needs any more, and then the new
VDR-1.7.23 requires linux-3.0 or newer headers to compile... yay...
Hi, I have a self compiled 3.2.1-S
On 16.01.2012 20:47, Jouni Karvo wrote:
Hi, I have a self compiled 3.2.1-SMP kernel in Debian:
Never mind - I found the instructions in the "HISTORY" file.
yours,
Jouni
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.o
hi,
it seems xine-plugin 0.9.4 does not compile with vdr 1.7.27.
yours,
Jouni
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
hi,
since starting to use a AV receiver between TV and VDR, I have had HDMI
detection problems.
To start X server even when TV is not on, I use custom edid file that I
got from the tuner. With this, VDR always starts X properly, so even if
VDR has auto-started for recording, the output work
On 28.07.2012 18:14, VDR User wrote:
HDMI in. That's all. How is your setup cabled? I've heard a similar
story before and it turned out to be a quirky receiver but I can't say
if NAD has that problem or not.
VDR-(HDMI)-Receiver-(HDMI)-TV
yours,
Jouni
_
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of
coulours, it is weird to have them in a different order on the OSD and
in the remote. Plus the skip 1min forwards and 1min backwards during a
repl
On 12.08.2012 15:46, JJussi wrote:
On 12.8.2012 15.32, Klaus Schmidinger wrote:
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of
coulours, it is weird to
hi,
earlier, I used to compile lirc separately, but nowadays there are lirc
modules in the kernel source, using /dev/input and IR keymaps. After
switching to these, it seems many of the buttons in the remote have
stopped working, as they are now interpreted as keyboard presses instead
of RC c
Thanks for the suggestions.
On 18.10.2012 00:05, Tony Houghton wrote:
I prefer inputlirc to the original lirc. If you configure it to start
at boot and grab the input device it should stop X or whatever from
interpreting it as key presses.
It seems easy, but when I moved to inputlirc, now I h
On 20.10.2012 15:18, Tony Houghton wrote:
Strange. FWIW I used to use the Hauppauge "grey" remote, but I
replaced that card and none of my other receivers came with suitable
remotes (not enough buttons etc) so I bought an HP MCE remote and
cheap generic MCE receiver
With a bit of fiddling and
an additional problem is the definition of "viewed". I don't normally
view the end credits. Also, I have normally 10min extra in the end of
each recording, just in case. So normally there are around 10-15mins in
the end of a viewed recording that have not been viewed. But this would
proba
hi,
I updated from 1.7.32 to 1.7.41. It seems fine, but for some reason vdr
does not find locales any more:
locale -a | wc
537 5375097
locale -a | grep fi
fi_FI
fi_FI@euro
fi_FI.iso88591
fi_FI.iso885915@euro
fi_FI.utf8
fil_PH
fil_PH.utf8
finnish
and the syslog:
Mar 17 09:50:31 v
17.03.2013 12:37, Klaus Schmidinger kirjoitti:
On 17.03.2013 10:57, Halim Sahin wrote:
Hi,
I see locale problems as well.
I've used LCLBLD and no locales were installed in ./locale after make
run.
I typed "make i18n" which helped.
I just verified that a plain 'make' does generate the ./locale
vdr 2.1.6 (self-compiled) with vdr-xine-0.9.4 plugin and debians
packaged libxine2 shows YLE HD subtitles fine.
yours,
Jouni
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 09.03.2015 16:31, VDR User wrote:
> Have you tried compiling the sources yourself? It'll probably take a
> while but as long as no voodoo/magic is required, I don't see why not.
I am in the process. Using the instructions from
http://www.vdr-wiki.de/wiki/index.php/Kategorie:Raspbian_VDR_Stre
hi,
I have the following problem:
when pressing "menu" with my Raspberry pi Lirc, VDR crashes:
Mar 31 13:51:09 vdrfe vdr: [2456] rpihddevice: [OpenVG] cannot allocate
pixmap of 2804px x 781px, clipped to 2048px x 781px!
Mar 31 13:51:09 vdrfe vdr: [2469] rpihddevice: [EGL] failed to create
pix
hi,
01.04.2015, 22:47, Thomas Reufer kirjoitti:
There was a bug in git which is now fixed. Sorry for the
inconvenience! But in general, this could happen if there's not enough
GPU memory available, so the skin should check for a valid pixmap. For
the next developer version of vdr, It also need
hi,
I have a Raspberry Pi frontend (vdr 2.2.0) with a server (vdr 2.0.6 from
yavdr). Last night the disk was full, and vdr started to remove old
recordings.
For some reason, they did not remove just enough to fit in the new
recordings, but cleared about 2TB of old recordings. Earlier, (wi
17.02.2016, 23:14, Harald Milz kirjoitti:
Question: has anyone successfully run vdr-2.0.3 or -2.2.0 with the 4.2.0
kernel using a PCIe card? And while we're at it, a PCIe USB3 card with a
harddisk attached? It seems that some kernel buffer starts choking after,
like, 150 or more GB have been tran
hi,
I just upgraded my RPI raspbian packages, running vdr 2.2.0 and
vdr-plugin-rpihddevice (latest git). I did not upgrade the actual VDR
and its plugins.
For some reason, now MPEG2-encoded channels are not shown properly any
more; the video is just noise, mostly green, some purple. Audio
Klaus Schmidinger kirjoitti 17.01.2018 klo 11:59:
On 16.01.2018 19:44, Teemu Suikki wrote:
Hi,
I just experienced weird problem. My hard drive became 100% full.
...
This is somehow related to the fact that I now have Plex Media Server
sitting on the VDR recordings directory. But still I cou
hi,
Stone writes:
> With this modification to dvbdevice.c, I wonder if VDR will still crash
> when a timer goes off on a channel and all the sudden it becomes encrypted.
> This would normally cause a broken data stream and VDR would do an emergency
> exit.
I gave up recording encrypted chann
hi,
Reinhard Nissl writes:
> it will take 37000+ ms until VDR receives the stream. In the case of a
> recording, this is simply to long as recorder.c defines a
> MAXBROKENTIMEOUT of 30 seconds. VDR's recorder considers a stream to be
> broken when it doesn't receive a PES packet for that tim
hi,
I agree this is a off-topic... (but I hope on topic for the mailing
list anyway)
Reinhard Nissl writes:
> The use of MAXBROKENTIMEOUT is a last resort of getting a recording
> recorded when for example the driver or hardware is in a state where
> only reloading the driver can help out of
hi,
as the kernel finally supports standby or spin down or whatever mode
for my SATA disks, I have set up an aggressive scheme trying to spin
down disks whenever possible. The results: 2 degrees drop in case
temperature and a significantly lower noise. And a playout "problem"...
It takes about
hi,
Reinhard Nissl writes:
>
> I don't think that this is a matter of vdr-xine but at least it looks
> like there is a simple solution in xine regarding the annoying pause:
> try to increase
>
> engine.buffers.audio_num_buffers
>
> and
>
> engine.buffers.video_num_buffers
hi,
Reinhard Nissl writes:
> If you show the recording's progress menu and switch to play (after a
> jump to a cutting mark), you'll see that the progress bar advances very
> quickly by 10 seconds, as VDR sends the recording data as fast as
> possible (i. e. as fast as your harddisk can suppl
hi,
Sébastien Serra writes:
> When DRI is loaded and 3D acceleration is ON my X server quickly
> freezes. My log (using ssh) tells me something like
Video does not use 3D acceleration, but it does need dri/drm. So you
should check that MTRR and DRI/DRM (I don't remember which - "direct
render
hi,
Steffen Barszus writes:
> Shouldn't it be enough to do not sprecify -w option ? :
>
> -w SEC, --watchdog=SEC activate the watchdog timer with a timeout of SEC
>seconds (default: 0); '0' disables the watchdog
The problem is that the watchdog timer is able
Udo Richter writes:
> into my VDR, as it saved many recordings for me. This fallback is only
> triggered if a scheduled recording is getting not a single byte of data
> for at least one minute, so there's IMHO something seriously wrong about
Such as CA authorization needing refreshing, and
hi,
martin writes:
>
> Emergency Exit _is_ needed in case you have: a FullFeatured and/or CAM
> system
I think the opposite - EmergencyExit is bad in case of CAM.
If I understood the mails correctly, emergency exit is only needed for
TT FF cards - and there especially for DVB-S.
Tero's sc
Stone writes:
> >
> > It still wouldn't surprise me if this version caused a few overflows,
> > but hopefully these will be very rare.
>
> I'm curious how streamdev will function with these buffer changes.
And since I am not convinced that this memory footprint issue is
significant, I am co
hi,
Josce Unknown writes:
> Well if the PC clock was correct all the time I would probably not have
> to use the set time function :)
Yes, but typically PC HW clock does not drift so much. You could use
hwclock --systohc (and possibly --utc or --localtime) after letting
the vdr to set the s
hi,
covert covert writes:
> About to step into the deep end and build my first VDR box. In fact 2
> of them at the same time both with the exact same specs.
>
> All parts are going to be new.
>
> New CPU's are a lot more confusing than the simple days of single
> cores at fixed clockspe
VDR User wrote:
> I like these ideas... NO SIGNAL image in recording during no signal.
> Or that if no signal then no writing to disk. And a warning in the
> log about a possible incomplete recording cuz of lost signal +
> identified in recordings menu by a special char like ? maybe.
>
I do no
[EMAIL PROTECTED] wrote:
> How does that sound?
Complicated. And you did not even consider cases such as: The card is
receiving perfectly another channel on the same mux, so tuning to
another mux would not be an option. Although it is easy to add
conditions like this to the code, it would mean
[EMAIL PROTECTED] wrote:
>>> How does that sound?
>
>> Complicated. And you did not even consider cases such as:
...
> Because I've seen this restart cycle many times, and only way
> out of it is editing via [your favorite editor] the timers.conf
> file.
I have seen the problem too. Just remov
Antti Seppälä kirjoitti:
> Hello VDR community
>
> Iptv plugin developers are pleased to announce a release of vdr-iptv
> plugin version 0.0.3. This time the plugin includes a couple of bug
I see you are already in version 0.0.5
I'd like to try this out - do you know any free channels in the net
Segers,Jan J.K.T. kirjoitti:
> have a look here:
> http://www.global-itv.com/
thanks. I found a couple of channels.
It seems that vlc is able to play the stream correctly, with both audio
and video by itself. But when I try to use it together with iptv
plugin, it seems that for some reason au
Antti Seppälä kirjoitti:
> I decided to give Bahn TV a try and could also reproduce symptoms of
> missing audio.
>
> It seems that the transcoding engine of vlc gets confused by the audio
> bitrate setting iptv plugin uses by default. So far I haven't found
> other channels than Bahn TV that are
hi,
I am baffled...
Antti Seppälä kirjoitti:
> Set up a vlc for transcoding in a similar fashion as to how iptv plugin
>
> Now open another instance of vlc to play back the transcoded stream:
>
> vlc udp://@:4321
works
> If the stream works perfectly, you can close the playback vlc and try to
Ville Skyttä kirjoitti:
> On Tuesday 22 January 2008, Darren Salt wrote:
>> This patch should fix it. If you find that it works, report back and I'll
>> make sure that it gets committed.
>
> I'm not using any xine related functionality with VDR, but I tried the patch
> below.
>
> Unfortunately i
Morfsta kirjoitti:
> On Feb 7, 2008 4:27 PM, Jouni Karvo <[EMAIL PROTECTED]> wrote:
>
>> The --stdctl option causes xine to crash if it is used when starting
>> from the script...
>>
> Someone advised me of a workaround, you can use the startup script
> wit
hi,
I found the problem actually right after sending the email (but it is
still a bug in xine):
> XINECMD="$XINEPRG -L -A alsa -a spdif --no-splash -g -f -V xv --stdctl
> vdr://tmp/vdr-xine/stream#demux:mpeg_pes --post vdr_video --post
> vdr_audio --verbose=2"
The --stdctl option causes xine
hi,
I tried to upgrade to xine-lib 1.2 from mercurial.
Now I have a weird problem (that does not go away even if I downgrade
back to 1.1-xine-lib)
- When I start xine from the startup scripts, it segfaults:
This is the command:
XINEPRG="/usr/local/bin/xine"
XINECMD="$XINEPRG -L -A alsa -a spd
Klaus Schmidinger kirjoitti:
> However, there still would be the problem that VDR couldn't even tell
> that the "dut" track is "for the hard of hearing", because it is not
> properly marked.
>
> Or am I missing something here?
>
I think you are right - YLE uses "dut" for a synonym of "hearing
i
Ian Bates wrote:
> One more remark, if as I believe from the comments in the code above,
> that the '16:9 crop to 4:3' behaviour is not implemented in
> xineliboutput, am I the only one suffering from the lack of this
> feature? Am I the only one still using a 4:3 TV? I don't think so,
> what
hi,
Oliver Joa wrote:
> Hi,
>
> i recently upgraded my vdr to version 1.6.0. Now my vdr restarts every
> some minutes when recording:
If it only happens when recording encrypted channels, but not when live
viewing, then it can be a problem of too short a timeout.
At some point I had such a pr
hi,
with NVIDIA driver 169 and 173 at least, this does not yet work:
Thomas Hilber kirjoitti:
>
> I just use one big hammer instead:)
>
> Option "UseEDID" "FALSE"
>
> That works (mostly).
>
And the reason is easily read from the driver's README:
Because these TV modes only depend on the
hi,
Thomas Hilber wrote:
> On Mon, Aug 11, 2008 at 07:40:15PM +0300, Jouni Karvo wrote:
>
>> with NVIDIA driver 169 and 173 at least, this does not yet work:
>>
>
> I cannot confirm that. I just downloaded and installed most recent
>
> NVIDIA-Linux-x86-173.1
> On Wed, Aug 13, 2008 at 09:09:45PM +0100, Gavin Hamill wrote:
>
>
>> So, I started looking for other reasons. Whilst X + vdr are running, the
>> Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU
>> usage is 32%, with 16% for user processes. I thought maybe it was using
>>
Petri Helin wrote:
> really causes VDR to not start also. My aim really was to start some
> discussion on whether that should be changed. I myself think that VDR
> should start although some plugin fails to start. I'd hate to find out
> that some timed recording failed because the lcd display of
hi,
I just compiled the hg xine-lib 1.2 with SVN ffmpeg. In case someone is
interested in the same, these are the options required for xine-lib:
./autogen.sh --with-external-ffmpeg
CPPFLAGS="-I/usr/local/include/libavcodec
-I/usr/local/include/libavdevice -I/usr/local/include/libavformat
-I/usr
Goga777 kirjoitti:
>> I just compiled the hg xine-lib 1.2 with SVN ffmpeg. In case someone is
>> interested in the same, these are the options required for xine-lib:
>>
>> ./autogen.sh --with-external-ffmpeg
>>
>
> /usr/src/xine-lib-1.2# ./configure --help | grep ffmpeg
> /usr/src/xine-lib-1.
LinHai kirjoitti:
> when I first compile xine-lib is OK，second compile ffmpeg is OK.
>
> IF I first compile ffmpeg is OK，second compile xine-lib is failure.
>
> the syslog:
>
> make[2]: *** [xineplug_decode_faad_la-xine_faad_decoder.lo] Error 1
>
> make[2]: Leaving directory `/root/xine-lib-1-2-926
LinHai kirjoitti:
> I apt-get install libfaad-dev,but the log:
Please include also the error messages, not only the report of make
quitting. It is difficult to help if you do not give enough information.
yours,
Jouni
___
vdr mailing list
vdr@linuxtv.o
Klaus Schmidinger kirjoitti:
> On 23.03.2009 22:13, Klaus Schmidinger wrote:
>
>> On 23.03.2009 21:42, Niedermeier Günter wrote:
>>
Here's a quick shot - totally untested (no time, sorry).
Please try it and let me know if it helps.
>>> Hi,
>>>
>>> I've tried it:
>>>
Frank Scherthan kirjoitti:
> Hi there :)
>
> marti...@embl.de schrieb:
>
>> Well, keeping the remote control away from my kids is not easy unless I han
>> g it
>> from the ceiling.
>>
>> Is there some way I can disable live tv pausing all together?
>>
>> It is causing a lot of trouble and I don´
VDR User kirjoitti:
> On Thu, May 7, 2009 at 11:38 AM, Jouni Karvo wrote:
>
>> I'd be pleased, if there would be some kind of a caretaking, so that the
>> "pause-live-tv" recording would just disappear after returning to other
>> modes of operation. I th
hi,
I decided to upgrade after about two years with an old, stable(ish)
version.
I installed vdr-1.7.7, yaepghd patch, and osdteletext. For some reason,
I don't seem to get any data to the teletext pages. The /vtx directory
also stays empty. Any ideas on how to debug or what to do?
I did not
hi,
I am using yaepghd + vdr-xine 9.2. The small window showing the current
channel does not scale the video down, but only shows a small fraction
of the normal-sized video window.
Any idea on how to make the video scale for the window?
I run xine with this command:
/usr/local/bin/xine
-Dtvtim
VDR User kirjoitti:
> On Tue, May 12, 2009 at 7:48 AM, Jouni Karvo wrote:
>
>> hi,
>>
>> I am using yaepghd + vdr-xine 9.2. The small window showing the current
>> channel does not scale the video down, but only shows a small fraction
>> of the normal-sized
Tobi kirjoitti:
> Jouni Karvo wrote:
>
>
>
>> I installed vdr-1.7.7, yaepghd patch, and osdteletext. For some reason,
>> I don't seem to get any data to the teletext pages. The /vtx directory
>> also stays empty. Any ideas on how to debug or what to do?
hi,
Now having some experiences with vdr-1.7.7. It seems subtitles are OK
in live view, and with new recordings.
But when viewing recordings made with 1.5.7 (my previous version), the
subtitles are shown much too early. It seems they appear right after
the previous text should be shown, are ke
hi,
I have the following problem:
When live viewing with 1.7.9 and vdr-xine 0.9.3, this channel (in cable)
is shown properly:
TV7;HTV:386:M128:C:6900:800+802=2:801=fin:0:0:61500:42249:16:0
If I try to record anything, vdr restarts constantly, and the recording
is of zero length.
The output
Jouni Karvo kirjoitti:
> hi,
>
> I have the following problem:
>
> When live viewing with 1.7.9 and vdr-xine 0.9.3, this channel (in cable)
> is shown properly:
> TV7;HTV:386:M128:C:6900:800+802=2:801=fin:0:0:61500:42249:16:0
>
>
vdr-1.7.10 seems to fix this. T
hi,
is there somewhere a patch that would remove the break when the
broadcaster uses "dynamic pids" (such as YLE). Now, when a programme
starts at YLE, they change the Audio PID number, leading to VDR
re-tuning or something, that leads to a 1-2s break in the show. There is
no change in frequency
Klaus Schmidinger kirjoitti:
> On 23.11.2009 18:36, Jouni Karvo wrote:
>
>> hi,
>>
>> is there somewhere a patch that would remove the break when the
>> broadcaster uses "dynamic pids" (such as YLE). Now, when a programme
>> starts at YLE, they cha
Rolf Ahrenberg kirjoitti:
> On Mon, 23 Nov 2009, Jouni Karvo wrote:
>
>> is there somewhere a patch that would remove the break when the
>> broadcaster uses "dynamic pids" (such as YLE). Now, when a programme
>> starts at YLE, they change the Audio PID numb
Jouni Karvo kirjoitti:
> Rolf Ahrenberg kirjoitti:
>
>> On Mon, 23 Nov 2009, Jouni Karvo wrote:
>>
>>
>>> is there somewhere a patch that would remove the break when the
>>> broadcaster uses "dynamic pids" (such as YLE). Now, when a pr
Klaus Schmidinger kirjoitti:
> On 24.11.2009 22:38, Anssi Hannula wrote:
>
>> Klaus Schmidinger wrote:
>>
>>> On 24.11.2009 19:22, Anssi Hannula wrote:
>>>
>>>> Klaus Schmidinger wrote:
>>>>
>>>>>
hi,
I just turned to 64bit, and it seems vdr dumps core there...
compiled with g++-4.3
command line:
`./vdr-prod -u vdr -w 60 -P xine -v /video0 -c /video0 --userdump -l 3'
log content (end of log):
Script done on Mon 25 Jan 2010 07:28:00 PM EET
Jan 25 19:26:20 vdr vdr: [-1] channel 1 (TV1)
Jouni Karvo kirjoitti:
> hi,
>
> I just turned to 64bit, and it seems vdr dumps core there...
>
> compiled with g++-4.3
>
>
answering to myself. Compiling with g++-4.1 removes the segmentation fault.
I don't know whether this is related, but g++-4.3 warns in many pla
Jouni Karvo kirjoitti:
> Jouni Karvo kirjoitti:
>
>> hi,
>>
>> I just turned to 64bit, and it seems vdr dumps core there...
>>
>> compiled with g++-4.3
>>
>>
>>
> answering to myself. Compiling with g++-4.1 removes the segmentati
... and here the backtrace without -O2, if it helps more...
#0 0x004717be in cHashObject::Object (this=0x41) at tools.h:525
525 cListObject *Object(void) { return object; }
(gdb) bt
#0 0x004717be in cHashObject::Object (this=0x41) at tools.h:525
#1 0x00470153 in cChannels:
hi,
Reinhard Nissl kirjoitti:
>
> This doesn't look like a vdr-xine issue.
>
>
Indeed not.
It just occurred to me that even though I had not started other plugins,
there was the yaepghd patch included. I removed that, and it seems now
the segmentation fault is gone. (for a few minutes at l
hi,
Reinhard Nissl kirjoitti:
> Please report the logged error message.
>
Actually, your patch immediately segfaulted.
But I can see some problem: The include files from the distro tell me:
k...@vdr:/usr/include$ grep __NR_gettid */*
asm/unistd_32.h:#define __NR_gettid224
asm/unistd
Jouni Karvo kirjoitti:
>
> So it seems the syscall numbers have changed at some point. I am afraid
> if the libc is now broken due to this. This has not happened to me
> before, so I don't actually know what would be the good thing to do.
> But forcing the syscall number to 1
I have a similar problem - for some reason VDSB without a real explanation.
Markus Fritsche kirjoitti:
> Hello All,
>
> The issue was not related to USB whatsoever - my channels.conf was the issue.
>
> I created it with "scan" from the dvb-utils package. Turns out that
> "scan -o vdr" outputs the
Markus Fritsche kirjoitti:
> I am using v1.6.0 (which came with Ubuntu) - is it outdated?
>
>
Ah. I guess not - my bad. The latest development version is 1.7.12,
and I made a wrong assumption.
yours,
Jouni
___
vdr mailing list
vdr@linuxtv.o
the Noad kirjoitti:
> Hi,
>
> there is a new version of noad at
>
> http://noad.heliohost.org
>
> This Version handles also TS-Recordings.
>
A couple of problems:
Mar 18 12:54:58 vdr noad[22790]: noad arg[0]: noad
Mar 18 12:54:58 vdr noad[22790]: noad arg[1]: -
Mar 18 12:54:58 vdr noad[22790]:
Jouni Karvo kirjoitti:
> the Noad kirjoitti:
>
>> Hi,
>>
>> there is a new version of noad at
>>
>> http://noad.heliohost.org
>>
>> This Version handles also TS-Recordings.
>>
>>
> A couple of problems:
>
> Mar 18 1
hi,
since I updated from vdr-1.7.11, there is some change in the way H.264
is treated:
With 1.7.11 + xine with vdpau support, I can watch H.264 "HDTV" shows
without problems. Occasionally, there is a small glitch.
But with 1.7.14 + the same version of xine, H.264 (both SDTV and HDTV)
fail. Sy
Luca Olivetti kirjoitti:
> En/na Reinhard Nissl ha escrit:
>>
>> Since 1.7.12, VDR records PCR. Please apply the patch found in
>> the below link to vdr-xine-0.9.3:
>>
>> http://www.linuxtv.org/pipermail/vdr/2010-February/022368.html
>
> It doesn't happen with all channels, though, I'm currently us
hi,
I have Nvidia GT220, with xine-lib-1.2 from today.
I have been struggling with the deinterlacing of HD content, with no
success.
My current settings in .xine/config (which I found by reading the source
code - is there any documentation anywhere?):
video.output.vdpau_honor_progressive:1
On 12.06.2010 20:59, István Füley wrote:
Jouni Karvo wrote:
video.output.vdpau_honor_progressive:1
Try to change it back to 0.
Ah. Seems you are right - the problem is in the broadcast. I sent an
"improvement suggestion", let's see whether they bother to respond.
Than
On 15.06.2010 11:20, István Füley wrote:
Glad to hear, that you managed to fix it. I don't think that the
broadcaster will care about it :(
How the GT220 is working with vdpau? Is the temporal_spatial
deinterlacing working without freezes or dropped frames?
I'm thinking about buying a similar ca
On 25.07.2010 21:14, Antti Ajanki wrote:
Hi,
I just released version 0.3.1 of the webvideo plugin. The new version
fixes (among other things) the incompability that was caused by
Youtube recently changing their output format.
Hi; a feature request:
- could you add a method for deleting the
On 04.08.2010 22:00, Antti Ajanki wrote:
On 08/03/2010 11:58 AM, Jouni Karvo wrote:
Hi; a feature request:
- could you add a method for deleting the downloaded video files?
I would find this most useful - having to take a ssh connection to the
HTPC for deleting files is a bit cumbersome
On 27.08.2010 20:44, Antti Ajanki wrote:
New version of the Webvideo plugin is available at
http://users.tkk.fi/~aajanki/vdr/webvideo/
Tried compiling with vdr 1.7.15. Does not work, because the "vdr"
include directory is under "include", not where the sources are.
May I suggest adding a
On 11.09.2010 18:45, Rolf Ahrenberg wrote:
On Sat, 11 Sep 2010, Antti Ajanki wrote:
On 09/11/2010 01:44 PM, Jouni Karvo wrote:
May I suggest adding a VDRINCLUDEDIR variable, and -I option, and
removing the "vdr/" from the #include statements in the future
versions.
Than
I don't understand what would be easy in using SQL. Since the
channels.conf-code is already there,
and pretty stable, then obviously rewriting that to SQL is not "easy",
but instead additional work.
Justifying additional work needs some reason.
I think adding dependencies to outside packages
hi,
after upgrading my kernel to 2.6.37 SMP PREEMPT x86_64 and switching to
the in-kernel lirc devinput drivers, I have had vdr startup problems.
At some boots; typically when the system wakes up from sleep, either by
RTC or by power key from the remote, VDR watchdog-restarts every 1
minute
On 16.02.2011 20:36, VDR User wrote:
On Wed, Feb 16, 2011 at 6:48 AM, Jouni Karvo wrote:
I don't know where to start. Is this a vdr, lirc or a driver problem, or
perhaps initscript order problem? Should I try the 2.6.38-rc5, or would
that be just looking for trouble?
Check the VDR lo
On 17.03.2011 00:12, Reinhard Nissl wrote:
Hi,
Am 16.03.2011 20:29, schrieb Reinhard Nissl:
- Added support for VDR-1.7.17s TrueColor OSD.
I forgot to mention, that TrueColor OSD is currently only possible
with VDPAU.
Furthermore you have to select an "OSD display mode" different from
"X
On 17.03.2011 18:21, Jouni Karvo wrote:
Thanks for the update. Seems so far to work nicely. The INSTALL file
points to the jusst.de tree, but I thought that the libxine-1.2 is now
at the xine-project mercurial (where, it seems, are some changes by
you :)
This vdr-xine, combined with
On 18.03.2011 21:18, Jouni Karvo wrote:
On 17.03.2011 18:21, Jouni Karvo wrote:
Thanks for the update. Seems so far to work nicely. The INSTALL
file points to the jusst.de tree, but I thought that the libxine-1.2
is now at the xine-project mercurial (where, it seems, are some
changes by
hi,
Klaus Schmidinger writes:
> Lauri Tischler wrote:
> > I seem to remember that there was a patch to prevent stopping and
> > starting recording
> > if audio-pid changes.
> > Was there ?
<...>
> ...but the audio pids are set up at 20:50:18, which is 6 (six!)
> seconds after the show
hi,
Anssi Hannula writes:
>
> Note that in Lauri's case the language PIDs *do* change, not just the
> language codes.
Ah, so this is the fancy "dynamic pid" effect. They remove one
stream. Although, if the removed "program" is not recorded, there
should be no reason to restart. (other than
1 - 100 of 106 matches
Mail list logo
