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 has begun.
hi,
Lauri Tischler writes:
Maybe Xbox running mediacenter as frontend ?
Streaming with xinelibout ?
Does it work? Mediacenter web pages seemed to talk only about
streaming video files through a network filesystem. Perhaps I did
miss that, though.
yours,
Jouni
hi,
I have also currently the responsiveness problem. I have a P4 2.4GHz
which runs at aout 20% load, so it should not be a performance problem.
Currently home-made lirc, vdr-xine and 1.4.1 (and that's why I haven't
reported before you started complaining, as I have not had the energy
to
hi,
Reinhard Nissl writes:
Are you using xine's video output driver xxmc?
yes, I am.
I experience deadlocks with this driver on either nVidia or Via EPIA
hardware. For example, when you replay a recording and press the pause
button: the pause symbol (OSD) will never appear on
hi,
Seppo Ingalsuo writes:
Jouni Karvo wrote:
Earlier I had an ATI GFX card and used XV (with xine) for playback,
and had not this problem. After switching to nVidia GeForce FX 5200,
it started.
I wonder if this would help in xorg.conf Device section
Option UseEvents
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 channels
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,
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 supply
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
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
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 concerned
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 clockspeeds.
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 not
[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 removing
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
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 it makes
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
with a sudo xine, or a su - xine
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 to
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
impaired. Go
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 do
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
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 TV encoder
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.14.12.pkg1.run
It's running perfectly
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
X11 output
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
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.2#
no
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
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
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:
files are created, but with
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´t reallly need
VDR User kirjoitti:
On Thu, May 7, 2009 at 11:38 AM, Jouni Karvo jouni.ka...@iki.fi 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 think it would not break anything
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
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
VDR User kirjoitti:
On Tue, May 12, 2009 at 7:48 AM, Jouni Karvo jouni.ka...@iki.fi 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 video window.
Any idea
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?
Make sure, you use the latest
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
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. Thanks!
yours,
Jouni
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 change the Audio PID number, leading to VDR
re-tuning
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 programme
starts at YLE, they change the Audio PID number, leading
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:
On 24.11.2009 18:28, Jouni Karvo wrote:
Jouni Karvo kirjoitti:
Rolf
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
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 places
about expressions with both
... 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
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
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 178 does not actually fix
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 channel
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.org
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]: noad
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 12:54:58 vdr noad[22790]: noad arg[0]: noad
Mar 18 12:54:58 vdr noad[22790]: noad arg[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.
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 using an
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.
Thanks for the help
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
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.
Thanks for the suggestion
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 Karvojouni.ka...@iki.fi 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
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
X11
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
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
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
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
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.org/cgi-bin
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
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
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
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
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
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
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
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
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
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,
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
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
91 matches
Mail list logo