On 12.09.22 16:49, Jürgen Schneider wrote:
Hi,
does anybody know what´s up with https://www.vdr-portal.de ?
Jürgen
It has been down in the past for maintenance and was up again shortly
after. So probably we should just wait a little longer.
Manuel
_
u don't like it.
Manuel
On 31.07.22 11:04, Manuel Reimer wrote:
Hi Richard,
Sorry for the late response. I finally found the time to port over your
wiki pages.
I've sent you an invite that you just have to accept. This should give
you full permissions on the repository.
Unfortunately I was
in on github is "keynet". Let me know if you need any more info -
Thanks
On 10/07/2022 12:48, Manuel Reimer wrote:
On 07.07.22 17:02, Richard F wrote:
RIP as you say, but many thanks for keeping it going r/o. I'm actually
still maintaining vdr-convert for my own use + using it quit
On 07.07.22 17:02, Richard F wrote:
RIP as you say, but many thanks for keeping it going r/o. I'm actually
still maintaining vdr-convert for my own use + using it quite a lot. I
plan to recover the wiki pages which represented quite a lot of work.
Has code been copied to github ? Who's owning /
On 24.05.22 21:33, Tobi wrote:
Over the last years, the projects.vdr-developer.org site was hosted on a
server sponsored by Xeatre.tv. This server will now go offline on June, 7'th.
At least for now it still seems to run...
I haven't made a final decision on how to proceed, but I'm leaning to
On 25.05.22 20:11, Richard F wrote:
I find it regularly useful, and refer to the pages from some of the
plugins I use. So sad to see these things that look thousands of hours
to create and debug now falling by the wayside. And once you get used
to it, the Redmine markdown is actually quite a goo
In the end each individual developer has to decide where he wants to
continue his development.
Years ago a small group of VDR users already created a possible
alternative here:
https://vdr-projects.github.io/
https://github.com/vdr-projects
This GitHub organization has a similar goal as
project
On 07.04.20 11:23, Klaus Schmidinger wrote:
The CHAN command tells you which channel VDR itself is currently showing
live.
If you are watching with some streaming plugin, you need to ask that
plugin.
VNSI has no SVDRP interface and even if it had: One idea of having a
VNSI server is that you ca
Hello,
I've created an inofficial VDR mirror on Github.
https://github.com/VDR4Arch/vdr
The target of this mirror is to collect all changes done by Klaus. Not
only releases but also every "official" patch.
This allows you to keep a local VDR copy up-to-date by just running "git
pull" from time
On 01/18/2015 02:43 PM, Joerg Bornkessel wrote:
- VDR now reads command line options from *.conf files in
/etc/vdr/conf.d (thanks to Lars Hanisch). See vdr.1 and vdr.5 for
details.
Is there an example what exactly can we do with this?
The Manpage's give there very small information :(
Lars?
H
Hello,
for most of the GB TV channels it is common to only have the current and
the next event in the EPG list.
I did a few tries to work around this problem using EPG parsed from
internet services and imported to VDR via xmltv2vdr-Plugin.
As this solution is a bit tricky and not very relia
On 08/20/2013 10:12 AM, Klaus Schmidinger wrote:
So my question to Klaus: Is there something like this planned or would
a patch be accepted which adds a feature like this? As far as I know a
new dependency (libudev) would be needed.
I wouldn't like to add a dependency to libudev.
So how could
On 08/20/2013 09:49 AM, Klaus Schmidinger wrote:
BTW: you should have started an all new thread for this, not "reply"
to "VDR needs some way to detect new tuners on runtime..." and simply
change
the subject. Now these two threads are intertwinded... :-(
X-Mailer: Microsoft Office Outlook 12.0
On 08/20/2013 09:40 AM, André Weidemann wrote:
Add a line like this after loading the required modules:
/sbin/modprobe dvb
/sbin/udevadm settle --timeout=30
then start up vdr.
Everything should be fine since udevadm only returns after all actions
regarding the module load are settled.
This is
Hello,
with event based init systems (in my case systemd) it seems to become a
big issue to startup VDR.
If you install VDR on a SSD device, then startup gets *really* fast.
Sometimes that fast, that VDR starts before all devices are initialized.
I've asked in the systemd mailinglist, if th
Hello,
I tried to add all the suggestions, I got for vdrpbd 0.0.1 and created a new
release.
This one comes with a template for vdrpbd.conf and even has a man page to
describe the settings (man vdrpbd.conf).
Not it is also possible to customize the time range and the amount of keypresses
f
YUP wrote:
OK, thanks, it's good to know such a thing before installing on Archlinux.
Did you mean set "PowerKeyIgnoreInhibited" to "yes" in
/etc/systemd/logind.conf ?
$ echo HandlePowerKey=ignore >> /etc/systemd/logind.conf
BTW, could you post a link to your bug report on
systemd?
http://l
Lucian Muresan wrote:
What about using this with non-systemd init, does it just work by
actually deactivating or rather replacing acpid?
Just execute the binary. It will work without any configuration.
The default behaviour is to fork to background (classic "Unix daemon").
If you want to run
#x27;s going on here.
Yours
Manuel Reimer
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
answer to this mail and tell me about your opinion and/or give feature
requests.
Yours
Manuel Reimer
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Lucian Muresan wrote:
So it does on Gentoo, but the problem was with various plugin makefiles
actually, which claimed to be "new style" but for whatever reason the
persons who adapted them to the new style removed including $(PLGCFG) or
circumvented it by mistake.
*Wrong way* to fix this! If th
Lucian Muresan wrote:
I wonder, do you use vanilla VDR or a patched VDR on Archlinux?
https://github.com/CReimer/vdr4arch/blob/master/vdr/PKGBUILD#L31
One patch (MainMenuHooks) which doesn't change anything on the plugin API.
Gentoo
uses the extended patch, it's just the way it is, users are
Helmut Auer wrote:
Sorry to hack this thread , but my wound is still wide open :(
There also was a makefile concept for ten years and apparently no one has a
problem with it, but it was changed and that that has cost me many many hours
and days and all the fun I had with VDR before ...
Then ple
Carsten Koch wrote:
But if they really cannot have readable names,
at least I would not provide a default, but let
the makefile issue a message that they must
be set (as I suggested in the other thread).
They don't have to be set, so why should the Makefile issue a message?
Yours
Manuel
___
ent variables to the correct values for
the VDR "runtime user". This fixes many problems with all kinds of external
software, called by VDR (ProjectX or even Firefox via "externalplayer" to browse
the web on your TV).
Would be great if this small change could still make i
Helmut Auer wrote:
We are talking about > 100 Plugins. Maybe we can drop the half of these but > 50
will be remaining ...
No problem. Let's start a discussion about this in a separate thread. I bet that
about 20 more plugins aren't worth the effort and so about 30 plugins will be
left. Portin
Klaus Schmidinger wrote:
Never in my wildest dreams would I have expected such an outrage about this
change, which was entirely intended to make things simpler in the future.
But if this is not what people want, then let's just stick with the old
Makefiles and declare version 1.7.34 a complete an
Udo Richter wrote:
Being actively developed and being needed are two different things. I wouldn't
want to drop all the plugins that aren't under active development any more, as
this would probably be true for 2/3 of my plugins.
If there is really a need for that special unsupported plugin, then
Klaus Schmidinger wrote:
This was more like a general rant about Linux distributions all wanting
there files in different locations.
This is common on most Unix systems. There are common paths where specific types
of files should be placed to. If you are used to the common paths, then you'll
Klaus Schmidinger wrote:
...still considering what to do with the plugin configuration stuff. Currently I
tend to
put a "plgcfg" entry into vdr.pc, since apparently everybody wants this to be
somewhere else.
I'm just glad Linux distribution managers don't build cars - otherwise we would
most
like
Reinhard Nissl wrote:
I understand that this seems to be a quite simple solution, because in the end,
almost any other configuration option will be converted to either compiler or
linker settings. But it's quite lowlevel and one has to dig through the Makefile
in depth to extract the necessary co
Kartsa wrote:
So what I would like to do is to strip the ending of the names. I created a very
simple script to changes the name when the recording ends using recording hooks
but seems that if the recording stops for any reason and then starts again there
will be problems.
What you want to do i
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt
it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small
problem:
+# By default VDR requires only one single directory to operate:
VIDEODIR = /video
-CONFDIR =
Ludwig Nussel wrote:
I'd still consider a file that is only modified if the user
intentionally does so via the remote control static. There's no
difference between that and using an editor except for the user
interface.
The difference is, that /etc is mounted readonly on some distributions (lik
Ludwig Nussel wrote:
[Readonly /etc]
Currently that might be true. Nevertheless it would be good to enhance
vdr to make it friendlier in that regard though. E.g treating short
lived data like a one shot timer or automatically detected stations
differently than actual configuration like the orderi
Gero wrote:
Vdr's databases reside in /var/lib/vdr where they are changeable by intention.
The databases are linked to /etc.
So the content from /etc (the links to vdr-databases) is static, but the
content of the databases is not.
Its not that good as if the vdr would have divided the setup into
Gerald Dachs wrote:
That's the current state. I can't think of a good reason why it has to
stay that way though. VDR itself could have a menu that allows to enable,
disable and configure plugins.
I can't see a benefit of this approach. At least for distributors it would get
more complicated to
Ludwig Nussel wrote:
Yes. Not only for better systemd integration but in general it would be
better if vdr could work without requiring any external scripting or
configuration.
You need some external script to call VDR as somewhere it is required to
configure plugins and plugin parameters and
VDR User wrote:
Hi. I was wondering if anyone has a patch that puts the disk usage
back into the title of the main & recording menus when using the
anthra (anthra_1920_OSE to be exact) with text2skin? After the
following change in vdr, there's no way to know how much free space is
on my recording
Hello,
what is the current status in this topic? Anyone working on this?
Yours
Manuel
Klaus Schmidinger wrote:
On 09.04.2012 15:18, Udo Richter wrote:
Am 09.04.2012 11:54, schrieb Klaus Schmidinger:
However, there is one thing in the current behavior that I would even
consider a bug: if one
Udo Richter wrote:
> Ok, second attempt:
> - Makefile does not set CACHEDIR and RESDIR
> - Make.config *can* set CACHEDIR and RESDIR, or not.
> - If --cachedir or --resdir is set by command line, use them.
> - If not, default to CACHEDIR and RESDIR.
> - If CACHEDIR or RESDIR is not set (empty stri
Klaus Schmidinger wrote:
> > Try mhddfs
>
> Now that sounds like a very good alternative!
> I'd say this puts the final nail into this VDR feature's coffin ;-)
ACK. Revoking my vote for the old feature. I hope that mhddfs is well
maintained. Seems to be a pretty good alternative. Still a bit wor
Klaus Schmidinger wrote:
> This method may have been useful in the old days where large
> harddisks were unavailable or hard to come by. Now we're living
> in the age of terabyte disks, and setting up a VDR with 1TB of
> video storage (even using a second disk to have a RAID-1 for
> data safety) os
Steffen Barszus wrote:
vdr has 2 types of conf files -
1) internal databases - like channels.conf, setup.conf
2) real conf files like scr.conf, diseqc.conf etc
1 should be in /var/lib/vdr
2 should be in /etc/vdr/
I don't think so. VDR has two types of conf files, but they are:
- Files that ar
Klaus Schmidinger wrote:
Note, though, that after version 2.0 this "multiple disk handling" will
be deprecated and later dropped. So I suggest in a template it should
be /srv/vdr/video, without the '0' at the end.
In my opinion, this way a great feature of VDR would be lost. There is *no*
alte
Udo Richter wrote:
My suggestion:
Allow to keep the default CACHEDIR and RESDIR un-set (empty), and if
--cachedir or --resdir is not present, default to whatever --video and
--config is actually set to. That way, the package builder can decide
whether to set CACHEDIR and RESDIR or not, and if the
Hello,
if I have a look at the changes in 1.7.24, then for me it looks like the file
"Make.config.template" is broken there. As Variables are set using "?=", the
values in "Make.config.template" not longer override the defaults of "Makefile".
I'd vote for reverting this change. Any objections
Tony Houghton wrote:
I don't think a plugin is enough. For better client-server VDR
needs to support multiple clients watching different channels with
different OSDs simultaneously.
It just has to deliver the data. The OSD itself is created by the client.
Yours
Manuel
___
Klaus Schmidinger wrote:
Yes, the next stable version will be 2.0.
Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
I'll see to make "client/server" a priority after that.
What does this mean? Do you plan built-in networking support or do you plan to
improve st
Lou wrote:
I noticed one of my local broadcasters does actually flag a commercial break's
starts and endings:
Nov 3 16:48:37 channel 17 (TSR1) event Thu 03.11.2011 16:45-17:26 (VPS: 03.11
16:45) 'Hawaii Five-0' status 4
Nov 3 17:13:38 channel 17 (TSR1) event Thu 03.11.2011 16:45-17:26 (VPS: 03.
Hello,
> I would also love to see native rotor support. The plugin crashes all
> the time with yavdr and is virtually unusable.
IMHO it depends on how those rotors are controlled. If they are controlled via
DISEQ and VDR, for whatever reason, fails to send the required DISEQ commands,
then VDR
Hello,
> You actually make an important point. VDR was never designed with
> server/client in mind.
But there are plugins out there, that can add exactly what you need. One of
them is "streamdev", which does a very good job.
Not anyone wants a client/server setup, so why should those people, n
Steffen Barszus wrote:
> well the point was to make it simpler, improving something. This goal
> would be missed by that.
"simple" is a matter of definition. I think the VDR built-in handlers of
configuration files are very simple with the big benefit of being plain text.
Yours
Manuel
--
() a
Udo Richter wrote:
> The PES-based VDR-1.6 also has trouble when recording from high
> bandwidth channels. It doesn't crash though, it just has slow OSD,
> juddery playback and partially broken recordings.
> And by the way: The recording interface has always been fetching the TV
> stream in TS form
Theunis Potgieter wrote:
> Or wait for dvbsddevice plugin or similar to have a workaround for your
> card.
Depends on the source of the problem. If the problem is the tuner part, then
this part is not in a separate plugin, as VDR still handles DVB cards without
additional plugins. Most probably
VDR User wrote:
> The problem is with the design (lack of adequate bandwidth) of your
> card, not VDR. I don't think it makes much sense to force/limit VDR
> in any way just to accommodate design flaws with that FF card (which I
> own as well btw). I agree that users experiencing this problem sho
Hi,
> The question is:
> Is there a way to disable the output while recording such channels?
> This will be great for ff card without full-ts-mod.
Another question: Wouldn't it be possible to make the current VDR work with
"old" firmwares? Maybe with a switch to the kernel driver, which togg
Theunis Potgieter wrote:
> Sorry to make things complicated, but would it not satisfy everybody
> needs if you could bind to an ip address, which could be any one you
> specify? For example, I would prefer mine to be bind to my eth0's ip
> for internal lan clients to connect, but not accessible via
Hello,
I've attached a second patch. This patch changes VDR's svdrp port handling in
the following way: If only the localhost item is found in svdrphosts.conf, then
the port is attached to "INADDR_LOOPBACK", which makes it impossible to reach
the port from outside. As soon as even one additiona
Original-Nachricht
> Datum: Sat, 09 Jan 2010 11:25:29 +0100
> Von: Olaf Titz
> An: vdr@linuxtv.org
> Betreff: Re: [vdr] [Patch] Allow to limit SVDRP port to given IP
> But how about this much simpler solution: if svdrphosts.conf is
> missing or empty, bind to localhost only. (An
Hello,
> How about this: if svdrphosts.conf contains only one single IP number,
> then
> open the port for only that IP number. Otherwise i needs to be opened
> generally,
> anyway.
You are absolutely right!
So if svdrphosts.conf only contains "127.0.0.1" (which is the default), then
the port w
Original-Nachricht
> Datum: Fri, 08 Jan 2010 14:57:12 +0100
> Von: Klaus Schmidinger
> An: VDR Mailing List
> Betreff: Re: [vdr] [Patch] Allow to limit SVDRP port to given IP
> What about svdrphosts.conf?
It just denies someone to access. The port is still available, accessibl
ion, if Klaus thinks,
that this feature may be interesting for VDR. The patch can be applied to VDR
1.6.0-2 with or without extensions patch and VDR 1.7.10. I didn't try 1.7.11,
but most probably the patch will work there, too.
Yours
Manuel Reimer
--
() ascii ribbon campaign - against htm
attr(STDIN_FILENO, &savedTm);
HasStdin = true;
}
A working workaround seems to be to execute VDR in the following way:
vdr -t "$TERMINAL" < "$TERMINAL" &
CU
Manuel Reimer
--
() ascii ribbon campaign - against html mail
/\- gegen HTML-Ma
64 matches
Mail list logo
