Carsten Koch wrote:
martin wrote:
...
go and get yourself a new hard disc :-)
Well, that option is of course always available. ;-)
Let's take a look at my vdr system:
/video df -hT
FilesystemTypeSize Used Avail Use% Mounted on
/dev/hda2 xfs147G 12G 136G 8% /
Norbert Goebel wrote:
Matthias Schniedermeyer wrote:
Not excatly.
I would call it semy-online-storage.
Normaly the HDDs are switched off.
But as they are connected to USB-Power-Switches they can be switched
on/off automatically by the computer.(*)
Hi,
I just got interested
Rainer Zocholl wrote:
[EMAIL PROTECTED](Norbert Goebel) 13.09.06 18:21
Matthias Schniedermeyer wrote:
Not excatly.
I would call it semy-online-storage.
Normaly the HDDs are switched off.
But as they are connected to USB-Power-Switches they can be switched
on/off automatically
Christian Wieninger wrote:
Hi,
for a new feature of epgsearch, I'd like to do a continuous check (in a
separate thread) if any timer was deleted via OSD or SVDRP since the
last check.
The only thing I found so far is to build a timer array and compare it
at each check with the current
Christian Wieninger wrote:
Hi,
Matthias Schniedermeyer wrote:
Does epgsearch save any status from epg-data and/or timers?
yes, but the 'done' approach is currently different: epgsearch marks and
saves a broadcast as done only if it has been successfully and
That wasn't what i meant
Darren Wilkinson wrote:
Matthias Schniedermeyer wrote:
Video is inherently bandwith intensive.
At least (for PAL):
720x576x4x25 = about 40MB/s (*)
1920x1080x4x25 = about 200MB/s
And that's taking aside ANY of the other processing. Decoding, IDCT,
YUV-RGB transformation and so on. Also
Pasi Juppo wrote:
Matthias Schniedermeyer wrote:
Clemens Kirchgatterer wrote:
Matthias Schniedermeyer [EMAIL PROTECTED] wrote:
I'd say the only downside of the Linux support kills it as a VDR
platform. Graphic is NOT accelerated.
That's the only downside i'm aware of, and i can understand
Klaus Schmidinger wrote:
Heikki Manninen wrote:
On su, 2007-01-14 at 14:48 +0100, Klaus Schmidinger wrote:
Your CAM doesn't respond to the QUERY that VDR sends to it.
So VDR can't ask the CAM whether it is able to decrypt a certain
channel (in addition to others it is already decrypting).
So
Stefan Huelswitt wrote:
Hi,
I'm playing around with 1.5.0
Initialy I wasn't able to tune to any channel. Even for FTA vdr
kept saying not available.
It took me nearly an hour to find the reason for that:
I had set PrimaryLimit=20
I have this setting since ages, but cannot say why anymore.
Hi
I have recently updated from VDR 1.2.6 to 1.4.6
I have the problem that once VDR emergency exists, for whatever reason,
it never gets the recording started again in time, so it emergency
exists again and again until the recording has ended.
If i manually disable the timer, wait a few seconds
Matthias Schniedermeyer wrote:
Hi
Added note: It is an encrypted channel and the CAM-found-message always
appears a few seconds after VDR started, but before VDR tunes the
channel and starts the timer. A few seconds later a:
Ups.
This must read: AFTER VDR tunes the channel and starts
On 01.07.2007 19:40, Georg Acher wrote:
On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote:
or better or whatever. cool, no problem. what? you signed a NDA that
does not allow you distribute the os in the first place? your bad.
Once again, and now in capitals.
IT'S
On 01.07.2007 21:10, Georg Acher wrote:
On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote:
If only the hardware vendors where as united as the movie-industry.
HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and
HDMI. As long as they can sell
Bernd Juraschek wrote:
Hello list,
I want to do some kind of offline modifying vdr timers, but I don't know
how to identify timers.
If I use the timer id to change or delete VDR timers, then this will go
wrong if VDR has deleted some timers since the remote site has retrieved
the timer
On 18.11.2007 17:01, Klaus Schmidinger wrote:
Maybe it actually is about time for me to build a new VDR.
I'll probably take a look at the Reel Extension HD PCI.
But that means I'll also need a new motherboard with at least
five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD).
On
On 15.01.2008 09:35, Magnus Hörlin wrote:
I'm sorry for bothering you with a question that should possibly have been
sent to the mplayer mailing list.
Next week I'm going to Tenerife to relax by the pool, but I don't want to
miss any biathlon, alpine- or cross-country skiing transmissions,
On 03.02.2008 11:17, Klaus Schmidinger wrote:
So, here's the straw poll:
Should there be a stable version 1.6.0 now, based on what's in
version 1.5.14, but without DVB-S2 or even H.264 support?
Is the CAM Handling regarding multiple parallel recodings (on the same
channel) fixed?
I
On 03.02.2008 12:17, Klaus Schmidinger wrote:
On 02/03/08 12:06, Matthias Schniedermeyer wrote:
On 03.02.2008 11:17, Klaus Schmidinger wrote:
So, here's the straw poll:
Should there be a stable version 1.6.0 now, based on what's in
version 1.5.14, but without DVB-S2 or even H.264
On 16.03.2008 17:55, Florian Gleixner wrote:
Hi,
i use dvbcut to cut my recordings. After cutting i can rename the
resulting mpg file to 001.vdr, delete the index file and run genindex
and then i have a perfect cutted recording. This works well for all
recordings that are smaller than 2GB.
On 16.03.2008 22:20, Florian Gleixner wrote:
Matthias Schniedermeyer wrote:
On 16.03.2008 17:55, Florian Gleixner wrote:
Hi,
i use dvbcut to cut my recordings. After cutting i can rename the
resulting mpg file to 001.vdr, delete the index file and run genindex
and then i have
On 16.03.2008 22:55, Florian Gleixner wrote:
Matthias Schniedermeyer wrote:
For me personally playbackability with VDR was never a priority.
I've been using VDR for recording since Oktober 2000, back then i had to
write my own cutting scripts, since VDR didn't had the cutting
On 04.01.2009 11:55, Klaus Schmidinger wrote:
Up to now VDR has used names like 001.vdr for its recording files.
While moving to Transport Stream as the recording format, I need to
use a different file name extension, and so was wondering which one
to use. My first idea was *.ts, for Transport
On 04.01.2009 22:34, Klaus Schmidinger wrote:
On 04.01.2009 19:21, Nicolas Huillard wrote:
Klaus Schmidinger a écrit :
Up to now VDR has used names like 001.vdr for its recording files.
While moving to Transport Stream as the recording format, I need to
use a different file name
On 27.12.2012 13:21, VDR User wrote:
On Thu, Dec 27, 2012 at 10:20 AM, fnu v...@auktion.hostingkunde.de wrote:
... there are way too much changes at the moment :)
FullAck, but the number of changes are not the issue, it's more the
sustainability and the time frame within the changes.
On 27.12.2012 16:55, VDR User wrote:
Matthias Schniedermeyer:
Pointing out that the last stable release of VDR having an old
timestamp has nothing to do with people _choosing_ to use the
developer version, which is warned and well-known to possibly contain
changes that will cause problems
On 10.03.2013 20:40, Peter Münster wrote:
On Sun, Mar 10 2013, fnu wrote:
But to change it in a global way like this is IMHO not a way to go.
Did you understand my suggestion? Here again: not writable: warning, not
readable: exit. Is that a problem for real-life systems?
For most people
On 13.03.2013 11:44, Michael Frank wrote:
Hello,
I'm not sure whether this is a bug or an intended feature:
When using an SVDRP command the result displayed always lacks the
hyphen in the last line, e.g. lstc returns
250-2609 Canvas (MPEG4);TV
27 matches
Mail list logo