Hi list,
I've updated the runvdr extreme script to version 0.3.
The new version adds some distribution-like comfort to plugin
management, by managing whole directories of configuration files. A new
script, runvdr-conf.d, can be used to manage symbolic links in
/etc/runvdr/conf.d/ for differen
Klaus Schmidinger wrote:
> Users in Germany should please test this, too, and do an
>
> export VDR_CHARSET_OVERRIDE=ISO-8859-9
>
> before starting VDR.
In case we do head for a single override option, wouldn't it be more
consistent to do this with a command line option instead of an
environmen
Joerg Pulz wrote:
> What do you think why we have tools like pkg-config or autotools and so
> many projects make use of it? Because its funny? I don't think so!
>
> What's the big deal with Villa's proposal to change two lines in the
> Makefile when it breaks nothing for you and makes life easie
Timothy D. Lenz wrote:
> which, but not all, will be shut down in a year. For ATSC .1 is the primary
> channel and .2, .3, etc are the sub channels. The "#" on the remote could
> be used for the "." In the channels.conf an ATSC next channel number would
> look like:
> :@13.1
Well, at least I've n
Clemens Kirchgatterer wrote:
> pkg-config is no exotic dependency that we have good reason to avoid.
I know that its easy to install that package. (Though I wonder whether
the linvdr guys agree.)
My point is just that its not a change-one-line-and-all-will-be-happy,
it does add one more to the b
Clemens Kirchgatterer wrote:
>> But would it kill anybody to simply have all header files at
>> a standard place (/usr/include and /usr/local/include)?
>
> yes it would. how would you install different versions of the same
> libraries (with their headers) if it wasn't in different paths? and
> wha
clemens kirchgatterer wrote:
> structure bin, lib, include, share, ... if i want to compile software
> using the libs (and headers) of opt1 i only have to do
> "PKG_CONFIG_PATH=/opt1 make" and to start that program
> "LD_LIBRARY_PATH=/opt1 prog". given the Makefile of prog uses
> pkg-config properl
Ville Skyttä wrote:
> I'm a bit confused about the locale dir stuff in VDR 1.6.0 especially wrt.
> plugins. newplugin hardcodes LOCALEDIR to $(VDRDIR)/locale without taking
> Make.config into account at all. The result is that plugins will try to
> place their *.mo into a wrong location if LOC
Jean-Claude Repetto wrote:
> My Medion MD 4688 remote (from Aldi) has lost its codes because the
> batteries were dead :-(
> I am not using LIRC, but the RC input of a WinTV DVB-S REV 1.3, and this
> is my remote.conf file :
>
> remote-event0._Setup /proc/av7110_ir 8000 20
> remote-event
Peter Evertz wrote:
> I am very interested in this feature. My providers (astra/hotbird) are
> smart enough not to send not to much garbage, but deleting of unused
> channels is really a pain. I am at 4500 Channels in my channels.conf and
> I am pretty sure that at least 30 % of them are long go
Hi list,
There's a new version of the DVB API wrapper patch that adds fallback
compatibility to the current stable DVB API without multiproto support.
The new version also fixes a bug with the default DVBFE_MOD_AUTO
modulation on DVB-S.
Also, the patch for VDR-1.5/1.6 that allows to read a ch
Klaus Schmidinger wrote:
>> The new version also fixes a bug with the default DVBFE_MOD_AUTO
>> modulation on DVB-S.
>
> Is this fix also relevant for the original VDR 1.7.0?
No, its just a wrapper bug: After importing a DVB-S channels.conf from
1.6.0, VDR uses DVBFE_MOD_AUTO as modulation, and
Thiemo wrote:
>> The patch keeps a time stamp whenever a channel announcement is seen,
>> and the plugin tracks the first-seen and last-seen time of all channels
> Is this timestamp stored in the channels.conf? If so, what about
> compatibility?
No, it is not, to preserve compatibility and to kee
Lauri Tischler wrote:
>>> If that looks hard, i can push a tree which is a result of the above
>>> outlined steps.
>> Thanks a lot for providing http://jusst.de/hg/multiproto_plus.
>
> Any instructions somewhere how to stuff that into stock kernel (debian)?
> I really don't want to compile the tot
Igor Nikanov wrote:
> Chipmaker Via's S3 Graphics division has announced a high-performance
> discrete graphics processor positioned as the first to meet the
> embedded industry's thermal requirements. The 4300E targets gaming
> and signage, offers HD video, DVI or HDMI output, and mixes dedicated
Lauri Tischler wrote:
> Does VDR 1.4 - 1.6 work with multiproto drivers ?
The multiproto drivers are fully backwards compatible, all programs
based on the old API work as before. However, the additional features
like DVB-S2 are of course limited to multiproto-aware software like VDR
1.7 or VDR
Rainer Zocholl wrote:
> ARD swaps some transponders 2nd June.
> With VDR that seems to be a great pain, or?
It doesn't have to, if they move their NID-TID-SID to the new
transponders. VDR will then follow with the existing channel to the new
transponder. Maybe they do that at the end of the simu
lukkinosat wrote:
> I set a time of 40 seconds, but if time watchdog is
> less than 40 seconds, vdr exit with a segmentation
> fault.
> Is this normal? Is possible set a message with a time
> greater of time watchdog?
It is. VDR 1.4.x even used a dirty workaround to display the 5 minute
shutdown
Jelle De Loecker wrote:
> skincurses.c:793: error: ‘WINDOW’ was not declared in this scope
> skincurses.c:793: error: ‘w’ was not declared in this scope
> skincurses.c:793: error: ‘initscr’ was not declared in this scope
The WINDOW data structure is provided by ncurses library. You may
Hi list,
There's a new version of the DVB API wrapper patch. The new version is
compatible to the current multiproto drivers, and wraps the
DVBFE_SET_DELSYS call.
The new version is based on the vdr-1.7.0-multiproto-update.diff, and
probably works also with the vdr-1.7.0-h264-diff.bz2 pat
lucian orasanu wrote:
> I dont understend why are you kep mantaining this
> patch wen vdr-1.7.0 and all plugins should be evolving
> on multiproto. Stop releasing this patch, keep it for you!!
I think that there's a need for it. In my opinion something like VDR
should work on any stable Linux dis
Peter Münster wrote:
> Is it possible with vdr, to send one audio channel to the headphones and
> the other audio channel to the speakers (or another headphones)?
I don't think that this is currently possible, though it would be a
really great feature. The easy way from hardware point - use stere
Hi list,
Is there a proper way to attach another stream receiver to the currently
receiving channel, and - more important - disconnect it properly on
channel change?
The problem arises from difficulties with the osdteletext plugin. (see
http://www.vdr-portal.de/board/thread.php?threadid=70372
Klaus Schmidinger wrote:
>> - Find a way to mark a receiver as being 'extremely unimportant', and
>> don't count them as NeedsDetachReceiver or as Receiving() in that case,
>> maybe by using -1 as priority.
>
> Using a negative priority would be the right way:
>
>cReceiver(tChannelID Channe
Hanno Zulla wrote:
> are there known users of vdr within TV or radio operators?
>
> There was a claim that some TV stations use vdr to archive their
> broadcast stream and another that vdr is used by cable companies as part
> of their infrastructure.
You've probably heard of xeatre.tv, a large sc
Peter Marquardt wrote:
> I don't see any advantages using vdr. Archived material might be used in
> future productions, so you'll definitely want to record the best signal,
> you can get. Furthermore, archived material might be needed to reproduce
> the signal as close as it was, to determine wh
Hi Klaus & list,
Today I had an unexpected parse error in my channels.conf, in this line:
Test Feed;Test Feed:10920:hC56M2O0S0:S19.2E:22000:0:0:0:0:0:1:1063:0
The line was added by automatic transponder scan yesterday. The 'bug' of
this channel is that the SID (4'th last) is 0, triggering
tCh
Hanno Zulla wrote:
> So it appears that we have a problem with
>
> 1) too many vdr-related projects dying or being orphaned when the
>original author looses interest
In most cases, its probably not just loosing interest, but running out
of time. Handling a job, a family and a time-consuming
LinHai wrote:
> when I run the vdr-1.7.0+h.264,there is something wrong with it.
>
> syslog:
> Aug 7 02:09:05 hdtv2 vdr: [10938] ERROR (svdrp.c,84): Address already
> in use
VDR wants to open its port for SVDRP connections (default port 2001),
but someone else (another VDR?) has already open
Klaus Schmidinger wrote:
> On 09/04/08 12:38, Morfsta wrote:
>> Does anyone know what is happening with VDR development these days?
>> There doesn't seem to be much activity - is Klaus taking a long
>> holiday or very busy with work!? :-)
>
> This summer I had quite a few other things to do, and m
VDR User wrote:
> What ever happened to the idea of setting up VDR deveopment on
> mercurial to allow the main contributors who want to work on it to do
> so without hassle/delay?
My 2c on this:
Lets think this through: An open VDR repository for everyone to get in
their personal 'I want this'
Jelle De Loecker wrote:
> I was wondering what the people on the VDR ml thought about this.
From a non-dvb-insider perspective who doesn't really need things like
s2 right now, I'm seeing this form a relaxed point of view.
The two APIs seem to do things different, but in the end they both offer
Hans Werner wrote:
> Sourcecaps I believe has existed as a patch for about four *years* and
> has it's own web page. Absolutely ridiculous. I am lost for words.
So I guess mythtv has something like that, right?
Also, I've never heard of anyone doing a more general patch that also
integrates thin
Morfsta wrote:
> VDR does need some of its core functionality upgraded - for example
> something like the Reel channel scan is badly missing, you should be
> able to easily scan for transponders from within VDR, just like most
> satellite receivers.
Hmmm. My VDR automatically updates its channel
The sky plugin does not compile any more, because it uses PID_MASK_HI
which got renamed to TS_PID_MASK_HI. Patch is attached. A similar
problem strikes for streamdev.
Cheers,
Udo
--- vdr-1.7.1-old/PLUGINS/src/sky/sky.c 2008-09-07 13:34:53.0 +0200
+++ vdr-1.7.1/PLUGINS/src/sky/sky.c
Hi list,
A minimal update to the DVB API wrapper for VDR 1.7.1 is available on my
web site.
http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper
http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper
Cheers,
Udo
___
vdr mailing list
v
Klaus Schmidinger wrote:
> On 09/07/08 19:42, Clemens Kirchgatterer wrote:
>> ...
>> i always wondered why dvb support was directly compiled in while other
>> back and frontends were supposed to be plugins. this clearly leaves a
>> sign that dvb is the "preferd" plattform.
>
> Well, it was the fir
Hi list,
I've updated the runvdr extreme script to version 0.4.
The main new feature is the ability to launch an X server together with
VDR, for use with xine or xineliboutput. An installed login manager like
gdm/kdm/wdm/xdm wont be used, and can be used for a desktop login on a
different run
Petri Helin wrote:
> In fact I am already wondering why plugins are not
> hot-pluggable...
They are, to some degree, by using the proxy plugin. The proxy plugin
can delay loading a plugin, and for some plugins it can unload a plugin
while VDR is running. It can also do the requested continue-on
Niels Wagenaar wrote:
> So, this should mean that VDR 1.7.x should focus on S2API because of
> the obvious reasons. Has anybody started on a patch of somekind to
> include S2API in VDR 1.7.0 or 1.7.1? Mainly I was thinking of doing
> it myself (I have a Hauppauge WinTV-NOVA-HD-S2 which is allready
Hi,
I've published version 0.1.2 of the OSDServer plugin.
The new version fixes a bug on VDR 1.5.11+ on text edit items.
The new version also adds a new Perl binding module that encapsulates
the OSDServer network protocol within Perl objects. By using the Perl
module, OSDServer is a lot easier
Artem Makhutov wrote:
> do you know an solution to make VDR (maybe with the use of the
> sreamdev-plugin) to stream using multicast?
>
> I have an IPTV Settop Box, which I would like to use for wathing TV, but
> it only works with IP-Multicast...
The xineliboutput plugin connects its remote clien
Klaus Schmidinger wrote:
> Well, I like the idea of taking the plain VDR and a FF DVB card
> and have it run "out of the box", without having to fiddle around
> with any plugins ;-)
This is not really a good point any more, since at least latest
development 1.7.x builds wont work without a custom
Pasi Juppo wrote:
> Would this approach allow easier implementation of a real client-server
> solution for VDR or would VDR still need severe changes in order to
> allow this?
Has not much to do with this. The limitation for a client-server
solution is that VDR has exact ONE display front end, ON
Simon Baxter wrote:
> Can anyone suggest a howto, or can guide me on how to circumvent this
> entirely? Basically I need to:
>
> 1) auto log into 'vdruser'
> 2) start xine
This sounds familiar, and leads to the question: Do your *really* need a
window manager? Or do you just run xine fullscree
Jörn Reder wrote:
> With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my
> Budget CI card for recordings so I can't view any Pay TV when a
> recording is active.
The rules that were added with 1.4.1-4 are still present, so they
probably got over-ruled by something else.
Can y
Klaus Schmidinger wrote:
>> Is there any movement to files >2GB for the recordings?
>
> I will most likely change this when going to TS recording format.
> In doing so, I'd like to get rid of splitting recordings into separate
> files altogether. However, I think there might be people who still
>
Karl Glatz wrote:
> But the disadvantages are clear: Modern GPUs support more than the OSD
> provided by VDR (even older gpus do that).
> So none of these Output-Plugins will face the real problem: The OSD is
> (mostly) limited to work with FF cards.
>
> [...]
>
> Even if you don't like such in
On 12.12.2008 18:06, VDR User wrote:
> I can say I've seen many people move away from VDR because it doesn't
> provide a good solution to this. After years of using standalone VDR
> boxes, I too would love if we had the option to use a networked VDR
> with each client being exactly as you describe
On 12.12.2008 23:23, Nicolas Huillard wrote:
> The problems that come to mind in typical current multiple VDR are :
> * DVB device handling is running even if there is no actual DVB device
> (OK, this is not a problem in practice, except for device numbers)
When there are no DVB devices available
On 13.12.2008 00:04, VDR User wrote:
>> Maybe those people who wants such a networking capable vdr should fork it and
>> implement the needed features?
>
> Possibly. However, I could be wrong but didn't Klaus recently say if
> anyone forks VDR, he would stop developing it? And it isn't as if
> th
On 14.12.2008 11:23, matthieu castet wrote:
> - on my configuration the recording only work on vdr#1. on vdr#2 svdrp
> should be used to control recording and ftp to read them (with a video
> player)
I never tried to record on the streaming client, but beside the fact
that video will go unnecessa
On 15.12.2008 11:06, Frank Schmirler wrote:
>>> - no channel sync
>> This would make an excellent addition to streamdev.
>
> Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should
> stick to what it was meant for: streaming.
Streamdev is a receiving device within VDR, and VDR
On 15.12.2008 11:46, Nicolas Huillard wrote:
> The problem is that xineliboutput seems to use a single
> ~/.xine/config_xineliboutput config file, stored in the home directory
> of the vdr user, which is defined by /etc/passwd, which is the same on
> all clients...
You could mount different locati
On 20.12.2008 23:37, Frank Schmirler wrote:
> It seems that we have a different understanding of the term "channel sync".
> Streamdev-0.3.4 has the capabilities you're talking about. What I had in mind
> was merging or replacing the client's with the server's channels list.
One thing is updating t
On 01.12.2008 16:02, Jörn Reder wrote:
Jörn Reder wrote:
With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my
Budget CI card for recordings so I can't view any Pay TV when a
recording is active.
The rules that were added with 1.4.1-4 are still present, so they
probably got ove
Hi list,
I've released the successor of the Multiproto dvb api wrapper patch. As
its predecessor, the patch allows VDR-1.7.2 to be run on kernels without
S2API support by wrapping S2API calls to old API calls.
Behavior can be configured in Make.config again:
DEFINES += -DDVB_S2API_RUNTIME=1
On 08.01.2009 17:14, Sascha Vogt wrote:
>>> And the second question is about the preferred distribution to use VDR
>>> with. Are there any distributions optimized for VDR and fast boot times?
>
> Can you provide any figures? 30 seconds, 50 seconds, 90 seconds? To get
> at least a rough idea.
>
> PS
On 10.01.2009 17:34, Alex Betis wrote:
> Is it possible to map them to 1,2,3,4? Can you think of a scenario both
> color keys and numbers might be used in the same menu?
The recordings menu calls external commands from reccmds.conf with the
number keys, and has commands on the color keys.
The ch
On 11.01.2009 18:05, Joachim Wilke wrote:
> 2009/1/11 Lauri Tischler:
>> Plse dont change it, now when searching for 'plugin' something sometimes
>> comes up also from german sources, if the term is changed to 'erweiterung'
>> all german sources will become essentially black holes.
>
> If this is y
On 10.01.2009 21:58, Johann Friedrichs wrote:
> there seems to be problem in pausing replays of new recordings (output
> to FF). 4 out of 5 times vdr freezes when trying to continue the replay.
> Poll in PlayVideo runs into a timeout and a new write gives EAGAIN. This
> does not happen with old rec
On 11.01.2009 20:44, JJussi wrote:
> Related question.. Is it possible to change order of those colors (what
> represent color-keys) at screen?
> Because my remote have those colors, but two of those are in different
> order...
Would be a Skin-related issue. Skins get the key description by color
On 14.01.2009 02:48, LinHai wrote:
> when I start the VDR-PC,The Screen displays:
> /usr/bin/runvdr:line 576: 4515 Segmentation fault
Line 576 is in my latest patched runvdr extreme 0.4.0 release the line
in which the actual VDR process is launched, at least if you're using
the runvdr-0.4.0-xserve
On 21.01.2009 19:33, Gerald Dachs wrote:
> Assumed I have 2 free Tuners and I zapp through the channels of one
> tuner. Would it be possible to tune the 2. tuner to the same time to
> the after next channel in change direction, so that for the next
> channel change in the same direction it would be
On 06.01.2009 16:06, Klaus Schmidinger wrote:
> - Recording files larger than 4GB or with more than 255 separate
>files hasn't been tested yet.
> + The index file format has been changed to support file sizes of up to 1TB
> (previously 2GB), and up to 65535 separate files per recording (previ
Hi list,
Attached is a new version of cDevice::PlayTsVideo and
cDevice::PlayTsAudio that properly handles partially accepted buffers of
the PlayVideo and PlayAudio functions. The original functions would
discard any partially written data.
These two functions are only used by devices that d
Hi list,
The new S2API-Wrapper patch for VDR-1.7.4 is ready. Beside adding
support for the final 2G-flag, the patch also reverts the change that
sends TS data directly to the device, since TS playback support is even
newer than S2API support.
Since TS to PES conversion by VDR-1.7.4 is also br
Hi list,
A first experimental version of the hard link cutter patch is available
for VDR-1.7.4.
The new version handles 1TB file sizes for TS recordings, properly
calculates the switch-to-large-files for 65535 files, and also handles
PES recordings properly with the old limits.
For TS record
Hi list,
The Cuttime-patch modifies the recording time of edited recordings to
match the time of the first cut mark of the original recording. So if
you start a recording 5 minutes earlier, and then later cut off the
first 5 minutes, the resulting recording will have the proper start time
agai
On 26.01.2009 08:39, Klaus Schmidinger wrote:
> On 25.01.2009 23:53, Udo Richter wrote:
>> Attached is a new version of cDevice::PlayTsVideo and
>> cDevice::PlayTsAudio that properly handles partially accepted buffers of
>> the PlayVideo and PlayAudio functions. The ori
On 26.01.2009 12:10, Udo Richter wrote:
> On 26.01.2009 08:39, Klaus Schmidinger wrote:
>> On 25.01.2009 23:53, Udo Richter wrote:
>>> Attached is a new version of cDevice::PlayTsVideo and
>>> cDevice::PlayTsAudio that properly handles partially accepted buffers of
>
On 26.01.2009 22:25, Deti Fliegl wrote:
> sometimes it is very useful to create and destroy cDevice based classes
> at runtime. Currently it is only possible to create such classes at any
> time but destroying causes inconsistency in the 'devices' array which
> leads to segmentation faults in vario
On 28.01.2009 10:32, alex bustamante wrote:
> "warning: `vdr' uses 32-bit capabilities (legacy support in use)"
>
> What is this exactly?
Your vdr is compiled against libcap version 1, while your kernel already
supports a newer version of capability handling, provided by libcap
version 2. Compil
On 06.02.2009 13:49, Alex Betis wrote:
> I'm playing now with autoshutdown script (the one that is specified with
> -s switch) and have a question.
> When power button is pressed, VDR calls the script, but lets say the
> script decided not to
> shutdown the PC (other background work is done). I see
On 07.02.2009 11:26, Ville Skyttä wrote:
>> VDR does not know whether the shutdown script initiated the shutdown or
>> decided to ignore it,
>
> I suppose it would be quite easy to implement that and maybe some other
> scenarios as well using shutdown script exit statuses. For example exit
> statu
On 08.02.2009 10:19, Ville Skyttä wrote:
> On Saturday 07 February 2009, Udo Richter wrote:
>> Unfortunately it's not that easy. Currently, VDR backgrounds the call to
>> the shutdown script, and detaches the shutdown script from the VDR
>> process. Only because of tha
On 28.02.2009 11:42, Klaus Schmidinger wrote:
> What we also need is a way of detecting whether there are any ttxt subtitles,
> and on which page they are broadcast (haven't looked into the DVB standard
> about this yet, but I believe every broadcaster uses a different page).
The teletext standard
On 31.03.2009 23:39, Thomas Günther wrote:
> This patch allows you to choose if to record and to replay Dolby
> Digital independently.
Just for the record: You can choose to play or not to play DD in the
existing audio track selection dialog. This patch is only needed for
brain-dead plugins that
On 08.04.2009 15:41, Gerald Dachs wrote:
> On every start of the vdr I get this error message:
>Apr 2 00:33:36 vdr vdr: [2462] ERROR (thread.c,225): Keine Berechtigung
> It comes from cThread::SetPriority and seems to be harmless, but annoying.
> Is the attached patch the right cure?
>
>voi
Hi list,
I've updated the runvdr extreme script to version 0.4.1
This release mainly sums up several bug fixes that were available
before, and some internal changes.
Get it at:
http://www.udo-richter.de/vdr/scripts.en.html#runvdr-extreme
http://www.udo-richter.de/vdr/scripts.html#runvdr-extrem
On 13.04.2009 20:17, Klaus Schmidinger wrote:
> On 13.04.2009 20:11, VDR User wrote:
>> There's been recent talk in #xine-vdpau about expanding VDR to allow
>> for a high color osd.
>
> I believe the right way to go is to implement a full 24 (32 with alpha
> channel) bit OSD, as was already done fo
On 14.04.2009 01:42, Torgeir Veimo wrote:
> This would of course require information from vdr in a slightly
> different form; ie. semantically instead of pixels. I'd suggest trying
> to get the OSD information as HTML from VDR, then allowing the frontend
> to render it in any way it deems suitable,
On 17.04.2009 23:49, Timothy D. Lenz wrote:
> In the startup scripts I've been using for some time, it does a check for
> /tmp/VDRBOOT_COMPLETE
> to confirm vdr started correctly. It doesn't seem to have a problem if the
> file is not found, but somewhere along the line vdr
> stoped creating this
On 18.04.2009 15:36, Luca Olivetti wrote:
> On Sat, 18 Apr 2009 13:28:24 +0200
> Udo Richter wrote:
>
>> This is mostly what the VDR skin interface already provides: A
>> semantically structured description of the interface. Most skins
>> translate this into a bitmapp
On 20.04.2009 10:56, Peter Dittmann wrote:
> A simple use case:
> * standalone settop box with VDR and DVD recording capability
> * OS gets a seperate small partition
> * /videoX get the big rest
To add some more variations to the same solution the others already
mentioned:
- Mount your big disk
On 21.04.2009 21:27, Ville Skyttä wrote:
>> So better suggestion for the distri maintainers would be to use the \mnt
>> tree for mounting any partitions.
>
> I disagree, /mnt is system admin area, not something distros should touch.
> http://www.pathname.com/fhs/pub/fhs-2.3.html#MNTMOUNTPOINTFORATE
On 24.04.2009 17:11, Paul Menzel wrote:
> I searched for all variants of
> "test material" for ff-card or "full featured" tv set
> vdr "test material"
> on the WWW to no avail. I only found [1] which also voices this wish.
There's a test picture I've made for exactly the same purpose on my web
pa
On 22.04.2009 14:43, Falk Spitzberg wrote:
> while playing with ACPI wakeup, i noticed that VDR always sets a
> wakeuptime of now+30 minutes, when the timeframe from 'now' to 'begin of
> next recording' is less than 30 Minutes.
>
> Is that intended behaviour?
It is, for two reasons:
- The next wa
On 08.05.2009 21:42, Pasi Juppo wrote:
> The problem is not how to edit but which buttons needs to be pressed to
> set cutting marks, which to move them, which to start actual cutting
> etc.
I agree that the editing key mapping is not very intuitive, at least not
as intuitive as the rest of VDR.
On 09.05.2009 12:38, Klaus Schmidinger wrote:
> - When should such a recording be deleted?
>If it gets deleted as soon as replay is stopped, you'll be very surprised
>when you (or your kids ;-) inadvertently press Stop, and you can't resume
>replay.
>If it gets deleted after a certa
On 08.05.2009 01:17, Andrew Herron wrote:
> I agree it must put extra wear & stress on the hard drive and yes the
> energy usage must be higher.
I don't think so. Disks don't wear that much by reading and writing.
Spinning up and down, heating up and cooling down, shaking them, do lots
of seek o
On 09.05.2009 22:04, Klaus Schmidinger wrote:
>> This 'editing mode' could have some (OSD visible) key mapping like
>> red->toggle mark, green->jump to last mark, yellow->jump to next mark,
>> blue->start editing. However, this would make jumping a lot more difficult.
>
> The color keys are already
On 15.05.2009 23:31, Frank Schmirler wrote:
>> Also, can an svdrp command be added to perform a VDR shutdown? I
>> notice the svdrp command "QUIT" described as "Exit VDR" but after
>> testing this command, nothing happened.
Its "Exit vdr (SVDRP)". Notice the difference. The command quits the
SVD
On 07.06.2009 01:58, Marcel Witte wrote:
> So ext4 seems to be perfect for a video-partition, but to make it more
> perfect, it would be nice if VDR could use the fallocate()-systemcall as
> mentioned in the article. This would prevent fragmentation in the file system.
Sounds like a good plan, but
On 07.06.2009 01:58, Marcel Witte wrote:
> So ext4 seems to be perfect for a video-partition, but to make it more
> perfect, it would be nice if VDR could use the fallocate()-systemcall as
> mentioned in the article. This would prevent fragmentation in the file system.
Sounds like a good plan, but
On 13.06.2009 17:31, VDR User wrote:
> "VDR renders its OSD into an array (of 8 bit indexes into a palette right
> now, and of full 24(rgb)+8(alpha) bit color values for truecolor)
> and its up to the device implementation how it transfers that array (or
> parts of it) to the actual display hard- o
Hi list,
Hard link cutter patch goes into the next round. The 0.2.2 version fixes
GCC-4.4 compile issues, is ready for VDR-1.7.6 - VDR-1.7.8, and comes in
a special version for the soon to be announced VDR-1.6.0-2-tsplay patch.
All in all, there are four versions of the 0.2.2 patch:
vdr-1.5.13
Hi list,
Since VDR-1.7.x introduced the TS recording format, the VDR recordings
world was split into PES and TS recordings. While VDR-1.7 can play both,
all VDR-1.7 recordings cannot be played by 'stable' VDR-1.6 systems any
more. In order to re-unite VDR-1.6 and VDR-1.7, I've back-ported part
On 14.06.2009 16:39, Udo Richter wrote:
In order to re-unite VDR-1.6 and VDR-1.7, I've back-ported parts
of VDR-1.7 to 1.6 to allow playback of TS recordings even on VDR-1.6
systems.
http://www.udo-richter.de/vdr/patches.html#tsplay
http://www.udo-richter.de/vdr/patches.en.html#tsplay
Th
On 21.06.2009 17:08, Klaus Schmidinger wrote:
> On 17.06.2009 19:03, J.W. wrote:
>> I thought you could just release vdr-1.6.1 with the patches you have
>> already published (maybe with additional dvb_api patch) . Are there more
>> bugfixes planed?
>
> I released VDR 1.6.0 only because several peop
201 - 300 of 522 matches
Mail list logo
