Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Lars Hanisch]

Hi,

Am 21.12.2011 22:12, schrieb jan med:

I think the problem is YaVDR.
Rotorng work whit both vdr-1.7.21/22 (whit patch).
There are only same problem with low/no signal!
The old-rotor not compile for me.


 That may be. Have you installed the latest updates?
# sudo apt-get update
# sudo apt-get dist-upgrade

 There should at least be an update for vdr-plugin-dynamite.

Regards,
Lars.



kind regards,

Jan23


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] vdr/config.c: memset has wrong parameters

[Lars Hanisch]

Hi,

 The compiler gives me:

:~/src/vdr$ make config.o
g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE 
-DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\" -I/usr/include/freetype2 
  config.c

In file included from /usr/include/string.h:642:0,
 from config.h:16,
 from config.c:10:
In Funktion »void* memset(void*, int, size_t)«,
eingefügt von »cSatCableNumbers::cSatCableNumbers(int, const char*)« bei 
config.c:72:39:
/usr/include/x86_64-linux-gnu/bits/string3.h:82:32: Warnung: Aufruf von »__warn_memset_zero_len« mit Attributwarnung 
deklariert: memset used with constant zero length parameter; this could be due to transposed parameters [standardmäßig 
aktiviert]


 I think, the memset arguments should be swapped:

diff --git a/config.c b/config.c
index 94f6845..53beb4b 100644
--- a/config.c
+++ b/config.c
@@ -69,7 +69,7 @@ cSatCableNumbers::cSatCableNumbers(int Size, const char *s)
 {
   size = Size;
   array = MALLOC(int, size);
-  memset(array, size * sizeof(int), 0);
+  memset(array, 0, size * sizeof(int));
   FromString(s);
 }

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] vdr/config.c: memset has wrong parameters

[Lars Hanisch]

Am 21.12.2011 23:31, schrieb Klaus Schmidinger:

On 21.12.2011 23:18, Lars Hanisch wrote:

Hi,

The compiler gives me:

:~/src/vdr$ make config.o
g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -c 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" 
-DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE
-DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\"
-DLOCDIR=\"./locale\" -I/usr/include/freetype2 config.c
In file included from /usr/include/string.h:642:0,
from config.h:16,
from config.c:10:
In Funktion »void* memset(void*, int, size_t)«,
eingefügt von »cSatCableNumbers::cSatCableNumbers(int, const char*)« bei 
config.c:72:39:
/usr/include/x86_64-linux-gnu/bits/string3.h:82:32: Warnung: Aufruf von 
»__warn_memset_zero_len« mit Attributwarnung
deklariert: memset used with constant zero length parameter; this could be due 
to transposed parameters [standardmäßig
aktiviert]

I think, the memset arguments should be swapped:

diff --git a/config.c b/config.c
index 94f6845..53beb4b 100644
--- a/config.c
+++ b/config.c
@@ -69,7 +69,7 @@ cSatCableNumbers::cSatCableNumbers(int Size, const char *s)
{
size = Size;
array = MALLOC(int, size);
- memset(array, size * sizeof(int), 0);
+ memset(array, 0, size * sizeof(int));
FromString(s);
}


Ville Skyttä already reported this to me and I have removed that call
altogether for the next developer version, because the array is initialized
explicitly, anyway.


 Fine! :-)

Lars.



Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Lars Hanisch]

Hi,

Am 20.12.2011 09:49, schrieb Morfsta:

I have just upgraded my VDR system to yavdr 0.4.0 which uses VDR
1.7.21 and I notice that the Rotor plugin and my own Rotor-ng plugin
no longer drive the rotor using any of the functions in the menu.

Is anyone else seeing this too?

I think that this could be because of recent changes to disecq
handling code within VDR as part of the Unicable update. Klaus could
you point me in the direction of what might have changed such that
these plugins no longer work and I will do my best to implement a fix.

Thanks very much for your help,


 Please install the latest updates with:
$ sudo apt-get update
$ sudo apt-get dist-upgrade

 There was an error in the vdr-plugin dynamite's Makefile.

Thanks,
Lars.



Regards,

Morfsta

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Lars Hanisch]

Hi,

Am 23.12.2011 20:07, schrieb Morfsta:

  Please install the latest updates with:
$ sudo apt-get update
$ sudo apt-get dist-upgrade

  There was an error in the vdr-plugin dynamite's Makefile.


Hi there,

Thanks for your help, but the rotor / rotorng plugins still don't work
after the update.

Any other ideas?


 I don't see a dynamite related problem after a quick look over the source of 
the plugins in the yaVDR PPA.
 The vdr-patch adds a new method to cDevice and dynamite is aware of it.

 Please take a look at 'nm -D /usr/lib/vdr/plugins/libvdr-dynamite.so.1.7.21' if there's a symbol 
cDynamicDevice::SendDiseqcCmd.


 If you'r familiar with build debs you can try to rebuild vdr with some logmessages in the SendDiseqcCmd methods of 
dvbdevice.c to see if there are really sent. I have only DVB-C and can't really test it.


 Some words to dynamite, a core functionallity of yaVDR:
 It creates devices "between" vdr and the "real" devices like a proxy passing all virtual methods to its subdevice. 
This makes it possible to start vdr with a lot of dummy devices (not to mix with the plugin) and attach the dvbdevices 
when they are created, e.g. if they get plugged in via USB.
 Also dynamite is able to set unused devices to an idle state, which means that it closes all its filehandles including 
the frontend. Please look in /etc/vdr/plugins/plugin.dynamite.conf if an idle-timeout is specified.


 dynamite is running in the yavdr team for months and hasn't shown many problems. But I don't think that anyone of us 
has tested it with rotor(ng).


 And take a look at the dynamite repository. There are patches for other 
plugins which need to be patched.

 I hope we can get rotor back to work again!

 If you have dvb hardware, which initialises fast on boot (like PCI/PCIe devices) you can try to disable dynamite in 
the /etc/vdr/plugins/order.conf, just insert a minus before it. But be aware to insert a * if you want to use it again, 
since this is needed to asure that dynamite is the last plugin that gets loaded.


Regards,
Lars.



Kind Regards,

Morfsta

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Rotor / Rotor-NG not working with latest VDR

[Lars Hanisch]

Hi,

Am 03.01.2012 11:43, schrieb Morfsta:

On Sun, Dec 25, 2011 at 12:32 PM, ilia mane  wrote:

Thank you Lars Hanisch it work for me.I just disable the dynamite plugin in
/etc/vdr/plugins/order.conf and the rotorng plugin work now.


Just returned from the Christmas period, merry Christmas all!

Then it looks like dynamite is the problem. Rotorng has a setup option
for the satellite adapter that is connected to the rotor and normally
it is set to 1,2,3 etc depending on the allocated adapter # at boot
up. I guess this might now change with this virtual proxy for the
adapter that is setup by dynamite?

How is this handled, for example by femon or other plugins that need
to communicate with the required physical adapter #?


 A quick grep in the femon sources shows me, that femon opens the frontend on its own. It will use the device's 
"CardIndex()" as adapter number and will always open frontend0 (which will break even without dynamite on 
multi-frontend-devices). For now dynamite will not guarantee that adpater #0 will have cardindex #0. If you want to 
correlate the shown info to your devices, you'll have to look in the dynamite settings -> list all devices (or use the 
SVDRP command "plug dynamite lstd").


 It is possible to assign adapters to specific cardindices with the udev environment variable "dynamite_cardindex". But 
one should use this on all adapters since the logic behind this is not so smart to first attach all devices with a set 
cardindex and then all others.


 I think it might be a good idea if dynamite will use the adapter number as a 
hint for the cardindex.


 I can imagine these things, that will lead to problems with dynamite:
- new virtual functions in cDevice or cDvbDevice: they have to be patched into dynamite's cDynamicDevice so it can 
forward calls to its subdevice
- new non-virtual member functions in cDevice/cDvbDevice: for every method it has to be evaluated if the "parent's" or 
"subdevice's" value has to be return (e.g. CardIndex, DeviceNumber, PatPmtParser, CamSlot etc.). It depends from where 
and in which context these functions are called (has the caller a pointer to a subdevice like a call from within 
cDvbDevice - has it a pointer from the cDevice::device array which will point to the parent device etc.).
- dynamic_cast (like it is used with the new device bonding feature): plugins won't get the "real" 
device like cDvbDevice or similar. It will always be a cDynamicDevice.


 rotorng adds one new virtual function to cDevice: SendDiseqcCmd
 In yavdr this is included in the dynamite plugin (as "nm -d 
/usr/lib/vdr/plugins/libvdr-dynamite.so.1.7.22" confirms).
 When I look at the cDevice-functions rotorng is using I don't see anything which will lead to problems. Maybe it's 
just a cardindex mismatch?


 There are two ways to test this (after reactivating dynamite with an * in /etc/vdr/plugins/order.conf, which will 
ensure that dynamite loads as the last plugin):


1. The "fast" way: Detach all devices from vdr with "svdrpsend plug dynamite 
dtad"
   Reattach them in the "right" order with "svdrpsend plug dynamite attd 
/dev/dvb/adapter0/frontend0" etc.

2. The other way: Add a udev rule to your system that will assign every 
frontend a cardindex, it may look like:

 ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", 
ENV{dynamite_cardindex}="%E{DVB_ADAPTER_NUM}"

 Reload the modules and restart vdr. This assumes you have no card with 
multiple frontends.


Thanks,
Lars.



Thanks,

Morfsta

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21

[Lars Hanisch]

Hi,

Am 08.01.2012 02:09, schrieb Hawes, Mark:

Hi Lars,
I have got the sc plugin working with your hybrid patch v2 and
introduced the premium card and all is working well.
Are you planning any more revisions to the patch? Or at least a 1.7.22
version?


 Not really, because the driver changes introduced by Manu are on its way into linux-media. After that only one 
frontend will be left and new ioctls are there to switch between delivery systems.

 Rumours say Klaus is working on it for vdr 1.7.23... :-)

 But if you like, you can send me your changes. I'm curious about them.

Lars.


Thanks,
Mark.

-Original Message-
From: Hawes, Mark
Sent: Thursday, 1 December 2011 10:08 PM
To: 'VDR Mailing List'
Subject: RE: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21

Hi Lars,
First reports on v2 of your multi-frontend patch with HVR 4000 card:
   - can switch between both frontends successfully and very stable with
repetitive tests
   - timer behaviour as expected
   - switching response seems quicker than before
   - Streamdev and xineliboutput plugins compile OK. Xlo tested OK, will
look at Sd later
   - Have modified Rotor plugin to fit (maintaining personal version) and
all seems OK
   - Working through sc plugin changes to fit.
If I can get the sc plugin working I'll move across a sd premium card
into the mix and see how it behaves, watch this space ...
While this is all good obviously things will no doubt change when Klaus
releases 2.x with the new multi-frontend adapter handling. However,
reading between the lines this may not be in the immediate future so an
interim workaround  for these cards is appreciated by me and I expect
others ...
Thanks and keep up the good work.
Mark.


-Original Message-
From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf
Of L. Hanisch
Sent: Thursday, 1 December 2011 10:50 AM
To: VDR Mailing List
Subject: [vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21

Hi,

   Here's version 2 of my multi-frontend-patch. It's still "dirty", since
it changes the constructor of cDvbDevice which will break compilation of
some plugins. But I think it might be necessary to look at the relevant
plugins since they might need to react on frontend changes. I haven't
tested any of those plugins but will have a look at some that I'm using.
Maybe there have to be some virtual functions like
"BeforeFrontendSwitch" and "AfterFrontendSwitch" so the plugins are even
able to know about it.

   Assumption for this patch:
   All frontends within one adapter have to be used mutually exclusive.
All cards I know behave in this way. If there are cards with multiple
frontends which can be used simultaneously I'd like to hear about it.

   Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I
think my patch can easily be converted to use that.

   I'm still working on this patch, it's not finished yet... :-)

   Have fun,

Lars.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23

[Lars Hanisch]

Hi,

Am 23.01.2012 05:43, schrieb Hawes, Mark:

I have updated my current build taken from the Media Build Tree last Tuesday 
with the contents of the linux media tarball dated 22/01/2012 and rebuilt my 
drivers.
I still get the same results.
As the system initialises the following lines appear in the syslog:
Jan 23 12:16:44 Nutrigrain kernel: [9.338720] tuner-simple 16-0061: 
couldn't set type to 63. Using 78 (Philips FMD1216MEX MK3 Hybrid Tuner) instead
Jan 23 12:16:44 Nutrigrain kernel: [9.346240] DVB: registering adapter 1 
frontend 0 (Conexant CX24116/CX24118)...
Jan 23 12:16:44 Nutrigrain kernel: [9.349110] DVB: registering adapter 1 
frontend 1 (Conexant CX22702 DVB-T)...
Subsequently when starting VDR the following is logged:
Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'A - 
ATSC'
Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'C - 
DVB-C'
Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'S - 
DVB-S'
Jan 23 13:10:13 Nutrigrain vdr: [2704] registered source parameters for 'T - 
DVB-T'
Jan 23 13:10:13 Nutrigrain vdr: [2704] probing /dev/dvb/adapter0/frontend0
Jan 23 13:10:13 Nutrigrain vdr: [2704] new device number 1
Jan 23 13:10:13 Nutrigrain vdr: [2704] frontend 0/0 provides DVB-S with QPSK ("ST 
STV0299 DVB-S")
Jan 23 13:10:13 Nutrigrain vdr: [2708] tuner on frontend 0/0 thread started 
(pid=2704, tid=2708)
Jan 23 13:10:13 Nutrigrain vdr: [2709] section handler thread started 
(pid=2704, tid=2709)
Jan 23 13:10:13 Nutrigrain vdr: [2704] probing /dev/dvb/adapter1/frontend0
Jan 23 13:10:13 Nutrigrain vdr: [2704] new device number 2
Jan 23 13:10:14 Nutrigrain vdr: [2706] video directory scanner thread ended 
(pid=2704, tid=2706)
Jan 23 13:10:14 Nutrigrain vdr: [2705] video directory scanner thread ended 
(pid=2704, tid=2705)
Jan 23 13:10:19 Nutrigrain vdr: [2704] frontend 1/0 provides DVB-S,DVB-S2 with QPSK 
("Conexant CX24116/CX24118")
Jan 23 13:10:19 Nutrigrain vdr: [2712] tuner on frontend 1/0 thread started 
(pid=2704, tid=2712)
Jan 23 13:10:19 Nutrigrain vdr: [2713] section handler thread started 
(pid=2704, tid=2713)
Jan 23 13:10:24 Nutrigrain vdr: [2704] ERROR (dvbdevice.c,1087): 
/dev/dvb/adapter1/frontend1: Device or resource busy
Jan 23 13:10:24 Nutrigrain vdr: [2704] found 2 DVB devices
I'm sure that I have the latest drivers loaded now, but still the same issue.

> The only conclusion that I can come to is that the necessary changes to the 
drivers
> have not (yet) been made.  Has anyone else tried VDR 1.7.23 with a HVR 4000 
hybrid card
> and if so, do you get the same results?

 Yes, I would get to the same conclusion. There should only be one frontend.
 You should point the guys on the linux-media mailing list to this "bug".

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Theses Client/Server VDR

[Lars Hanisch]

Hi,

Am 02.03.2012 11:12, schrieb fnu:

Hi there,

following the discussion regarding Client/Server the last couple of day, I'm
honestly horrified.

What I did realize where super complex ideas, hacks, bottomline a solution
from developers for developers. I got the imagination some want to keep out
normal users, inventing VDR to death, because only a few users are able to
handle it.

Since Apple pretty much come with a TV solution this year, expectations of
users will change in terms of GUI&  usability. And not only Apple, even
Ubuntu does invent in the same direction on their UbuntuTV.

There's no need to copy these solutions, but the need to be prepared to
these fast changing expectations. To think about the details of VDR, a good
and stable solution, which I love to use since over 10 years now.

I don't have any issues to run a complete VDR on Client and Server, the
binary is small, so what.

My dream of a Client/Server VDR solution is:

- 1+n VDRs do find themselfs seemless w/o user interaction within a network
- 1+n VDRs do elect/define a principle, which become the leader of the pack,
preferably that one with (the most) DVB devices


 Since automatism may be wrong (same number of devices in each vdr or whatever), a simple priority numbering scheme of 
the vdrs should be possible. Something like: "This is my main vdr (priority 100), this vdr has priority 50 etc."

 I think this could be handled by every user and it can be easily configured 
via OSD. :)

Lars.


- The principle becomes the central point of VDR operation
- Timers set on whether Client/Server VDR, is handled by the principle
centrally
- Recordings are also handled centrally on the principle, the clients do
have seemless access to it
- It doesn't matter if the clients do have their own disks
- But if needed principle can use this addional disk space on clients and
each client does also have seemless access
- DVB devices can be added and removed dynamically  to each of the VDRs, but
principle stay responsible for all DVB devices within network
- Plugins can be added/removed dynamically via OSD or a Web-Interface
- The VDR pack or rather the principle can be controlled/programmed by a
cloud service from all over the world.
- Setting up one of these VDRs may only be possible for experienced user,
but es soon as they're up and running, you're little children could hanle
them.

Just my vision for a smart client/server VDR solution.

Cheers
fnu


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Segfault in dvbhddevice

[Lars Hanisch]

Am 07.03.2012 21:43, schrieb Udo Richter:

Am 07.03.2012 21:19, schrieb Richard Scobie:

I have found that adding a "sleep 5" to my startup script, between
loading the drivers and starting vdr, has caused it to successfully
survive five reboots.


I'm doing an udevadm settle --timeout=30 after load/unload, haven't had
any issues with that. Before I had that solution, I was polling for all
devices to appear under /dev/dvb, before starting VDR.


 "udevadm settle" is a nice replacement for a sleep, something learned today, 
thanks. :-)

 ;-)
 This is where the dynamite-plugin comes in (needs a patch for the vdr). It creates device-proxies so vdr can start 
without the actual devices. dynamite listens on udev and attachs the devices as they got created.

 This scenario was one of the reasons to develop that plugin...


 If the environment is not too fancy (device bonding is not tested by me, I have only 
DVB-C/-T) it should "just work"...

Lars.



Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Segfault in dvbhddevice

[Lars Hanisch]

Am 08.03.2012 12:52, schrieb syrius...@no-log.org:

Lars Hanisch  writes:


Am 07.03.2012 21:43, schrieb Udo Richter:

Am 07.03.2012 21:19, schrieb Richard Scobie:

I have found that adding a "sleep 5" to my startup script, between
loading the drivers and starting vdr, has caused it to successfully
survive five reboots.


I'm doing an udevadm settle --timeout=30 after load/unload, haven't had
any issues with that. Before I had that solution, I was polling for all
devices to appear under /dev/dvb, before starting VDR.


  "udevadm settle" is a nice replacement for a sleep, something learned today, 
thanks. :-)

  ;-)
  This is where the dynamite-plugin comes in (needs a patch for the
vdr). It creates device-proxies so vdr can start without the actual
devices. dynamite listens on udev and attachs the devices as they got
created.
  This scenario was one of the reasons to develop that plugin...



I use it because it adds ways to detach cards from vdr, reload drivers
and use them again without stopping vdr.

Thanks again for this wonderful plugin !

btw, i haven't tested, does vdr-1.7.24-dynamite-subdevice.patch apply
on 1.7.26+(patches from the ml)


 Haven't tested that yet, I'm still working on 1.7.25. And I think there will 
be soon a 1.7.26...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Local frontend - using XBMC strm vs vdr-sxfe

[Lars Hanisch]

Hi,


I just wish I could have the full VDR OSD, but within XBMC :)


Most likely will never happen.


 You'll never know. :)

 Haven't looked into XBMC yet, but dbus2vdr (0.0.4) can export the OSD as PNG 
files and signals changes via DBus.
 Disadvantage: you can't use the OSD of the output-plugin anymore (which you 
may not need anymore).

 vdr just can use one OSD-provider at the time. Mostly it's instantiated in the "MakePrimaryDevice" of the 
output-plugin. dbus2vdr can create its OSD-provider which will delete the present one, but can't re-create the old 
provider (haven't tried yet calling "PrimaryDevice()->MakePrimaryDevice()" yet).

 And it's not possible at the moment to let dbus2vdr recreate its provider. But 
this will come.

 The first use case for this OSD export is a headless vdr. But it may be worth 
trying for your setup, too.
 Please take a look at the README of dbus2vdr line 168ff.
 https://github.com/flensrocker/vdr-plugin-dbus2vdr/blob/master/README

 What you have to do:
 Listen for dbus-signals on interface de.tvdr.vdr.osd from object /OSD and send the usual keystrokes to vdr to open OSD 
and navigate (you can do that also viy DBus, see line 119 in the README).
 "Open" will inform you about the position and id of the OSD, "Display" sends you a filename to the PNG and its 
position relative to the position of the OSD. After "Close" all files will be deleted.

 Every PNG between Open and Close have to be displayed over the last ones since 
only differences are reported.

 It's a really young feature and never really tested, and I would like to get 
some input about this.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.26

[Lars Hanisch]

Hi,

Am 10.03.2012 16:18, schrieb Klaus Schmidinger:

- Added a new plugin interface for implementing EPG handlers.
+ A plugin can implement an EPG handler by creating an object derived from
cEpgHandler and implementing the necessary member functions.
+ The special handling of events with table id 0x00 has been dropped.
For backwards compatibility EPG events with table ids lower than 0x4E will
be treated as if they had a table id of 0x4E, and the new plugin 'epgtableid0'
can be used to have them handled like in previous versions.
+ The default table id for a newly created cEvent has been changed to 0xFF,
which is higher than any normal table id that is broadcast in the EIT data.
See PLUGINS.html, section "Electronic Program Guide" for more information.


 Damn, too late for today... :-)
 Just finished the noepg-plugin-skeleton at

 https://github.com/flensrocker/vdr-plugin-noepg

 but have no time now for really testing that.

 Thanks!

Lars.



Have fun!

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] noepg-plugin

[Lars Hanisch]

Don't want to hijack the announce-thread... :)

Am 10.03.2012 20:26, schrieb Mika Laitio:
>>   Damn, too late for today... :-)
>>   Just finished the noepg-plugin-skeleton at
>
> So according to README this plug-in replaces the noepg.patch.
> What is the functionality/purpose of this noepg patch/plugin?

 First it's just an example for the new interface.

 On the other hand it will help those who import epg "the old way" (SVDRP or other plugins) and don't want to mix it 
with the DVB-epg until there are enough epg-plugins to replace them.
 Since the starttimes of extern epg-sources sometimes don't match the DVB times it can lead to double entries. That was 
avoided with the noepg-patch which deactivated DVB-epg for selected channels.


Lars.

>
> Mika
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] noepg-plugin

[Lars Hanisch]

Hi,

 Here's the first working release 0.0.1 of the noepg-plugin.

 https://github.com/downloads/flensrocker/vdr-plugin-noepg/vdr-noepg-0.0.1.tgz

 It replaces the noepg-patch.

 You configure the channels you want to block with a "settings.conf" in the 
plugin's configuration directory.

 In blacklist-mode the DVB-epg for all listed channels will be ignored.

-example begin-
mode=blacklist
C-1-1011-11100
- example end -

 In whitelist-mode the DVB-epg for all listed channels will be allowed.
 The DVB-epg for all other channels will be ignored.

-example begin-
mode=whitelist
C-1-1011-11100
- example end -

 As always please take a look at the README. :)

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] vdr 1.7.27, fix UPDR

[Lars Hanisch]

Hi,

Due to a missunderstanding, UPDR doesn't update the global recordings list only 
the local list of LSTR.

 void cSVDRP::CmdUPDR(const char *Option)
 {
   Recordings.Update(false);
+  ::Recordings.Update(false);
   Reply(250, "Re-read of recordings directory triggered");
 }

Maybe the member should be renamed to make the code more readable?

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] vdr 1.7.27 - can add groupsep with NEWC

[Lars Hanisch]

Hi,

The attached patch adds the possibility to add group separators to the channels 
via SVDRP's NEWC command.

Lars.
diff --git a/svdrp.c b/svdrp.c
index 01366dd..ce806ac 100644
--- a/svdrp.c
+++ b/svdrp.c
@@ -257,8 +257,8 @@ const char *HelpPages[] = {
   "MOVC  \n"
   "Move a channel to a new position.",
   "NEWC \n"
-  "Create a new channel. Settings must be in the same format as returned\n"
-  "by the LSTC command.",
+  "Create a new channel or group separator. Settings must be in the\n"
+  "same format as returned by the LSTC command.",
   "NEWT \n"
   "Create a new timer. Settings must be in the same format as returned\n"
   "by the LSTT command. It is an error if a timer with the same channel,\n"
@@ -1294,7 +1294,7 @@ void cSVDRP::CmdNEWC(const char *Option)
   if (*Option) {
  cChannel ch;
  if (ch.Parse(Option)) {
-if (Channels.HasUniqueChannelID(&ch)) {
+if (ch.GroupSep() || Channels.HasUniqueChannelID(&ch)) {
cChannel *channel = new cChannel;
*channel = ch;
Channels.Add(channel);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] POLL: epg behavior when guide data is missing

[Lars Hanisch]

Hi,

Am 01.05.2012 17:45, schrieb VDR User:

Hi ML. I had noticed that several of my channels were missing from the
epg list. It turns out this is because VDR will exclude any channels
from epg list that don't have epg data. It made more sense to me that
rather than excluding those channels, they be listed with "No data
available" so the channels are at least still accessible from the epg
list. Otherwise the user has to exit the epg, navigate to the channels
list and find them there.

Since it's probably safe to assume most users spend most of their time
in the epg list when in the osd, doesn't it also make sense that the
full channel list should be available there as a matter of
convenience? Klaus recommended I pose this to the ML and if see if
others agreed. If so, he'll adopt the idea.

So in consideration of the above, do you think the epg list should
display _all_ channels, including those without any guide data, giving
those channels "No data available". Or, do you think the epg list
should exclude channels without guide data and leave those channels
only accessible elsewhere?

Thanks for your input


 Make it configurable and everyone is happy since there will be always someone 
who is not your opinion.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS

[Lars Hanisch]

Hi,

Am 09.05.2012 16:39, schrieb Midas:
[...]

2. I got completely confused in how vdr might count devices. As
described i have two satellite and one terrestial device.

[...]

 You can try to set the adapter number with the module parameter "adapter_nr", so the devices have the same order on 
every boot. That will remove one possible cause of failure.

 See "modinfo ".

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Quiet times...

[Lars Hanisch]

Am 06.08.2012 09:04, schrieb Klaus Schmidinger:
> It's been rather quiet on the VDR mailing list lately, but I guess
> everybody (like myself) is enjoying the summer and engaged in outdoor
> activities...

 Yeah, just now back from Sweden with our camper and had a good time with a lot 
of sun...

 Now back to business (or maybe next week...). :)

Lars.

> 
> Klaus
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ring buffer overflows

[Lars Hanisch]

Hi,

Am 22.08.2012 13:24, schrieb Marx:
> Because of many problems with three different TV cards I had prevoiusly - I 
> bought one which claims full linux support -
> Qbox II by TBS.
> After a few  hours I have card working, hovewer I have a problem too.
> When I'm recording it seems ok, but when I'm watching through streamdev + 
> VLC, there are errors about buffer overflow.
> Often it causes viewing to stop after a minute or so.
> I suspect there is need to set some larger buffers but I don't know where.

 I have similar issues when using vlc (on Windows) and streamdev. I can watch 
10 to 15 minutes without any problem and
then vdr logs ring buffer overflows (just tested with ZDF HD/DVB-C). I hadn't 
time yet to debug this, but I suspect that
decoding in vlc is a little bit too slow and vdr delivers data "too fast" (of 
course vdr will deliver with the right
speed since it's receiving the original stream). Increasing buffers wouldn't 
resolve the problem, it will just take
longer till the first overflow is hit.

 And I think it's independend to the dvb card. I use a Satelco EasyWatch and a 
Cine C/T.

Lars.

> 
> Aug 21 23:09:45 wuwek vdr: [5018] Streamdev: Accepted new client (HTTP) 
> 192.168.1.10:2734
> Aug 21 23:09:45 wuwek vdr: [5018] CAM 1: assigned to device 1
> Aug 21 23:09:47 wuwek vdr: [5009] max. latency time 3 seconds
> Aug 21 23:09:51 wuwek vdr: [5030] streamdev-writer thread started (pid=5009, 
> tid=5030)
> Aug 21 23:09:51 wuwek vdr: [5031] streamdev-livestreaming thread started 
> (pid=5009, tid=5031)
> Aug 21 23:09:51 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 
> 4, HasCaDescriptors 0)
> Aug 21 23:09:52 wuwek vdr: [5032] receiver on device 1 thread started 
> (pid=5009, tid=5032)
> Aug 21 23:09:52 wuwek vdr: [5033] TS buffer on device 1 thread started 
> (pid=5009, tid=5033)
> Aug 21 23:09:52 wuwek vdr: [5018] Streamdev: Accepted new client (HTTP) 
> 192.168.1.10:2737
> Aug 21 23:09:52 wuwek vdr: [5030] ERROR: streamdev-server: couldn't send 
> 48504 bytes: Połączenie zerwane przez drugą stronę
> Aug 21 23:09:52 wuwek vdr: [5030] streamdev-writer thread ended (pid=5009, 
> tid=5030)
> Aug 21 23:09:53 wuwek vdr: [5018] client (HTTP) 192.168.1.10:2734 has closed 
> connection
> Aug 21 23:09:53 wuwek vdr: [5018] streamdev-server: closing HTTP connection 
> to 192.168.1.10:2734
> Aug 21 23:09:53 wuwek vdr: [5031] streamdev-livestreaming thread ended 
> (pid=5009, tid=5031)
> Aug 21 23:09:54 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 
> 5, HasCaDescriptors 0)
> Aug 21 23:09:54 wuwek vdr: [5018] buffer stats: 48692 (1%) used
> Aug 21 23:09:54 wuwek vdr: [5034] streamdev-writer thread started (pid=5009, 
> tid=5034)
> Aug 21 23:09:54 wuwek vdr: [5035] streamdev-livestreaming thread started 
> (pid=5009, tid=5035)
> Aug 21 23:09:54 wuwek vdr: [5033] TS buffer on device 1 thread ended 
> (pid=5009, tid=5033)
> Aug 21 23:09:54 wuwek vdr: [5032] buffer stats: 50384 (1%) used
> Aug 21 23:09:54 wuwek vdr: [5032] receiver on device 1 thread ended 
> (pid=5009, tid=5032)
> Aug 21 23:09:54 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 
> 4, HasCaDescriptors 0)
> Aug 21 23:09:54 wuwek vdr: [5036] receiver on device 1 thread started 
> (pid=5009, tid=5036)
> Aug 21 23:09:54 wuwek vdr: [5037] TS buffer on device 1 thread started 
> (pid=5009, tid=5037)
> Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 208 (type 0xc0) RegDesc not 
> found -> assume AC-3
> Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 213 (type 0xc1) RegDesc not 
> found -> assume AC-3
> Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 1200 (type 0xc6) RegDesc not 
> found -> assume AC-3
> Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 666 (type 0xc0) RegDesc not 
> found -> assume AC-3
> Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 667 (type 0xc1) RegDesc not 
> found -> assume AC-3
> Aug 21 23:09:56 wuwek vdr: [5015] ERROR: 1 ring buffer overflow (188 bytes 
> dropped)
> Aug 21 23:10:02 wuwek vdr: [5015] ERROR: 8 ring buffer overflows (1504 bytes 
> dropped)
> Aug 21 23:10:09 wuwek vdr: [5015] ERROR: 10 ring buffer overflows (1880 bytes 
> dropped)
> Aug 21 23:10:15 wuwek vdr: [5015] ERROR: 7 ring buffer overflows (1316 bytes 
> dropped)
> 
> Marx
> 
> Ps. I know why I get:
> ERROR: streamdev: protocol violation (VTP) from 127.0.0.1:37275
> It's from vdradmin-am which seems incompatible with VDR 1.7.28
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ring buffer overflows

[Lars Hanisch]

Hi,

Am 28.08.2012 17:08, schrieb Dominic Evans:
> On 28 August 2012 11:30, Marx  wrote:
>> Are we the only two who have this problem?
>> Marx
> 
> Are you watching on VLC over Wifi? Have you tried increasing vlc's
> HTTP caching? I tend to set it to 'maximum latency', or switch to
> advanced and increased it to ~4000ms.

 I'm watching over GBit-LAN, so no bandwidth problem.
 I've increased the HTTP caching, I will see if it helps.

> Also try accessing streamdev's PES streams
> (http://example.com:3000/PES/101 ) rather than the TS stream.

 My (Windows-)vlc won't play, don't know why. Only TS is working here.

> Oh and also try using xineliboutput's streaming of the current channel
> (http://example.com:37890 ) to see if that works any better.

 I'm using softhddevice. Streaming is not so important for me to give up the 
advantages of softhddevice. :)

Thanks,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.30

[Lars Hanisch]

Hi,

Am 19.09.2012 09:25, schrieb Mika Laitio:
>> From the log I can see that the driver apparently makes DVB-S/DVB-S2
>> available
>> under adapter1/frontend0 and tries to provide DVB-T on adapter1/frontend1.
>> But if it does so, it tells the application that it can provide
>> DVB-S/DVB-S2
>> *and* DVB-T at the *same* time - which apparently isn't the case.
> 
> Yes, you are correct. If I use frontend0 for DVB-S, I can't use frontend
> 1 at a same time for DVB-T. I will try in the evening to build the
> latest drivers myself to check whether both frontends are still created
> also with that one.

 As far as I know the driver for the HVR4000 has not been changed to use the 
new dvb-api capabilities for switching the
frontend type.
 Maybe you can persuade them, the last user hadn't success yet... :(

Lars.

> 
> Are there some other cards/drivers available with similar limitation
> where only a single frontend0 is created?
> 
> Mika
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] correct some includes at plugins

[Lars Hanisch]

Hi,

Plugins should use

#include 

 and not

#include "vdr/..."

Regards,
Lars.
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
index 439ec9b..10882ae 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
@@ -10,8 +10,8 @@
 #define __DVBHDFFDEVICE_H
 
 #include "hdffcmd.h"
-#include "vdr/dvbdevice.h"
-#include "vdr/dvbspu.h"
+#include 
+#include 
 
 /// The cDvbHdFfDevice implements a DVB device which can be accessed through the Linux DVB driver API.
 
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
index bd74cde..eff1511 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
@@ -9,8 +9,8 @@
 #ifndef __DVBSDFFDEVICE_H
 #define __DVBSDFFDEVICE_H
 
-#include "vdr/dvbdevice.h"
-#include "vdr/dvbspu.h"
+#include 
+#include 
 
 /// The cDvbSdFfDevice implements a DVB device which can be accessed through the Linux DVB driver API.
 
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffosd.h b/PLUGINS/src/dvbsddevice/dvbsdffosd.h
index 8a1bc62..762cc8a 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffosd.h
+++ b/PLUGINS/src/dvbsddevice/dvbsdffosd.h
@@ -9,7 +9,7 @@
 #ifndef __DVBSDFFODF_H
 #define __DVBSDFFODF_H
 
-#include "vdr/osd.h"
+#include 
 
 class cDvbOsdProvider : public cOsdProvider {
 private:
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Lars Hanisch]

Hi,

Am 25.10.2012 17:23, schrieb Morfsta:
> The third version of my plugin rotorng has been released here: -
> 
> http://projects.vdr-developer.org/projects/plg-rotor-ng/files
> 
> This plugin allows you to steer a disecq 1.1 rotor, find satellites
> with a signal meter and to store them at given positions. It also has
> a rudimentary channel scanner which works with both DVB-S and S2. Much
> of this code has been merged together from the existing actuator and
> rotor plugins, so thanks to the developers of those for their work.
> 
> Please see the README file, there are a number of functions within the
> user interface that aren't fully implemented or working but the main
> functions are there.
> 
> Changes since previous version: -
> 
> 2012-10-11: Version 0.2
> 
> - updated sat card store value in config, always resetting
> - fixed issue with change implemented in 1.7.23 (thanks to Ihanisch)
     ^
 That should be an l (small L) or you can use my full name: Lars Hanisch
 :)
 Thanks for the good cooperation. I hope we'll succeed in getting it working 
with dynamite, too.
 I will dig into the new version of you plugin at the weekend.

Regards,
Lars.

> 
> 2012-10-21: Version 0.3
> 
> - Added patch for vdr-1.7.27 onwards, old patch for VDR still exists also.
> - Fixed problem with cStatusMonitor::ChannelSwitch call introduced in
> VDR 1.7.26 so dish moves on channel change
> 
> Good luck!
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Lars Hanisch]

Hi,

Am 25.10.2012 17:23, schrieb Morfsta:
> The third version of my plugin rotorng has been released here: -
> 
> http://projects.vdr-developer.org/projects/plg-rotor-ng/files
> 
> This plugin allows you to steer a disecq 1.1 rotor, find satellites
> with a signal meter and to store them at given positions. It also has
> a rudimentary channel scanner which works with both DVB-S and S2. Much
> of this code has been merged together from the existing actuator and
> rotor plugins, so thanks to the developers of those for their work.
> 
> Please see the README file, there are a number of functions within the
> user interface that aren't fully implemented or working but the main
> functions are there.
> 
> Changes since previous version: -
> 
> 2012-10-11: Version 0.2
> 
> - updated sat card store value in config, always resetting
> - fixed issue with change implemented in 1.7.23 (thanks to Ihanisch)
> 
> 2012-10-21: Version 0.3
> 
> - Added patch for vdr-1.7.27 onwards, old patch for VDR still exists also.
> - Fixed problem with cStatusMonitor::ChannelSwitch call introduced in
> VDR 1.7.26 so dish moves on channel change

 You've forgotten the wrap the definition of ChannelSwitch into #if's:

--- a/rotorng.c
+++ b/rotorng.c
@@ -333,7 +333,11 @@
   int last_position_shown;
   bool transfer;
 protected:
+#if VDRVERSNUM >= 10726
   virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber, bool 
LiveView);
+#else
+  virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber);
+#endif
 public:
   cStatusMonitor();
 };

Regards,
Lars.

> 
> Good luck!
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Lars Hanisch]

Hi,

Am 25.10.2012 19:44, schrieb Morfsta:
> On Thu, Oct 25, 2012 at 5:42 PM, Lars Hanisch  wrote:
>>  You've forgotten the wrap the definition of ChannelSwitch into #if's:
>>
>> --- a/rotorng.c
>> +++ b/rotorng.c
>> @@ -333,7 +333,11 @@
>>int last_position_shown;
>>bool transfer;
>>  protected:
>> +#if VDRVERSNUM >= 10726
>>virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber, bool 
>> LiveView);
>> +#else
>> +  virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber);
>> +#endif
>>  public:
>>cStatusMonitor();
>>  };
>>
> 
> Are you sure? Its definitely in my copy and seems to be in the one on
> the projects site.

 There are two places: one in the class definition and one a few lines below 
that. Just search for "ChannelSwitch"... :)
 Line 336 and line 347.

Regards,
Lars.

> 
> Thanks
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-rotorng-0.3

[Lars Hanisch]

Hi,

Am 26.10.2012 14:12, schrieb Morfsta:
> Okay, updated version (0.3.1) has been uploaded to the VDR Projects site.
> 
> I have also fixed all the compilation warnings (at last)!

 rotorng.c, line 204:
  if (ActuatorDevice->SendDiseqcCmd(switch_cmds[KNr]))
  {
dsyslog("Failed to send diseqc command!\n");
return;
  }

 I think, it should be (missed a !)
  if (!ActuatorDevice->SendDiseqcCmd(switch_cmds[KNr]))
  {
dsyslog("Failed to send diseqc command!\n");
return;
  }

 Tomorrow I will do some more review, so be patient with a new release... :)
 This one isn't bad, just a failure debug message when there's no error.

Lars.

> 
> Thanks
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Betr: Re: emergency restart is too fast for my USB DVB-T receiver

[Lars Hanisch]

Hi,

Am 29.10.2012 20:17, schrieb cedric.dew...@telfort.nl:
> Hi Gerald,
> 
> I can't see that plugin for vdr 1.7-31:
> $ find -iname *dyn* 
> ./vdr-1.7.23/patches/opt-64_dynamite+unicable+lnbsharing.dpatch
> ./vdr-1.7.27/patches/opt-61_dynamite.patch
> 
> I have obtained the MPKGBUILD's for arch linux via this command:
> svn co https://archvdr.svn.sourceforge.net/svnroot/archvdr archvdr
> 
> How can I install this plugin?

 You find an updated patch for vdr 1.7.31 at Github:
 https://github.com/flensrocker/vdr-plugin-dynamite

 For vdr 1.7.31 I removed some backport compatibilities for older 1.7.x, so 
make sure you use a recent version of the
plugin. You'll find the vdr-patch at the patches-subdirectory.

Regards,
Lars.

> 
> Best regards,
> Cedric
> 
> 
> 
>> -- Oorspronkelijk bericht --
>> Date: Sun, 28 Oct 2012 21:54:54 +0100
>> From: Gerald Dachs 
>> To: VDR Mailing List 
>> Subject: Re: [vdr] emergency restart is too fast for my USB DVB-T receiver
>> Reply-To: VDR Mailing List 
>>
>>
>> Am 28.10.2012 20:50, schrieb cedric.dew...@telfort.nl:
>>> Hi All,
>>> The problem is that the kernel does not reinitialize the receiver until
>> nobody
>>> is using the device. reinitialize takes a few seconds, but vdr does not
>> release
>>> the device long enough for that to happen. The result is that vdr restarts
>>> many times.
>>
>> The dynamite plugin should handle this for you.
>>
>> Gerald
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
> 
>
> 
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] the great dynamite plugin ! :)

[Lars Hanisch]

Hi,

Am 29.10.2012 13:04, schrieb syrius...@no-log.org:
> Talking about dynamite,
> I'm using it because of my dvb-ttpci card and my usb dvb-t dongle.
> Their driver/firmware need to be reloaded from time to time.
> 
> There're 3 dvd-s cards and 1 dvb-t usb stick.
> I'm using the adapter_nr module feature to order the cards.
> - card 0 : WinTV-NOVA-HD-S2 (uses diseqc, can receive S28.2E and S19.2E)
> - card 1 : WinTV-NOVA-S (uses diseqc, can receive S28.2E and S19.2E)
> - card 2 : FF Rev. 1.5  (uses diseqc, can receive S28.2E) 
> - card 3 : rtl2832u 
> 
> I'm using udev rules to configure the timeout and to pass an argument
> to the timeout_handler.
> 
> I'm using vdr 1.7.30 atm, I've been observing one weird behaviour for
> quite a long time now:

 A ported patch for vdr 1.7.31 has been added to the git repository of dynamite:
 https://github.com/flensrocker/vdr-plugin-dynamite

 In the plugin itself I dropped support for older 1.7.x version, so maybe you 
have to switch to vdr 1.7.31 if possible
to debug this issue.

> after I watch a recording my dynamite-patched-vdr often reloads card
> #0 for no apparent reason.
> When the recording ends, i get a black screen instead of live tv.
> After the timeout my handler script detach the card from vdr, reloads
> the dvb driver and reattach the card.
> After the card is detached vdr automatically switches to another card,
> that's an expected behavior.
> After the card is reattached i can use femon to switch back to card
> #0: it's working again.

 Have you any logging from such a situation? dynamite is rather verbose so that 
may be helpful.
 Besides GetTS-timeout have you also set an idle-timeout?

> So you would say: buggy driver.
> 
> But lately i've been commenting out the driver reload part in my
> handler script: to fix the black screen you just have to detach the
> card from vdr then reattach it. (nothing more)
> 
> So I guess it's rather an issue with the dynamite patch, have you ever
> encountered it or a similar behavior ?

 Haven't seen such behaviour before, but I don't use this feature... :)
 When implemented I tested it with a DVB-USB-stick which I unplugged when a 
stream was in progress.

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] correct some includes at plugins

[Lars Hanisch]

Hi,

Am 20.10.2012 15:03, schrieb Lars Hanisch:
> Plugins should use
> 
> #include 
> 
>  and not
> 
> #include "vdr/..."

 Any reason, this didn't get into 1.7.32?
 Is it wrong or was it just missed? ;)
 It would help packaging plugins which needs headers of the dvb?ddevice-plugins.

 Here's a link to the patch:
 http://patchwork.linuxtv.org/patch/15069/

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] correct some includes at plugins

[Lars Hanisch]

Am 19.11.2012 00:20, schrieb Klaus Schmidinger:
> On 19.11.2012 00:03, Lars Hanisch wrote:
>> Hi,
>>
>> Am 20.10.2012 15:03, schrieb Lars Hanisch:
>>> Plugins should use
>>>
>>> #include 
>>>
>>>   and not
>>>
>>> #include "vdr/..."
>>
>>   Any reason, this didn't get into 1.7.32?
>>   Is it wrong or was it just missed? ;)
> 
> It's not wrong and it wasn't missed, either ;-)
> It's just somewhat further down the TODO list, and I wanted to
> have the new cutting code finally available for others to test
> and maybe debug.

 Ok, I'm fine with it. :)

Lars.

> 
> Klaus
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.32

[Lars Hanisch]

Hi,

Am 19.11.2012 08:51, schrieb Marx:
> Sorry for small off-topic but can you recommend editor which can edit TS 
> stream, mainly by cutting off adverts? Besides
> VDR I have Enigma based tuner and it saves TS stream, but differently from 
> VDR so I can't use VDR to edit.
> Marx

 I have a workflow (on Windows) which generates really good videos.
- demux with ProjectX
- cut with Cuttermaran
- mux with mencoder (to mpg actually)

 But this will work only with SD/mpeg2 material.

 TS-Doctor ist good for repairing HD-Streams and Smart Cutter seems to be an 
analog solution like Cuttermaran, but I
haven't tested it yet. Smart Cutter and Cuttermaran reencodes only the GOP with 
the cut out/in and leave the rest of the
stream  unchanged. They allow cutting even on B frames so you can remove ads 
and you won't recognize the cut afterwards.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Lars Hanisch]

Hi,

Am 26.11.2012 10:13, schrieb Oliver Schinagl:
> I'm thinking of getting into the whole satellite thing (DVB-T user for now) 
> and was searching for interesting DVB-S2
> tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. 
> While expensive you can connect up to 8
> tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). 
> While I know there is a octopus mini-pcie
> device, I heard that there where some PCB issues so decided on getting the 
> PCI-e version.
> 
> I have tried googling for some up to date linux! information but found very 
> little. Are there any l4m/dd octopus/duoflex
> DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current (and 
> past) experiences? The tuner (only 1
> dualtuner board and the octopus) will set you back a good 200Euro so I want 
> to be sure that the devices is properly
> supported.

 I'm using a DuoFlex with a DVB-C/T dual tuner modul. How to build the latest 
drivers is described here (german only):
 
http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/113367-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-sowie-tt-s2-6400-teil-2/

 If you'r using Ubuntu or yaVDR, there's the linux-media-dkms package with this 
driver included.
 My DVB-C/T card is working here for months with no problems. Second dual tuner 
is ordered... :)

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Lars Hanisch]

Hi,

Am 26.11.2012 20:10, schrieb Halim Sahin:
> On Mon, Nov 26, 2012 at 06:20:56PM +0100, Lars Hanisch wrote:
>>  My DVB-C/T card is working here for months with no problems. Second
>>  dual tuner is ordered... :)
> 
> What about cam support in vdr for this card???

 It's not implemented yet. You can however redirect the input of one tuner 
through the ci, so you can decrypt one
transponder.

 
http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p1048374-ci-unterst%C3%BCtzung-f%C3%BCr-cines2-mystique-satix-s2-dual-usw/#post1048374

 Note: the driver for the C/T dual tuner doesn't create different frontends for 
C and T, so removing the unused ones and
renaming the wanted ones isn't necessary anymore.

Lars.

> Regards
> Halim
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Lars Hanisch]

Hi,

Am 26.11.2012 21:24, schrieb Oliver Schinagl:
> Why build it externally? I was quite certain that the ddbridge drivers are in 
> mainline for a while now?
> Which modules to you select?

 ddbridge is upstream with DVB-S2 support, but not the driver for my C/T-module.

Lars.

> 
> On 11/26/12 18:20, Lars Hanisch wrote:
>> Hi,
>>
>> Am 26.11.2012 10:13, schrieb Oliver Schinagl:
>>> I'm thinking of getting into the whole satellite thing (DVB-T user for now) 
>>> and was searching for interesting DVB-S2
>>> tuners. I found that the l4m octopus/duoflex-s2 a very interesting device. 
>>> While expensive you can connect up to 8
>>> tuners! to a single PCI-e 1x lane (Bandwith should be more then enough). 
>>> While I know there is a octopus mini-pcie
>>> device, I heard that there where some PCB issues so decided on getting the 
>>> PCI-e version.
>>>
>>> I have tried googling for some up to date linux! information but found very 
>>> little. Are there any l4m/dd octopus/duoflex
>>> DVB-S2 (or even CAM/DVB-C/DVB-T) users here that can share their current 
>>> (and past) experiences? The tuner (only 1
>>> dualtuner board and the octopus) will set you back a good 200Euro so I want 
>>> to be sure that the devices is properly
>>> supported.
>>
>>   I'm using a DuoFlex with a DVB-C/T dual tuner modul. How to build the 
>> latest drivers is described here (german only):
>>  
>> http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/113367-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-sowie-tt-s2-6400-teil-2/
>>
>>
>>   If you'r using Ubuntu or yaVDR, there's the linux-media-dkms package with 
>> this driver included.
>>   My DVB-C/T card is working here for months with no problems. Second dual 
>> tuner is ordered... :)
>>
>> Lars.
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Lars Hanisch]

Hi,

Am 27.11.2012 11:03, schrieb Ralph Metzler:
> Oliver Schinagl writes:
>  > > The newer C/T modules use ST demods.
>  > > I think the DRX-K is also no longer being produced.
>  > I bought a Terratec dual T PCI-e which features two DRX-K demods. While 
>  > not the newest card, it's reasonably new and driver support is < 6 
> 
> More like > 6 year old card and driver. It only got remerged recently.
> 
>  > months old. I guess there's a huge batch of DRX-K's still being used up?
> 
> I guess but it is not being used on any new Digital Devices cards.
> 
>  > 
>  > What demod/tuner is being used on the DVB-S2 bit? Just to know the state 
>  > of support of the demod/tuner.
> 
> stv0900/stv6110

 My card uses stv0367dd, tda18212dd and cxd2099 from the repository I mentioned.
 No upstream support for now, but I would like to work at that. I will get in 
contact with the author soon, but since I
don't know anything yet about the driver model, I first want to read and 
understand the code.

Lars.

> 
> It uses the drivers stv090x and stv6110x which are also used by several 
> different cards from other manufacturers and are working very well.
> 
> Regards,
> Ralph
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Lars Hanisch]

Am 27.11.2012 10:46, schrieb Ralph Metzler:
> Halim Sahin writes:
>  > Hi,
>  > On Mon, Nov 26, 2012 at 09:20:30PM +0100, Lars Hanisch wrote:
>  > > Hi,
>  > > 
>  > > Am 26.11.2012 20:10, schrieb Halim Sahin:
>  > > > On Mon, Nov 26, 2012 at 06:20:56PM +0100, Lars Hanisch wrote:
>  > > >>  My DVB-C/T card is working here for months with no problems. Second
>  > > >>  dual tuner is ordered... :)
>  > > > 
>  > > > What about cam support in vdr for this card???
>  > > 
>  > >  It's not implemented yet. You can however redirect the input of one
>  > >  tuner through the ci, so you can decrypt one
>  > > transponder.
>  > 
>  > Well this is not good news for users in germany because without a
>  > working cam, you can't watch much channels with dvb-c.
>  > Don't know but I can't understand, why cam
>  > handling must be done in userspace for these new cards.
> 
> CI works fine with the redirect mentioned above. You do not need any 
> copying in userspace in this case. 
> 
> What could be supported, and this is not possible with any other DVB PCIe card
> hardware I know of, is that an encrypted stream is sent from 
> memory/hard disk/network to the CI and back for decryption.

 I started a plugin to get support of the CI (including MTD) into vdr. But for 
now no luck so far.
 I use the CAM handling of the vdr and write the TS packets to the sec device. 
But reading from it will block and
nothing will be decrypted. But I have to learn more about the whole CI/CAM 
stuff...

Lars.

> 
> Regards,
> Ralph
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

[Lars Hanisch]

Hi,

Am 27.11.2012 17:56, schrieb Halim Sahin:
> Hi,
> On Tue, Nov 27, 2012 at 10:46:31AM +0100, Ralph Metzler wrote:
>> Halim Sahin writes:
>>  > Hi,
>>  > On Mon, Nov 26, 2012 at 09:20:30PM +0100, Lars Hanisch wrote:
>>  > > Hi,
>>  > > 
>>  > > Am 26.11.2012 20:10, schrieb Halim Sahin:
>>  > > > On Mon, Nov 26, 2012 at 06:20:56PM +0100, Lars Hanisch wrote:
>>  > > >>  My DVB-C/T card is working here for months with no problems. Second
>>  > > >>  dual tuner is ordered... :)
>>  > > > 
>>  > > > What about cam support in vdr for this card???
>>  > > 
>>  > >  It's not implemented yet. You can however redirect the input of one
>>  > >  tuner through the ci, so you can decrypt one
>>  > > transponder.
>>  > 
>>  > Well this is not good news for users in germany because without a
>>  > working cam, you can't watch much channels with dvb-c.
>>  > Don't know but I can't understand, why cam
>>  > handling must be done in userspace for these new cards.
>>
>> CI works fine with the redirect mentioned above. You do not need any 
>> copying in userspace in this case. 
> 
> Well the interface to decrypt an incoming encrypted stream differs from
> other available dvb devices with ci.
> In this case vdr needs to support two diferent ci systems.
> Sending an encrypted stream from memory back to ci and get the decrypted
> stream is nice to have but not the main use case for a dvb card.
> In vdr-portal.de are some posts that redirects using szap czap etc and a
> ci works. Q: is there a working solution for vdr as well?

 If you use the redirect parameter and you take care that the frontend, demux, 
dvr and ca have the same device numbers,
then vdr can decrypt channels on that device without any changes to vdr or in 
need of any plugins.

 But you only will be able to decrypt one transponder. Theoretically the CI is 
able to decrypt multiple transponders,
but for that, vdr has to be extended with some patch and a plugin. I'm afraid 
there isn't such a plugin at the moment.

Lars.

> Regards
> Halim
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] get a segmentation fault when starting vdr (backtrace included)

[Lars Hanisch]

Hi,

Am 29.11.2012 16:17, schrieb Dieter Bloms:
> Hello,
> 
> I've compiled vdr on alpinelinux 2.5.0 and get a segfault during
> start of vdr.
> Even without plugins I get this segfault (I didn't apply any patch to
> vdr sources).
> Vdr was started with the command:
> 
> /usr/local/bin/vdr --config=/etc/vdr --epgfile=/tmp/epg.data --grab=/dev/shm 
> --log=3.1 --mute --no-kbd --user=root --video=/remote/vdr/
> 
> I've made a backtrace with gdb:
> 
> --snip--
> vdrservernew:/tmp# gdb --core core /usr/local/bin/vdr
> GNU gdb (GDB) 7.5
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/local/bin/vdr...done.
> [New LWP 26493]
> [New LWP 26492]
> [New LWP 26494]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> Core was generated by `/usr/local/bin/vdr --config=/etc/vdr 
> --epgfile=/tmp/epg.data --grab=/dev/shm --'.
> Program terminated with signal 11, Segmentation fault.
> #0  skipspace (s=0x4080 ) at tools.h:196
> 196   if ((uchar)*s > ' ') // most strings don't have any leading space, 
> so handle this case as fast as possible
> (gdb) bt
> #0  skipspace (s=0x4080 ) at tools.h:196
> #1  isempty (s=0x4080 ) at tools.c:249
> #2  0x004a1eb9 in FromString (s=0x2e531d2 "1 01 deu 4:3", 
> this=0x2e4aba0) at epg.c:36

 Looks like the pointer returned by sscanf is not valid:

32: bool tComponent::FromString(const char *s)
33: {
34:   unsigned int Stream, Type;
35:   int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type, language, 
&description); // 7 = MAXLANGCODE2 - 1
36:   if (n != 4 || isempty(description)) {
37:  free(description);
38:  description = NULL;
39:  }
40:   stream = Stream;
41:   type = Type;
42:   return n >= 3;
43: }

 What I would do:
- set description to NULL before the sscanf
- log all values returned by sscanf and compare it with the given string

 Maybe a problem/different behaviour in the uClibc?

Lars.

> #3  cComponents::SetComponent (this=, Index=0, 
> s=s@entry=0x2e531d2 "1 01 deu 4:3") at epg.c:81
> #4  0x004a40f3 in cEvent::Parse (this=0x2e43360, s=) 
> at epg.c:495
> #5  0x004e9ea6 in cRecordingInfo::Read (this=0x2e2d110, 
> f=f@entry=0x2e2c330) at recording.c:468
> #6  0x004eb4e3 in cRecording::cRecording (this=0x2e2c650, 
> FileName=0x2e4c15c "Sex_and_the_City_2/2012-11-19.20.10.27-0.rec") at 
> recording.c:723
> #7  0x004eceb1 in cRecordings::ScanVideoDir (this=0x7fe7c0 
> , DirName=0x2e412b0 "/remote/vdr/Sex_and_the_City_2", 
> Foreground=false, LinkLevel=0) at recording.c:1165
> #8  0x004ed32c in cRecordings::ScanVideoDir (this=0x7fe7c0 
> , DirName=0x2e25ff0 "/remote/vdr", Foreground=false, LinkLevel=0) 
> at recording.c:1180
> #9  0x0052694e in cThread::StartThread (Thread=0x7fe7e0 
> ) at thread.c:262
> #10 0x6e6b7ce69406 in start_thread () from /lib/libpthread.so.0.9.32
> #11 0x6e6b7ce61885 in clone () from /lib/libpthread.so.0.9.32
> #12 0x in ?? ()
> --snip--
> 
> does anybody see what is wrong here ?
> 
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] get a segmentation fault when starting vdr (backtrace included)

[Lars Hanisch]

Am 30.11.2012 11:32, schrieb Gerald Dachs:
> Am 2012-11-30 10:17, schrieb Lars Hanisch:
>>  Looks like the pointer returned by sscanf is not valid:
>>
>> 32: bool tComponent::FromString(const char *s)
>> 33: {
>> 34:   unsigned int Stream, Type;
>> 35:   int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type,
>> language, &description); // 7 = MAXLANGCODE2 - 1
>> 36:   if (n != 4 || isempty(description)) {
>> 37:  free(description);
>> 38:  description = NULL;
>> 39:  }
>> 40:   stream = Stream;
>> 41:   type = Type;
>> 42:   return n >= 3;
>> 43: }
> 
> From man sscanf:
> 
>The GNU C library supports a nonstandard extension that causes the 
> library to
>dynamically allocate a string of sufficient size for input strings for 
> the %s
>and %a[range] conversion specifiers.
> 
> This is the reason why it doesn't work with ulibc.

 Then there should be a malloc or something similiar for description:

32: bool tComponent::FromString(const char *s)
33: {
34:   unsigned int Stream, Type;
  description = malloc(strlen(s));
  description[0] = 0;
35:   int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type, language, 
&description); // 7 = MAXLANGCODE2 - 1
36:   if (n != 4 || isempty(description)) {
37:  free(description);
38:  description = NULL;
39:  }
40:   stream = Stream;
41:   type = Type;
42:   return n >= 3;
43: }

 A check for description != NULL before the free call is not needed.

 But this is not the only place in the vdr code, where %a is used...

Lars.
> 
> Gerald
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] small typo in skin.h

[Lars Hanisch]

Hi,

Just a small typo, for the sake of complete- and correctness... :)

Lars.
diff --git a/skins.h b/skins.h
index f716448..163eaef 100644
--- a/skins.h
+++ b/skins.h
@@ -49,7 +49,7 @@ public:
 
 class cSkinDisplayChannel : public cSkinDisplay {
///< This class is used to display the current channel, together with
-   ///< the present and following EPG even. How and to what extent this
+   ///< the present and following EPG event. How and to what extent this
///< is done is totally up to the derived class.
 public:
   virtual void SetChannel(const cChannel *Channel, int Number) = 0;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Lars Hanisch]

Am 28.12.2012 16:38, schrieb Klaus Schmidinger:
> So should we go back to the Makefiles of version 1.7.33 and declare this
> area of the program source "untouchable" forever?
> Maybe this would be the easiest solution, and I wouldn't get bashed, offended
> and insulted that much any more.
> 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 and utter failure...
> 
> Beware - I'm not kidding about this! If this whining keeps going on, I will
> switch back to version 1.7.33 Makefiles, and I won't dare touch them again
> any time soon! After all, I didn't make this change because *I* wanted it...

 Building plugins outside the vdr source tree with the new Makefile is 
something I bear with the "current mess".
 I'm no Makefile-guru, so I have to "live with it" and I can't contribute to 
this thing at all.

 My personal development environment is a "vdr source tree with plugins".
 If I do development on a vdr-patch, I just call "make" and have the output 
(and errors/warnings) of the compiler right
there.
 If I work on a plugin I have a separate shell in the plugin's directory where 
I call "make". If it's ready for testing,
I call "make all plugins" from the vdr directory. In the directory above ("..") 
I have a script which starts the current
vdr with the settings for my development (other config directory etc.).

 Now a "make" compiles everything and I have to scroll a lot to get the 
warnings or errors.

 Perhaps we should talk about what targets are needed and what they should do. 
"Never touch a running system" only
applies to productive environments, not for development. Without touching there 
would be no progress.

 So please stop "whining" and let's do some work together!

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Lars Hanisch]

Am 01.01.2013 13:40, schrieb Luca Olivetti:
> Al 30/12/12 01:08, En/na Christopher Reimer ha escrit:
> 
>>
>> I don't consider the mailinglist as "central spot of developement".
>> Here I'm forced to speak English. Almost all VDR Users are German. And
>> in VDR-Portal I reach the critical mass. With the addition that I am
>> allowed to speak my native language.
> 
> Oh, if vdr is only intended for german speaking users, is there a good 
> alternative for the rest of us?

 It's not, noone said that.

 I (as a german) am sad, but can understand, that posting at vdr-portal in 
english is something complicated (or whatever
the right word is, usually I write mails in english with dict.leo.org in an 
open browser).
 And I'm also sad, that many "vdr-gurus" are just active at vdr-portal and not 
at this mailing list. The older ones of
us (I'm nearly 40 and think that I'm between the "young, wild ones" and "the 
wise elder" :-), tending to the older ones
as I'm using computers since 25 years now) have grown up with mailing lists, 
newsgroups etc. For the younger ones (I
don't want to flame anybody, just want to show a cliche) the "Internet" is 
equivalent to WWW. So they have grown up with
forums like vdr-portal.
 I must confess that normally threads at a forum are easier to read and 
understand as mailing list threads in any
mail-archive. First you have to found such an archive (or have to know that 
something like that even exists) and then
it's complicated to search or even browse the archive (monthly indexes etc.).

 This is an invitation: Please create more posts in english at vdr-portal! If a 
critical mass is passed it will be
easier for the ones coming past us. Sure there's only a small "international" 
part, but it is there. And of course there
will be "idiots", you got them everywhere, even at this mailing list. :)
 I promise if I have something valuable to say to an question asked in english 
I will give my best and will answer it.

 But I can't do it on my own, please help me.

 Happy New Year BTW... :) Maybe this will be a New Year'S pledge for some of 
us...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Lars Hanisch]

Am 02.01.2013 19:19, schrieb Vidar Tyldum:
> Den 02.01.2013 15:54, skrev Morfsta:
>> Perhaps a sticky at the top of the forum discussing and encouraging
>> the use of English for non-German speaking users would help and giving
>> some guidance on the best way to approach it, so as to avoid flames.
> 
> Yes, please! Or just "It's OK to post in English / Es sind OK zum Englisch
> schreibe"
> 
> (the German part is probably horribly wrong, but it's all I remember from my
> German class many winters ago... ;)

 "Es ist OK, in Englisch zu schreiben", just to fresh up your mind... :)

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] half-viewed recordings, can they be moved at the top of the list?

[Lars Hanisch]

Hi,

Am 06.01.2013 11:31, schrieb cedric.dew...@telfort.nl:
> Sometimes I watch a TV show halfway. Then I let VDR shutdown my PC. Then
> I would like to watch the rest of the show. Then I have to go to the list
> of TV shows, and find the correct one again.
> 
> In my opinion it would be easyer for me if the half-watched shows are placed
> at the top of the list with TV shows. Does such an option exist? How should
> recordings in a sub-folder be handled? Should those be moved to the top of
> the list, or copied, or a shortcut be made? I would like to see a shortcut.
> 
> I would also like to see that VDR remembers the current position in the list
> of recordings. This is already the case during a vdr-sxfe session, but not
> when vdr has been restarted. After a restart, VDR goes to the top of the
> list.
> 
> Or I should not have so many recordings :-)

 It's possible to write a plugin "lastviewed" (if not already exist) which 
tracks for cStatus::Replaying and remember
the replayed recodings in an internal list. With the main menu entry of this 
plugin you can either show the list or just
replay the last recording.
 So no need to extend vdr-core. :)

Lars.

> 
> Best regards,
> Cedric   
> 
>
> 
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] half-viewed recordings, can they be moved at the top of the list?

[Lars Hanisch]

Hi,

Am 06.01.2013 12:33, schrieb Mika Laitio:
> On 01/06/2013 12:31 PM, cedric.dew...@telfort.nl wrote:
>> Hi All,
>>
>> Sometimes I watch a TV show halfway. Then I let VDR shutdown my PC. Then
>> I would like to watch the rest of the show. Then I have to go to the list
>> of TV shows, and find the correct one again.
>>
>> In my opinion it would be easyer for me if the half-watched shows are placed
>> at the top of the list with TV shows. Does such an option exist? How should
>> recordings in a sub-folder be handled? Should those be moved to the top of
>> the list, or copied, or a shortcut be made? I would like to see a shortcut.
> 
> Maybe by extending the current functionality of "0" key that can be used
> for sorting the recordings either by name or date.

 I don't think this is the right way since the order of recordings is per 
directory and the last viewed recording may be
in some (deep) subdirectory. And I don't see any "last viewed timestamp" at the 
recording info. Only hint would be the
timestamp of the resume file.

Lars.

> 
> Mika

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] half-viewed recordings, can they be moved at the top of the list?

[Lars Hanisch]

Hi,

Am 06.01.2013 17:49, schrieb VDR User:
> Maybe VDR should have 3 flags instead of * (unviewed) and no-*
> (viewed). Instead maybe we could have:
> 
> no-*: viewed
> !: partially viewed
> *: new/unviewed

 Every uncut recording will be partially viewed...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] another more or less useless plugin: avahi4vdr

[Lars Hanisch]

Homepage: https://github.com/flensrocker/vdr-plugin-avahi4vdr

What is it:
It's a helper, so you can easily announce network services of your vdr and its 
plugins to your LAN via avahi (a Zeroconf
implementation) or retrieve information about other network services (not 
limited to vdr such as nfs mounts etc.).
Please read the README at
https://github.com/flensrocker/vdr-plugin-avahi4vdr/blob/master/README

I'm trying very hard to keep my README up-to-date. If there are questions 
please let me know.
Please get familiar with Avahi, the avahi-tools like avahi-browse, 
avahi-publish and their manpages.

How does it work:
The "static way" is using a file "services.conf" in the plugin's config 
directory. For an example please look at
 
https://github.com/flensrocker/vdr-plugin-avahi4vdr/blob/master/examples/services.conf

 Please forgive my long post... :)

Server-Example: How to announce streamdev-server
 (aka announcing a static network service with fixed port)
# line in services.conf, for syntax and escaping see README
name=vdr-streamdev-server on 
%h,type=_http._tcp,port=3000,subtype=_vdr_streamdev_server._sub._http._tcp

name: is something to display to the user (%h will be replaced with the 
hostname)
type: is the service type, there are standards, look at 
http://www.dns-sd.org/ServiceTypes.html
port: the port the service is listening on (handy for dynamic ports, since you 
can update the service on the fly and
reannounce a new port, but sadly not in this static example, you have to use 
the plugin's SVDRPCommand "CreateService"
for more control)
subtype: you can specify details of the service, streamdev is on the lowest 
level a webserver, hence the type
_http._tcp, but will publish special services with another "protocol", I 
suggest "_vdr_.sub." if it's for a vdr plugin. You can specify as many subtypes as you want.
txt: you can add as many txt records to a service with service specific data 
(not used in this example, if you know
avahi, you'll understand).

On vdr startup, avahi4vdr connects to the avahi-daemon and will announce the 
streamdev-server. What for? Read next. :)

Example: How to find streamdev-server
 (suggestion as extension to streamdev-client, feel free to implement)
I will create a patch as soon as I can find time and really do need this 
fetaure at streamdev...

You can call avahi4vdr's SVDRPCommand directly for registering a browser for 
services:

  int replyCode = 0;
  cString browserId; // remember this!
  cPlugin *avahi4vdr = cPluginManager::GetPlugin("avahi4vdr");
  ...
  if (avahi4vdr != NULL)
 browserId = avahi4vdr->SVDRPCommand("CreateBrowser",
"caller=streamdev-client,protocol=IPv4,type=_vdr_streamdev_server._sub._http._tcp",
 replyCode);
  ...

If you don't need the browser anymore you can delete it anytime (will be done 
automatically on vdr-exit).
  ...
  if (avahi4vdr != NULL)
 avahi4vdr->SVDRPCommand("DeleteBrowser", *browserId, replyCode);
  ...

Your plugin's Service function will be called if the browser raises an event:
  bool cPluginDbus2vdr::Service(const char *Id, void *Data)
  {
if (strcmp(Id, "avahi4vdr-event") == 0) {
   cAvahiHelper options(Data);
   const char *event = options.Get("event");
   const char *browser_id = options.Get("id");
   if (strcmp(event, "browser-service-resolved") == 0) {
  const char *name = options.Get("name");
  const char *host = options.Get("host");
  const char *protocol = options.Get("protocol");
  const char *address = options.Get("address");
  const char *port = options.Get("port");
  const char *local = options.Get("local");
  const char *txt = NULL;
  int txt_nr = 0;
  while (true) {
txt = options.Get("txt", txt_nr);
if (txt == NULL)
   break;
...
txt_nr++;
}
  ...
  }
   else if (strcmp(event, "browser-service-removed") == 0) {
  const char *name = options.Get("name");
  const char *protocol = options.Get("protocol");
  const char *local = options.Get("local");
  ...
  }
   return true;
   }
return false;
  }

cAvahiHelper is located at 
https://github.com/flensrocker/vdr-plugin-avahi4vdr/blob/master/avahi-helper.h
It's a helper class for parsing parameters, only header is needed, so just copy 
it to your plugin.

caller: (at CreateBrowser) the name of the plugin which should be called. You 
needn't to take your plugin's name. It's
possible to create browsers for other plugins. It's not a bug, it's a feature. 
:)

Whenever the browser detects a new service, an event "browser-service-resolved" 
is emitted. streamdev-client should
instantiate a new device for each detected server (or reuse an unconnected 
device, multi-device support should be added
first to streamdev-client) and if a server shuts down (event 
"browser-service-removed") the corresponding device

Re: [vdr] projects.vdr-developer.org - scheduled maintenance on Saturday/Sunday

[Lars Hanisch]

Am 10.01.2013 21:32, schrieb Tobi:
> Hi everyone!
> 
> On Saturday/Sunday (2013-01-12 / 2013-01-13) I will run a lot of upgrades
> on the server.
> 
> The Redmine projects might be offline for some hours but the Git
> repositories will still be accessible.
> 
> Sorry for any inconveniences! I'll try to keep the downtime as short as
> possible.

 Take the time you need and thanks for your work!

Lars.

> 
> bye,
> 
> Tobias
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Does anyone see this or is the VDR mailing list broken?

[Lars Hanisch]

Am 07.02.2013 00:40, schrieb VDR User:
> A few people have expressed concern now so I'm sending a test posting out.

 Everything fine here, last post was from 2013-01-31...
 Or have I missed something...? :)

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Red button inconsistency

[Lars Hanisch]

Am 10.02.2013 11:17, schrieb Klaus Schmidinger:
> On 10.02.2013 11:04, Ludi wrote:
>> Hi,
>>
>> For the following, I am assuming that the functions of color buttons of
>> the remote control of the VDR shipping with yavdr have not been
>> modified compared to the original VDR.  (otherwise, I am filing this at
>> the wrong place)
>>
>> The VDR uses the red button of the remote control for
>> various timer related functions. For example, the red button sets a
>> timer in when the epg is displayed, it toggles a timer from active to
>> inactive in the timers list...
>>
>> However, to toggle a timer from active
>> to inactive in the conflict catcher window, one has to use the green
>> button. Would it not be more straightforward to use the red button to
>> also toggle the timers in the conflict catcher view?
>>
>> Thanks in advance for taking it into account.
> 
> Just for the record: the "conflict catcher view" is not part of plain vanilla 
> VDR.

 It's part of extrecmenu, I think.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Red button inconsistency

[Lars Hanisch]

Am 10.02.2013 16:59, schrieb VDR User:
> On Sun, Feb 10, 2013 at 5:17 AM, Lars Hanisch  wrote:
>>>> However, to toggle a timer from active
>>>> to inactive in the conflict catcher window, one has to use the green
>>>> button. Would it not be more straightforward to use the red button to
>>>> also toggle the timers in the conflict catcher view?
>>>>
>>>> Thanks in advance for taking it into account.
>>>
>>> Just for the record: the "conflict catcher view" is not part of plain 
>>> vanilla VDR.
>>
>>  It's part of extrecmenu, I think.
> 
> I thought it's part of epgsearch.

 I think you're right. :)

 I use my vdr mainly via live-plugin, so I'm not very firm with the OSD...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.37

[Lars Hanisch]

Hi,

 Found some weird file in the tarball: menu.cyVkmHd

Lars.

Am 09.02.2013 15:35, schrieb Klaus Schmidinger:
> VDR developer version 1.7.37 is now available at
> 
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.37.tar.bz2
> 
> A 'diff' against the previous version is available at
> 
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.36-1.7.37.diff
> 
> MD5 checksums:
> 
> 602dc7e678bcfcf075da36344a337562  vdr-1.7.37.tar.bz2
> 34e953fcffc112f316cbfc1f53915324  vdr-1.7.36-1.7.37.diff
> 
> WARNING:
> 
> 
> This is a *developer* version. Even though *I* use it in my productive
> environment. I strongly recommend that you only use it under controlled
> conditions and for testing and debugging.
> 
> Approaching version 2.0.0:
> ==
> 
> If all goes well, there should be no more functional or API changes
> before the final version 2.0.0. There will just be a few more fixes.
> 
> 
> The changes since version 1.7.36:
> 
> - Now also using FindHeader() in cMpeg2Fixer::AdjTref() (pointed out by Sören 
> Moch).
> - Added missing template for DVBDIR to Make.config.template (reported by 
> Derek Kelly).
> - The LCARS menu now also works if the OSD has only 1bpp (two colors).
> - Fixed possible garbage in the remaining time of the LCARS replay display in 
> case the
>   hours change from two to one digit.
> - Fixed upscaling bitmaps. The last row and column of the scaled bitmap was 
> not filled,
>   which resulted in empty lines between scaled subtitles.
> - Fixed a leftover line in case a two line subtitle was followed by a one line
>   subtitle on the dvbhddevice in "high level" OSD mode.
> - Returning 0 from cDvbSdFfDevice::NumProvidedSystems() if option 
> --outputonly is given.
> - The index file is now closed after initially reading it if it is older than 
> 3600 seconds.
> - Improved responsiveness during replay when close to the recording's end.
> - Fixed a leftover progress display in the LCARS main menu when replay of a 
> recording
>   ends while the menu is open, and the live channel has no EPG information.
> - Fixed possible audio chatter when a recording is replayed to its very end.
> - Added dependency on 'i18n' to 'install-i18n' in the VDR Makefile (thanks to 
> Tobias
>   Grimm).
> - Changed several calls to Skins.Message() in vdr.c to Skins.QueueMessage() 
> in order to
>   avoid a black screen while such a message is displayed in case the channel 
> will be
>   switched (reported by Uwe Scheffler).
> - Updated the Slovakian language texts (thanks to Milan Hrala).
> - Improved LIRC timing for repeat function.
> - When pausing live video, the current audio and subtitle tracks are now 
> retained.
> - Added some notes about plugin Makefiles to PLUGINS.html.
> - Avoiding an extra key press event if the repeat function kicks in when 
> controlling
>   VDR via the PC keyboard.
> - The new options "Setup/Miscellaneous/Remote control repeat delay" and
>   "Setup/Miscellaneous/Remote control repeat delta" can be used to adjust the
>   behavior of the remote control in case a key is held pressed down for a 
> while, so
>   that the repeat function kicks in (see MANUAL).
>   The builtin LIRC and KBD remote controls already use these parameters. It is
>   recommended that plugins that implement an interface to any kind of remote 
> controls
>   also use the parameters Setup.RcRepeatDelay and Setup.RcRepeatDelta for the 
> desired
>   purpose, and remove any setup options they might have that serve the same 
> purpose.
> - cTimer no longer does any special "VFAT" handling to shorten directory 
> names to 40
>   characters. When a string is used as a directory name for a recording, the 
> maximum
>   length of the directory path, as well as the individual directory names, is 
> now
>   limited to the values specified by the new command line option --dirnames 
> (see
>   man vdr(1) for details). For backwards compatibility the option --vfat is 
> still
>   available and has the same effect as --dirnames=250,40,1.
> - The macro MaxFileName is now obsolete and may be removed in future 
> versions. Use
>   NAME_MAX directly instead.
> - There is no more fixed limit to the maximum number of cPixmap objects an 
> OSD can
>   create. However, a particular device may still be unable to create an 
> arbitrary
>   number of pixmaps, due to limited resources. So it's always a good idea to 
> use
>   as few pixmaps as possible.
> - Fixed formatting and removed some superfluous break statements in vdr.c's 
> command
>   line option switch.
> 
> Have fun!
> 
> Klaus
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] bug in channels.conf.terr?

[Lars Hanisch]

Hi,

 https://bugs.launchpad.net/ubuntu/+source/vdr/+bug/45721

 In the Debian package (and Ubuntu of course) is a patch included, which 
removes the following line from channels.conf.terr:

 Ch 14 (TV):481833:I0C23D0M64B8T2G32Y0:T:27500:2840:2841:2843:0:0:8800:0:0

 Can anybody confirm, this line is invalid?
 Which will be the right line?

 Would nice to get rid off this patch or have a valid channels.conf.terr 
upstream... :)

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] bug in channels.conf.terr?

[Lars Hanisch]

Am 10.02.2013 22:32, schrieb Klaus Schmidinger:
> On 10.02.2013 21:47, Lars Hanisch wrote:
>> Hi,
>>
>>   https://bugs.launchpad.net/ubuntu/+source/vdr/+bug/45721
>>
>>   In the Debian package (and Ubuntu of course) is a patch included, which 
>> removes the following line from
>> channels.conf.terr:
>>
>>   Ch 14 (TV):481833:I0C23D0M64B8T2G32Y0:T:27500:2840:2841:2843:0:0:8800:0:0
>>
>>   Can anybody confirm, this line is invalid?
>>   Which will be the right line?
>>
>>   Would nice to get rid off this patch or have a valid channels.conf.terr 
>> upstream... :)
> 
> Maybe I should completely remove all channels.conf* files from the
> source archive? The existing ones are already rather old, and I can't
> possibly keep them up to date, anyway.
> 
> Any opinions?

 I don't use them, so no objections from me.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] bug in channels.conf.terr?

[Lars Hanisch]

Am 11.02.2013 13:12, schrieb Klaus Schmidinger:
> On 11.02.2013 12:54, Gerald Dachs wrote:
>> Am 2013-02-11 12:40, schrieb Klaus Schmidinger:
>>> On 11.02.2013 05:04, VDR User wrote:
 On Sun, Feb 10, 2013 at 1:32 PM, Klaus Schmidinger
  wrote:
> Maybe I should completely remove all channels.conf* files from the
> source archive? The existing ones are already rather old, and I can't
> possibly keep them up to date, anyway.

 If they're not going to be kept up-to-date then they don't really
 serve any purpose since an outdated channels.conf is useless. People
 will just have to channel scan themselves anyways so why bother
 keeping outdated files in the source? I see no harm in removing them.
>>>
>>> On second thought, I guess I won't touch that area at this time, so
>>> close to version 2.0. I'll drop these files after version 2.0, once
>>> automatic transponder scanning will be implemented.
>>
>> In this case it would be a good idea to delete this line Lars mentioned from 
>> channel.conf.terr that lets the vdr crash.
> 
> I just tried that line with my VDR. It gives me an "Error in channel 
> settings", but
> it doesn't crash. Does it actually *crash* for you?

 Not for me, I just stumbled over this patch in the debian package and the old 
entry in the Ubuntu bug tracker.
 The original poster can't start his vdr with this line, but I think it will 
not crash.

 So whatever, if it gets removed, everything should be fine. :)

Lars.

> Anyway, I'll remove that line.
> 
> Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] Suggest naming central plugin make config as plugin.mk.

[Lars Hanisch]

Am 16.02.2013 19:33, schrieb Ville Skyttä:
> Makes it clearer that it's a Makefile snippet, distinguishes from VDR
> conf files. Reposted here per Klaus' request, he'd like to see 3
> people ack this.

 PLGCFG is new, has anyone used it so far?
 I have no objections.

Acked-by: Lars Hanisch 

Regards,
Lars.

> ---
>  Make.config.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Make.config.template b/Make.config.template
> index b02d796..5bd0a10 100644
> --- a/Make.config.template
> +++ b/Make.config.template
> @@ -62,7 +62,7 @@ endif
>  
>  # Use this if you want to have a central place where you configure compile 
> time
>  # parameters for plugins:
> -#PLGCFG = $(CONFDIR)/plugins.conf
> +#PLGCFG = $(CONFDIR)/plugins.mk
>  
>  ### The remote control:
>  
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] No data in 8 seconds, queuing no signal image

[Lars Hanisch]

Am 27.02.2013 16:23, schrieb Peter Münster:
> Hi,
> 
> Sometimes, when starting VDR, I get this message:
> "[input_vdr] No data in 8 seconds, queuing no signal image"
> And no video.
> 
> When switching channels of the same transponder, nothing happens. But
> switching to a channel of another transponder (channel 7), video comes
> back.
> 
> How could I avoid this problem please, when VDR starts automatically to
> start a recording?

 I don't know if it works, but you can configure vdr to start with always the 
same channel (which you'll never use for a
recording) so that it has to switch explicitly when starting the recording.

Lars.

> 
> Here some log messages:
> 
> --8<---cut here---start->8---
> Feb 25 21:00:03 media vdr: [2916] [input_vdr] No data in 8 seconds, queuing 
> no signal image
> Feb 26 15:14:17 media vdr: [0] [xine..put] cXinelibOsd::CanHandleAreas(): 
> Device does not support ARGB
> Feb 26 15:14:18 media vdr: [0] switching to channel 1
> Feb 26 15:14:18 media vdr: [0] [input_vdr] vdr_flush_engine: playback is 
> paused <0>
> Feb 26 15:14:18 media vdr: [11133] TS buffer on device 2 thread ended 
> (pid=0, tid=11133)
> Feb 26 15:14:18 media vdr: [11132] buffer stats: 188 (0%) used
> Feb 26 15:14:18 media vdr: [11132] receiver on device 2 thread ended 
> (pid=0, tid=11132)
> Feb 26 15:14:18 media vdr: [11129] [demux_vdr] PMT changed, resetting demuxer
> Feb 26 15:14:18 media vdr: [11145] receiver on device 2 thread started 
> (pid=0, tid=11145, prio=high)
> Feb 26 15:14:18 media vdr: [11146] TS buffer on device 2 thread started 
> (pid=0, tid=11146, prio=high)
> Feb 26 15:14:22 media vdr: [0] switching to channel 2
> Feb 26 15:14:22 media vdr: [0] [input_vdr] vdr_flush_engine: playback is 
> paused <0>
> Feb 26 15:14:22 media vdr: [11146] TS buffer on device 2 thread ended 
> (pid=0, tid=11146)
> Feb 26 15:14:22 media vdr: [11145] buffer stats: 0 (0%) used
> Feb 26 15:14:22 media vdr: [11145] receiver on device 2 thread ended 
> (pid=0, tid=11145)
> Feb 26 15:14:22 media vdr: [11129] [demux_vdr] PMT changed, resetting demuxer
> Feb 26 15:14:22 media vdr: [11147] receiver on device 2 thread started 
> (pid=0, tid=11147, prio=high)
> Feb 26 15:14:22 media vdr: [11148] TS buffer on device 2 thread started 
> (pid=0, tid=11148, prio=high)
> Feb 26 15:14:27 media vdr: [0] switching to channel 3
> Feb 26 15:14:27 media vdr: [0] [input_vdr] vdr_flush_engine: playback is 
> paused <0>
> Feb 26 15:14:27 media vdr: [11148] TS buffer on device 2 thread ended 
> (pid=0, tid=11148)
> Feb 26 15:14:27 media vdr: [11147] buffer stats: 0 (0%) used
> Feb 26 15:14:27 media vdr: [11147] receiver on device 2 thread ended 
> (pid=0, tid=11147)
> Feb 26 15:14:27 media vdr: [11129] [demux_vdr] PMT changed, resetting demuxer
> Feb 26 15:14:27 media vdr: [11149] receiver on device 2 thread started 
> (pid=0, tid=11149, prio=high)
> Feb 26 15:14:27 media vdr: [11150] TS buffer on device 2 thread started 
> (pid=0, tid=11150, prio=high)
> Feb 26 15:14:30 media vdr: [0] switching to channel 4
> Feb 26 15:14:30 media vdr: [0] [input_vdr] vdr_flush_engine: playback is 
> paused <0>
> Feb 26 15:14:30 media vdr: [11150] TS buffer on device 2 thread ended 
> (pid=0, tid=11150)
> Feb 26 15:14:30 media vdr: [11149] buffer stats: 188 (0%) used
> Feb 26 15:14:30 media vdr: [11149] receiver on device 2 thread ended 
> (pid=0, tid=11149)
> Feb 26 15:14:30 media vdr: [11129] [demux_vdr] PMT changed, resetting demuxer
> Feb 26 15:14:30 media vdr: [11151] receiver on device 2 thread started 
> (pid=0, tid=11151, prio=high)
> Feb 26 15:14:30 media vdr: [11152] TS buffer on device 2 thread started 
> (pid=0, tid=11152, prio=high)
> Feb 26 15:14:32 media vdr: [0] switching to channel 5
> Feb 26 15:14:32 media vdr: [0] [input_vdr] vdr_flush_engine: playback is 
> paused <0>
> Feb 26 15:14:32 media vdr: [11152] TS buffer on device 2 thread ended 
> (pid=0, tid=11152)
> Feb 26 15:14:32 media vdr: [11151] buffer stats: 0 (0%) used
> Feb 26 15:14:32 media vdr: [11151] receiver on device 2 thread ended 
> (pid=0, tid=11151)
> Feb 26 15:14:32 media vdr: [11129] [demux_vdr] PMT changed, resetting demuxer
> Feb 26 15:14:32 media vdr: [11153] receiver on device 2 thread started 
> (pid=0, tid=11153, prio=high)
> Feb 26 15:14:32 media vdr: [11154] TS buffer on device 2 thread started 
> (pid=0, tid=11154, prio=high)
> Feb 26 15:14:34 media vdr: [0] switching to channel 6
> Feb 26 15:14:34 media vdr: [0] [input_vdr] vdr_flush_engine: playback is 
> paused <0>
> Feb 26 15:14:34 media vdr: [11154] TS buffer on device 2 thread ended 
> (pid=0, tid=11154)
> Feb 26 15:14:34 media vdr: [11153] buffer stats: 0 (0%) used
> Feb 26 15:14:34 media vdr: [11153] receiver on device 2 thread ended 
> (pid=0, tid=11153)
> Feb 26 15:14:34 media vdr: [11129] [demux_vdr] PMT changed, resetting

Re: [vdr] Femon plugin build failed against vdr-1.7.40

[Lars Hanisch]

Am 10.03.2013 18:01, schrieb YUP:
> Hi, I tried to build femon 1.7.18 against vdr 1.7.40 and got the following 
> log:
> ==> Starting build()...
> g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC 
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"femon"'  -o 
> femonosd.o femonosd.c
> femonosd.c: In member function 'void cFemonOsd::DrawInfoWindow()':
> femonosd.c:475:20: error: 'class cDvbTransponderParameters' has no member 
> named 'PlpId'
> make: *** [femonosd.o] Error 1
> ==> ERROR: A failure occurred in build().
> Aborting...
> Rolf, could you fix it, please?

 PlpId has been renamed to StreamId.

 - Renamed the "plp id" to a more general "stream id" and added support for 
DVB-S2
   "Input Stream Identifier" (ISI) (based on a patch from Rolf Ahrenberg).
   With this VDR now supports "multi streaming" on DVB-S2 and DVB-T2 
transponders.

Regards,
Lars.

> 
> Regards,
> Yarema
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?

[Lars Hanisch]

Hi,

Am 17.03.2013 09:20, schrieb Halim Sahin:
> Hi,
> vdr doesn't copy plugins to PLUGINS/lib.
> Is there a way to get the old behaviour back?
> First look I couldn't find nothing in vdr's HISTORY file.

 I think "make LCLBLD=1" should do it.

Lars.

> 
> Regards
> Halim

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-menuorg 0.5.0

[Lars Hanisch]

Hi,

Am 16.03.2013 18:41, schrieb Tobi:
> I wanted to completely drop this plugin, but it seems, some folks really
> like it.

 Yes! :)

> Maybe Klaus can add this feature in 2.1+.

 I hope so, too.

> I've basically only updated the Makefile and the patch for VDR 1.7.40.

 While upgrading our yavdr-package I found a patch in our repository:


--- a/src/MenuOrgPlugin.cpp
+++ b/src/MenuOrgPlugin.cpp
@@ -45,6 +45,7 @@
 // VDR OBJECTS TO EXIST OR PRODUCE ANY OUTPUT!

 _subMenuProvider = NULL;
+_menuConfigurationRepository = NULL;
 }

 MenuOrgPlugin::~MenuOrgPlugin()


 Seems to be important, but I don't know the reason anymore, why I added it...
 Can you have a look on it?

Thanks,
Lars.

> 
> As always: Any help is welcome!
> 
> Development site:
>   http://projects.vdr-developer.org/projects/plg-menuorg
> 
> Downloads:
>   http://projects.vdr-developer.org/projects/plg-menuorg/files
> 
> Git-Web:
>   http://projects.vdr-developer.org/git/vdr-plugin-menuorg.git/
> 
> Anonymous Git-access :
>   git://projects.vdr-developer.org/vdr-plugin-menuorg.git
> 
> 
> This is intended to be a community maintained project! Any help and
> patches are always welcome!
> 
> Please report bugs, ideas or feature requests to the project site (no
> registration required for this!). If you want to contribute patches, new
> features or whatever, post an issue or patch to the projects issue tracker
> or request to join the project. I would happily add everyone as a project
> member, who would like to contribute to the project!
> 
> Tobias
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-menuorg 0.5.0

[Lars Hanisch]

Hi,

 Found an error in the Makefile. The LIBS are missing, patch attached.

Regards,
Lars.

Am 16.03.2013 18:41, schrieb Tobi:
> I wanted to completely drop this plugin, but it seems, some folks really
> like it.
> 
> Maybe Klaus can add this feature in 2.1+.
> 
> I've basically only updated the Makefile and the patch for VDR 1.7.40.
> 
> As always: Any help is welcome!
> 
> Development site:
>   http://projects.vdr-developer.org/projects/plg-menuorg
> 
> Downloads:
>   http://projects.vdr-developer.org/projects/plg-menuorg/files
> 
> Git-Web:
>   http://projects.vdr-developer.org/git/vdr-plugin-menuorg.git/
> 
> Anonymous Git-access :
>   git://projects.vdr-developer.org/vdr-plugin-menuorg.git
> 
> 
> This is intended to be a community maintained project! Any help and
> patches are always welcome!
> 
> Please report bugs, ideas or feature requests to the project site (no
> registration required for this!). If you want to contribute patches, new
> features or whatever, post an issue or patch to the projects issue tracker
> or request to join the project. I would happily add everyone as a project
> member, who would like to contribute to the project!
> 
> Tobias
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


--- a/Makefile
+++ b/Makefile
@@ -45,6 +45,9 @@
 INCLUDES += `pkg-config libxml++-2.6 --cflags`
 INCLUDES += `pkg-config glibmm-2.4 --cflags`
 
+LIBS +=  `pkg-config libxml++-2.6 --libs`
+LIBS +=  `pkg-config glibmm-2.4 --libs`
+
 DEFINES += -DPLUGIN_NAME_I18N='"$(PLUGIN)"'
 
 ### The source files (add further files here):
@@ -102,7 +105,7 @@
 ### Targets:
 
 $(SOFILE): $(OBJS)
-   $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) -o $@
+   $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) $(LIBS) -o $@
 
 install-lib: $(SOFILE)
install -D $^ $(DESTDIR)$(LIBDIR)/$^.$(APIVERSION)

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] 0.1.0

[Lars Hanisch]

Hi,

Am 23.03.2013 12:28, schrieb René:
> On 23.03.2013 1:20 , fnu wrote:
>> René,
>>
>> well you could go the hard way and try a mix of repository based VDR
>> plus any self-compiled Plugins, in that case I would rather suggest
>> to do everything by yourself inkl. VDR ...
>>
>> Or a little easier Debian/Ubuntu way, look here: http://goo.gl/Xz7zm,
>> usage: "sudo apt-add-repository ppa:yavdr/testing-vdr"
>>
>> Our packages do base closely on Tobi's work.
>>
>> === Kind regards fnu
> 
> Hi Fnu,
> 
> Thanks for the suggesting your repo. It looks to have an impressive list of 
> plugins :-) I did a small test-ride, but for
> some reason it did not install an init-script. is it something i'm missing, 
> or shall i use the init-script found under
> /usr/share/doc/vdr/examples ?

 In the final version (coming with vdr 2.0) the package will again install an 
init.d-Script (or an upstart-job if your
system uses that like Ubuntu).
 For now you have to use the one found in the examples directory.

Lars.

> 
> Regards,
> 
> René
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lars Hanisch]

Hi,

Am 25.03.2013 20:09, schrieb Lucian Muresan:
> That is also due to some acrobatic
> conditional constructs in some desperate tries to keep the same
> makefiles also backwards compatible with a whole lot of older VDR
> series, instead of just providing the old makefile under another name
> just as it was.

 I think the best way to get compatible with old vdr versions is to manually 
create a vdr.pc file. Then plugins with new
Makefiles will just build. This should be up to the distributors. Just copy one 
from a recent vdr and edit the API
version and paths... Have done it with the current stable-vdr 1.7.27 in yaVDR.

 For plugins with old Makefiles: just get the needed variables from vdr.pc in 
your build-script (pkg-build, debian/rules
etc.) and you're done.

 I like the new Makefile... :)

 I don't like defines in headers, it's just a source of error noone should be 
forced to manage. Wrapping multiple
patches into each other can only be maintainable if you don't make them 
selectable. The distributor decides which
patches he/she likes to distribute and maintaining a patch combination is 
awfull enough... Done that (and doing it) and
I don't really like that either. :)
 But I will do it until there are no more patches *I* need... :)

 Why argue about the new Makefile? It's done, get used to it...

Peace,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lars Hanisch]

Hi,

Am 27.03.2013 18:40, schrieb Lucian Muresan:
> [2] for example, an empty LIBS variable, also used in the correct order
> (after OBJS) in the final link statement, just for the case that a
> plugin have use them, it could have spared some authors of putting it in
> wrong order and then wonder about unresolved symbols;

 +1

 That should be included in the next developer cycle in the plugins' Makefile. 
Have stumbled upon this two or three
times. I do know it now but the next one will hit it for sure. :)

> [3] completely missing usage of RESDIR which also can be read out of
> vdr.pc and any sample commented out target using it, that way many
> plugin authors continue just to ignore it even if their plugin actually
> comes with lots of non-program files we all call resources, which have
> to be installed under a certain pattern, only modifiable by the RESDIR
> variable.

 It would be nice, if the plugin's install target would install its resources 
to its well defined resource directory
(it's $RESDIR/plugins/$PLUGIN, isn't it?). That would make packaging even more 
easy.

> Could continue with CACHEDIR, but that applies to less
> plugins...

 I understand CACHEDIR as a location for runtime generated data which doesn't 
necessarily survive reboots of the vdr. I
don't think it should be the target of any installation files. Or am I wrong?

> You will say this is up to packagers, but actually since
> there are these modifiable variables, and also some files have to comply
> to a certain directory pattern, this can be well prepared by the plugin
> author, it's only about his plugin, and the packagers just have to
> divert those variables specific to their distribution and the plugin
> would still work without further modifications, and not fight with doing
> missing targets for so many plugins...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lars Hanisch]

Am 28.03.2013 00:20, schrieb Lucian Muresan:
> On 27.03.2013 23:07, Lars Hanisch wrote:
>>> Could continue with CACHEDIR, but that applies to less
>>>> plugins...
>>  I understand CACHEDIR as a location for runtime generated data which 
>> doesn't necessarily survive reboots of the vdr. I
>> don't think it should be the target of any installation files. Or am I wrong?
> 
> You are not wrong at all, but I actually mean less installing files into
> CACHEDIR but rather creating the subdirectory structure there, as it is
> expected by that plugin (sometimes it involves the plugin name,
> sometimes it's more generic, like for example several plugins sharing
> so-called epg-images which are fetched by some script and can be used
> for displaying by different plugins, so they would rather use a
> directory name not necessarily bound to some plugin name...). But then,
> again, I can agree it's arguable if that's not better a runtime option
> anyway...

 Since the cache directory is writeable by the vdr I think the plugin should 
create its files and folder at runtime.

 Example: osdteletext, which caches several pages from TTX. It should create 
its folder $CACHE_DIR/plugins/osdteletext
on startup and then create and delete files if needed.

Lars.

> 
> Regards,
> Lucian
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] difference between "g++ -pthread" and "g++ -lpthread"

[Lars Hanisch]

Hi,

 I'm hunting some race condition in my plugins which produce a segfault in libc 
or libavahi (still searching the right
packages with debug symbols, race condition may be related to having to 
dbus-mainloops in dbus2vdr and avahi4vdr, but I
don't know yet).
 While investigating this I found something about the option "-pthread" of g++.

 According to g++'s manpage this will set the right options for the 
preprocessor and compiler so the program can use the
pthreads lib. Especially it will set -D_REENTRANT and -lpthread etc.

 vdr seems only to use -lpthread and no other pthread-specific options.

 I'm not an expert on this topic, so I would like to know if someone can shed 
some light on this.
 Makefile may than be patched with:

==
--- a/Makefile
+++ b/Makefile
@@ -14,12 +14,12 @@
 CFLAGS   ?= -g -O3 -Wall

 CXX  ?= g++
-CXXFLAGS ?= -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses
+CXXFLAGS ?= -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -pthread

 CDEFINES  = -D_GNU_SOURCE
 CDEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE

-LIBS  = -ljpeg -lpthread -ldl -lcap -lrt $(shell pkg-config --libs 
freetype2 fontconfig)
+LIBS  = -ljpeg -ldl -lcap -lrt $(shell pkg-config --libs freetype2 
fontconfig)
 INCLUDES ?= $(shell pkg-config --cflags freetype2 fontconfig)

 # Directories:
==

 Recompiled vdr and plugins do run as before (haven't solved my segfault).

 What do you think?

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] RFC: one or many positioners?

[Lars Hanisch]

Am 22.04.2013 14:28, schrieb Klaus Schmidinger:
>...
> or even
> 
>   virtual void Drive(bool Left) {}// true = left, false = right
>   virtual void Step(int Steps) {} // <0 = left, >0 = right
>   virtual void SetLimit(bool Left) {} // true = left, false = right
> 
> ?

 If you would go this way, I would prefer an enum as parameter, because it's 
easier to use and the code is easier to
understand. You don't have to remember if true is left or right. :)
 "Step" would than have two parameters, the enum and an uint.

Regards,
Lars.

> 
> Klaus
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] noepg

[Lars Hanisch]

Hi,

Am 09.05.2013 08:49, schrieb Marx:
> I'm trying to configure noepg headless. Some time ago I had GUI and 
> configured noepeg, but now it's headless and after
> channels update I need to configure it again.
> 
> While there is no documentation, I've found thread describing it:
> http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/p961213-noepg-konfiguration/

 I think that old thread is about the noepg-patch. If your vdr is recent enough 
(and contains the EpgHandler interface)
you can use the noepg plugin.

 https://github.com/flensrocker/vdr-plugin-noepg

 The format of the settings.conf file is described in the README:

 https://github.com/flensrocker/vdr-plugin-noepg/blob/master/README#L29

 If you want to block some channels from receiving DVB-EPG it's just:

mode=blacklist
V-0-3588-1
V-0-2916-1
V-0-2917-1

 If you want to get DVB-EPG only for some channels and block all other:

mode=whitelist
V-0-3588-1
V-0-2916-1
V-0-2917-1

 I hope this helps.

Regards,
Lars.

> Hovewer I use DVB-T and so channels have format like V-0-3588-1 V-0-2916-1 
> V-0-2917-1 V-0-3589-1 V-0-2805-1 V-0-3700-1
> 
> My channels list doesn't contain anything like 3588, 2916 etc so I don't know 
> how to manually build this list.
> 
> I'm attaching at the end my channels.conf.
> 
> Marx
> 
> :DVB-T
> TVP1
> HD;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:102=27:103=pol@3;104=qaa@122,108=aux@122:105;106=pol,109=eng:0:1:8808:1:0
> 
> TVP1;EmiTel:184500:I999B7C78D0M64T4G16Y0:T:27500:102=27:104=pol@4;103=qaa@122,108=aux@122:105;106=pol,109=eng:0:44:8808:3:0
> TVP2
> HD;EmiTel:184500:I999B7C78D0M64T4G16Y0:T:27500:202=27:204=pol@4;203=qaa@122,208=aux@122:205;206=pol,209=eng:0:2:8808:3:0
> TVP2;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:202=27:203=pol@3;204=qaa@122:205;206=pol,209=eng:0:45:8808:1:0
> Polsat;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:102=27:103=pol@4;104=mul@122:105;106=pol:0:3:8808:2:0
> TVN;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:202=27:203=pol@4;204=mul@106:205;206=pol:0:4:8808:2:0
> TVN 
> Siedem;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:502=27:503=pol@4;504=mul@106:505;506=pol:0:23:8808:2:0
> TV4;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:302=27:303=pol@4,308=aux@4:305:0:5:8808:2:0
> TV 
> Puls;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:402=27:403=pol@4:0:0:6:8808:2:0
> PULS 
> 2;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:602=27:603=pol@4:0:0:24:8808:2:0
> TV6;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:702=27:703=pol@4,708=aux@4:0:0:25:8808:2:0
> Polsat Sport 
> News;EmiTel:177500:I999B7C78D0M64T4G16Y0:T:27500:802=27:803=pol@4:0:0:26:8808:2:0
> TVP 
> Kultura;EmiTel:184500:I999B7C78D0M64T4G16Y0:T:27500:402=27:404=pol@4;403=qaa@106:405;406=pol:0:31:8808:3:0
> TVP 
> Historia;EmiTel:184500:I999B7C78D0M64T4G16Y0:T:27500:502=27:504=pol@4;503=aux@106:505:0:32:8808:3:0
> TVP 
> Polonia;EmiTel:184500:I999B7C78D0M64T4G16Y0:T:27500:602=27:603=pol@4:605:0:33:8808:3:0
> TVP 
> Rozrywka;EmiTel:184500:I999B7C78D0M64T4G16Y0:T:27500:3402=27:3403=pol@4;3408=aux@122:0:0:34:8808:3:0
> TVP INFO 
> Katowice;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:1102=27:1104=pol@4:1105:0:11:8808:1:0
> ESKA 
> TV;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:302=27:303=pol@3:0:0:27:8808:1:0
> TTV;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:402=27:403=pol@3;404=mul@106:405:0:28:8808:1:0
> POLO 
> TV;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:502=27:503=pol@3:0:0:29:8808:1:0
> ATM 
> Rozrywka;EmiTel:191500:I999B7C999D999M999T999G999Y999:T:27500:602=27:603=pol@3,608=aux@3:0:0:30:8808:1:0
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Deactivate a Tuner

[Lars Hanisch]

Hi,

Am 07.08.2013 21:04, schrieb Brian-Imap:
> Hi,
> I now a have a 4 Tuner Cine S2 setup that I want to run with 3 cables, I want 
> to keep the fourth cable for a test VDR.
> Reading about this I only see how to do it together with the Dynamite Plugin, 
> is that correct that I must use that
> Plugin to get it to work for VDR?
> 
> I am currently running a plain VDR setup on Ubuntu, with very few plugins and 
> had no need for the Dynamite Plugin
> up till now.

 You don't really need dynamite. If you want to omit the fourth tuner (in 
kernel count order), you can start vdr with
the -D parameter (see vdr --help).

 vdr -D0 -D1 -D2 

Regards,
Lars.

> 
> Cheers Brian
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 




smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Deactivate a Tuner

[Lars Hanisch]

Hi,

 Since you're using two different drivers, have you tried the module parameter 
"adapter_nr"? Then you will be able to
make the DVB-C card always adapter0 and the others 1-4.

 See "modinfo ".

Lars.

Am 18.08.2013 19:27, schrieb Brian-Imap:
> On 8/15/2013 9:08 PM, Brian-Imap wrote:
>> On 8/15/2013 5:58 PM, Arthur wrote:
>>> 15.08.2013 18:37, Brian-Imap kirjutas:
>>>> On 8/14/2013 10:16 PM, Arthur wrote:
>>>>> 14.08.2013 19:01, Brian-Imap kirjutas:
>>>>>> On 8/11/2013 11:43 AM, Brian-Imap wrote:
>>>>>>> On 8/8/2013 10:22 PM, Lars Hanisch wrote:
>>>>>>>> Am 08.08.2013 16:23, schrieb Brian-Imap:
>>>>>>>>> On 8/7/2013 9:58 PM, Lars Hanisch wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Am 07.08.2013 21:04, schrieb Brian-Imap:
>>>>>>>>>>> Hi,
>>>>>>>>>>> I now a have a 4 Tuner Cine S2 setup that I want to run with 3
>>>>>>>>>>> cables, I want to keep the fourth cable for a test VDR.
>>>>>>>>>>> Reading about this I only see how to do it together with the
>>>>>>>>>>> Dynamite Plugin, is that correct that I must use that
>>>>>>>>>>> Plugin to get it to work for VDR?
>>>>>>>>>>>
>>>>>>>>>>> I am currently running a plain VDR setup on Ubuntu, with very few
>>>>>>>>>>> plugins and had no need for the Dynamite Plugin
>>>>>>>>>>> up till now.
>>>>>>>>>>   You don't really need dynamite. If you want to omit the fourth
>>>>>>>>>> tuner (in kernel count order), you can start vdr with
>>>>>>>>>> the -D parameter (see vdr --help).
>>>>>>>>>>
>>>>>>>>>>   vdr -D0 -D1 -D2 
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Lars.
>>>>>>>>>>
>>>>>>>>>>> Cheers Brian
>>>>>>>>>>>
>>>>>>>>>>> ___
>>>>>>>>>>> vdr mailing list
>>>>>>>>>>> vdr@linuxtv.org
>>>>>>>>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ___
>>>>>>>>>> vdr mailing list
>>>>>>>>>> vdr@linuxtv.org
>>>>>>>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>>>>>>> Hi Lars,
>>>>>>>>>
>>>>>>>>> OK I knew about this, but I thought that the Card/Tuners numbers
>>>>>>>>> could change
>>>>>>>>> from boot to boot. Are you saying that they will not change?
>>>>>>>>   If it's one bridge with 4 tuners, I doubt their order will change.
>>>>>>>>
>>>>>>>>   You may want to read about "device bonding", where you split one
>>>>>>>> cable on two tuners so they share polarisation and
>>>>>>>> band, but may be tuned to different transponders.
>>>>>>>>
>>>>>>>>   But I'm a cable user, I don't know much about it, just that there
>>>>>>>> are some people out there who use it successfully. :)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Lars.
>>>>>>>>
>>>>>>>>> Cheers Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> vdr mailing list
>>>>>>>>> vdr@linuxtv.org
>>>>>>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>>>>>>>
>>>>>>>> ___

Re: [vdr] VDR needs some way to detect new tuners on runtime...

[Lars Hanisch]

Hi,

Am 20.08.2013 08:59, schrieb syrius...@no-log.org:
> Manuel Reimer  writes:
> 
>> 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 there is any way to get
>> around this:
>>
>> http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html
>>
>> The result: The "daemon" (VDR) needs some way to detect devices while
>> runtime.
>>
>> 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.
> 
> Hi,
> 
> You should be able to achieve this using the dynamite patch and
> plugin.
> I would definitey love to see its features merged in main vdr btw :)

 As a proof-of-concept I plan to rework the dynamite-patch/-plugin to extract 
the dynamic device discovering with udev
as a patch-only-implementation. Klaus, I will not urge you to include this, but 
I think, if enough people will need and
test it, maybe in the future we can make you think about it again. :)

 Even if you say that you never ever will include it, it won't keep me from 
writing that patch. I don't have a problem
to patch my own vdr... :)

 My plans:
- instantiate MAX_DVB_DEVICES cDvbDevice objects at startup
- special adapter number "-1" as "not connected/installed/inactive", such a 
device will return, that it can't receive
anything (Provides* functions etc.).
- start a udev-monitor thread and listen for dvb-subsystem events of 
adding/removing dvb-cards
- eval udev attributes on add-events if the card should have a specific device 
number and pass the adapter to the right
cDvbDevice object, otherwise interpret the adapter number as cardindex
- on removing a device, "close" the cDvbDevice (its file descriptors) and set 
it back to adapter -1 (will solve the usb
problem mentioned in another mail)

 This all is done by dynamite at the moment and is working fine. But since 
dynamite was the first project to learn about
udev and all the other things involved, a rewrite is always a good idea now all 
things are in place.
 Even closing the various file descriptors of the dvb devices doesn't lead to a 
segfault as some comments in the code
mention.
 Additional udev will be used to enumerate the dvb devices and some udev 
attributes may be used to decide if a device
should be used or not etc.

 I just have to work out how the cDvbDeviceProbe thing will fit into this - 
definitly the plugins must be able to handle
the special adapter "-1" and must be able to initialise its device aside the 
constructor. And there must be some kind of
configuration so the plugins can be told how many cDvbDevice-derived objects 
each has to instantiate. But it is all
solvable.

 I plan to release the first version of such a patch till end of september, if 
real life keeps calm the next weeks... :)
 And of course I will design it in such a way that it has to be enabled 
explicitly with a command line switch so that
the default behaviour is not changed.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR needs some way to detect new tuners on runtime...

[Lars Hanisch]

Am 25.08.2013 12:30, schrieb Klaus Schmidinger:
> On 25.08.2013 12:23, Lars Hanisch wrote:
>> Hi,
>>
>> Am 20.08.2013 08:59, schrieb syrius...@no-log.org:
>>> Manuel Reimer  writes:
>>>
>>>> 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 there is any way to get
>>>> around this:
>>>>
>>>> http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html
>>>>
>>>> The result: The "daemon" (VDR) needs some way to detect devices while
>>>> runtime.
>>>>
>>>> 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.
>>>
>>> Hi,
>>>
>>> You should be able to achieve this using the dynamite patch and
>>> plugin.
>>> I would definitey love to see its features merged in main vdr btw :)
>>
>>   As a proof-of-concept I plan to rework the dynamite-patch/-plugin to 
>> extract the dynamic device discovering with udev
>> as a patch-only-implementation. Klaus, I will not urge you to include this, 
>> but I think, if enough people will need and
>> test it, maybe in the future we can make you think about it again. :)
>>
>>   Even if you say that you never ever will include it, it won't keep me from 
>> writing that patch. I don't have a problem
>> to patch my own vdr... :)
>>
>>   My plans:
>> - instantiate MAX_DVB_DEVICES cDvbDevice objects at startup
> 
> I don't like this.
> 
> You can, of course, write whatever patch you like, but if the basic approach 
> is
> to "instantiate MAX_DVB_DEVICES cDvbDevice objects at startup" then it is most
> certainly never going to be included as a core feature.

 For now I haven't found another solution because several places all over the 
code (and also in the plugins) use the
pointers from the device array. If they change during runtime (or are reset to 
NULL, maybe inbetween), there are a lot
of problems to be expected. Therefore dynamite instantiates "proxy devices" and 
create "subdevices" with the real access
to the hardware. But these proxy devices have its own kind of problems, so I 
think it's better to implement the hotplug
functionality directly in cDvbDevice or even cDevice.
 It's just the next step on the way, it's way from perfect. I'm just curious if 
this setup will do better and doesn't
change the API too much. :)

Lars.

> 
> Klaus
> 
> 
>> - special adapter number "-1" as "not connected/installed/inactive", such a 
>> device will return, that it can't receive
>> anything (Provides* functions etc.).
>> - start a udev-monitor thread and listen for dvb-subsystem events of 
>> adding/removing dvb-cards
>> - eval udev attributes on add-events if the card should have a specific 
>> device number and pass the adapter to the right
>> cDvbDevice object, otherwise interpret the adapter number as cardindex
>> - on removing a device, "close" the cDvbDevice (its file descriptors) and 
>> set it back to adapter -1 (will solve the usb
>> problem mentioned in another mail)
>>
>>   This all is done by dynamite at the moment and is working fine. But since 
>> dynamite was the first project to learn about
>> udev and all the other things involved, a rewrite is always a good idea now 
>> all things are in place.
>>   Even closing the various file descriptors of the dvb devices doesn't lead 
>> to a segfault as some comments in the code
>> mention.
>>   Additional udev will be used to enumerate the dvb devices and some udev 
>> attributes may be used to decide if a device
>> should be used or not etc.
>>
>>   I just have to work out how the cDvbDeviceProbe thing will fit into this - 
>> definitly the plugins must be able to handle
>> the special adapter "-1" and must be able to initialise its device aside the 
>> constructor. And there must be some kind of
>> configuration so the plugins can be told how many cDvbDevice-derived objects 
>> each has to instantiate. But it is all
>> solvable.
>>
>>   I plan to release the first version of such a patch till end of september, 
>> if real life keeps calm the next weeks... :)
>>   And of course I will design it in such a way that it has to be enabled 
>> explicitly with a command line switch so that
>> the default behaviour is not changed.
>>
>> Lars.
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR wird in 3:00 Minuten ausschalten

[Lars Hanisch]

Hi,

Am 15.10.2013 00:37, schrieb Helmut Auer:
> Hello
>>
>> But still it does not make sense on my system as the message now pops up 
>> every
>> 5 minutes.  It is really very annoying if i sometimes use VDR to just watch
>> TV.  I would much better like it if VDR shuts down with no message than 
>> seeing
>> this message every 5 minutes.
>> To my understanding, making this a configuration option would make everybody
>> happy and would maybe even be easier than writing a plugin.
>>
> If you see this message and you press any key on your remote control, this 
> message will disappear at least for as many
> minutes as you have set the inactivity timeout ...

 Wouldn't a "MinUserInactivity = 0" disable the message because the user never 
gets inactive?

Regards,
Lars.

> 
> Bye
> Helmut
> 
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] searching a HW problem

[Lars Hanisch]

Am 15.10.2013 08:20, schrieb Petri Hintukainen:
> On ma, 2013-10-14 at 19:53 +0200, Vidar Tyldum wrote:
>> On 13. okt. 2013 23:30, Torsten Mohr wrote:
>>> These cards worked fine in my previous VDR, i never experienced problems 
>>> there.
>>>
>>> But on the other hand, what cards would you recommend?  A double tuner would
>>> be preferred (DVB-C).
>>
>> I am very satisfied with my SAA7146-based cards, although they only have 
>> a single tuner.
> 
> +1
> 
> I've been using SAA7146-based Technotrend cards for ~10 years 24/7
> without any problems. That's almost 90 000 hours without driver or HW
> failures (well, all other parts of the system have been replaced during
> the years). The hardware and drivers seem to be very robust, but
> compared to modern adapters those produce lot of heat and take quite
> much room (and PCI slots).
> I've tried also several DVB-C/T USB adapters, but those all performed
> rather poorly ... signal problems, lost recordings, requiring reboots
> etc.

 Here are doing two Satelco EasyWatch (KNC One clones) their job for years, but 
since my new vdr hasn't got any PCI
slots anymore I switched to the cards from Digital Devices/Linux4Media. A 
(dd)bridge and two Flex modules (=> 4 Tuner)
are working for some months now. You just have to compile the driver from the 
media-build-experimental repository of
Oliver Endriss - if you use Ubuntu/yaVDR there is a DKMS package which makes 
installation easy.
 They are a bit more expensive than other cards but have advantages: the dual 
tuner module just needs one cable and it's
no problem to connect a second module with a short cable from the antenna 
output of the first module. And since they are
small cards it's just a matter of the slot bracket if you want it full or low 
profile.

Regards,
Lars.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR wird in 3:00 Minuten ausschalten

[Lars Hanisch]

Am 15.10.2013 21:00, schrieb Udo Richter:
> Am 15.10.2013 00:48, schrieb Lars Hanisch:
>>  Wouldn't a "MinUserInactivity = 0" disable the message because the user 
>> never gets inactive?
> 
> It would, but in that case the automatic shutdown would be disabled too.

 Ah, right, my fault. Torsten wants a shutdown but not the message...

 There's always the possibility to patch your own vdr. :)

Lars.

> In that case, hitting the power button is required to get inactive,
> resulting in the same frequent shutdown retries as before.
> 
> @Torsten:
> Regarding the original problem, to what value is your MinUserInactivity
> option set? If you did set that to a very small value, you're probably
> trying to get around an automatic shutdown issue the wrong way.
> 
> 
> Cheers,
> 
> Udo
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR wird in 3:00 Minuten ausschalten

[Lars Hanisch]

Hi,

Am 16.10.2013 21:20, schrieb Torsten Mohr:
> Hi,
> 
> i have set MinUserInactivity to 10.
> 
> Pressing any button on the remote is very annoying, pressing a button gives 
> me 
> 5 minutes of warning free TV.
> 
> I also thought about patching VDR sources and compiling it myself but i can't 
> imagine that nobody else would benefit from that, i don't think my system 
> setup 
> is that special.

 I think an inactivity timeout of 10 minutes is a special setup.
 Why so low? Why not 180 minutes?

 You can always set the use to inactive with the power button.

Lars.

> 
> 
> Best regards
> Torsten
> 
> 
> Am Dienstag, 15. Oktober 2013, 00:48:16 schrieb Lars Hanisch:
>> Hi,
>>
>> Am 15.10.2013 00:37, schrieb Helmut Auer:
>>> Hello
>>>
>>>> But still it does not make sense on my system as the message now pops up
>>>> every 5 minutes.  It is really very annoying if i sometimes use VDR to
>>>> just watch TV.  I would much better like it if VDR shuts down with no
>>>> message than seeing this message every 5 minutes.
>>>> To my understanding, making this a configuration option would make
>>>> everybody happy and would maybe even be easier than writing a plugin.
>>>
>>> If you see this message and you press any key on your remote control, this
>>> message will disappear at least for as many minutes as you have set the
>>> inactivity timeout ...
>>
>>  Wouldn't a "MinUserInactivity = 0" disable the message because the user
>> never gets inactive?
>>
>> Regards,
>> Lars.
>>
>>> Bye
>>> Helmut


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR wird in 3:00 Minuten ausschalten

[Lars Hanisch]

Am 17.10.2013 19:09, schrieb Torsten Mohr:
> Hi,
> 
>>  I think an inactivity timeout of 10 minutes is a special setup.
>>  Why so low? Why not 180 minutes?
> 
> ok, that could be debugging left-over from the last setup.  I'll try the 
> value 
> 180, maybe this improves it.
> 
> If nothing happens and nobody is logged in i shut down the VDR after 30 
> minutes.  So a value of 180 would prevent a shutdown after 30 minutes of 
> inactivity?

 The vdr tracks remote keypresses. If the last keypress is longer ago than the 
inactivity timeout (180 = 3 hours), the
user is set to inactive. Then vdr asks all plugins if they are active and if 
not it triggers the shutdown.
 With a "hitk power" you can always set the user to inactive state before the 
timeout is reached.

Lars.

> 
> 
> Best regards
> Torsten
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [Patch] reconnect to lirc socket even if it doesn't exist on startup

[Lars Hanisch]

Hi,

 The reconnect loop of cLircRemote will not be started if the socket does not 
exist at the time, vdr starts.
 In "fast boot" environments this may be true.

 The attached patch fixes this.

Regards,
Lars.
diff --git a/lirc.c b/lirc.c
index b88bd73..09905d0 100644
--- a/lirc.c
+++ b/lirc.c
@@ -21,11 +21,9 @@ cLircRemote::cLircRemote(const char *DeviceName)
 {
   addr.sun_family = AF_UNIX;
   strcpy(addr.sun_path, DeviceName);
-  if (Connect()) {
- Start();
- return;
- }
-  f = -1;
+  if (!Connect())
+ f = -1;
+  Start();
 }
 
 cLircRemote::~cLircRemote()
@@ -67,14 +65,15 @@ void cLircRemote::Action(void)
   bool repeat = false;
   int timeout = -1;
 
-  while (Running() && f >= 0) {
+  while (Running()) {
 
-bool ready = cFile::FileReady(f, timeout);
+bool ready = f >= 0 ? cFile::FileReady(f, timeout) : false;
 int ret = ready ? safe_read(f, buf, sizeof(buf)) : -1;
 
-if (ready && ret <= 0 ) {
+if ((f < 0) || (ready && (ret <= 0))) {
esyslog("ERROR: lircd connection broken, trying to reconnect every %.1f seconds", float(RECONNECTDELAY) / 1000);
-   close(f);
+   if (f >= 0)
+  close(f);
f = -1;
while (Running() && f < 0) {
  cCondWait::SleepMs(RECONNECTDELAY);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr 1.7 -> 2.1 upgrade tips (FHS)

[Lars Hanisch]

Hi,

Am 04.11.2013 17:17, schrieb VDR User:
>>> Hi,
>>> Have a look to Make.config.template if you want to use vdr 2.x like 1.6
>>> running in one single dir!
>>
>> Yeah, I saw that sort of thing is doable but it's probably worth my
>> while doing things "properly" to fit in with the current way of
>> thinking.
> 
> It's not `improper` to keep the same pre-FHS structure. A lot of
> people don't care about FHS. I personally don't like files spread out
> all over the place. Instead I prefer things be kept in a single
> location so things are easy to keep track of. For that reason, I also
> use ONEDIR=1 in my vdr Make.config. I didn't have to move any files
> anywhere and upgraded VDR with no problem.
> 
> Don't do something because someone else does it. Do it because it's
> what you actually want. If you don't want it that way, why force
> yourself to go against your own preference? Especially if you're using
> linux where anything goes.

 And I'm pretty sure vdr will always support the "one directory" setup, because 
Klaus is using it (as far as I know).

Regards,
Lars.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] spelling in usage text

[Lars Hanisch]

Hi,

"--vfat for backwards compatibility (same as\n"
"   --dirnames=250,40,1\n"

 Either use a comma before "same" or a closing bracket in the second line.
 Whatever you prefer, I would take the comma. :)

 Patches attached for both variants.

Lars.
diff --git a/vdr.c b/vdr.c
index 083d838..ad2469c 100644
--- a/vdr.c
+++ b/vdr.c
@@ -540,7 +540,7 @@ int main(int argc, char *argv[])
"  -v DIR,   --video=DIRuse DIR as video directory (default: %s)\n"
"  -V,   --version  print version information and exit\n"
"--vfat for backwards compatibility (same as\n"
-   "   --dirnames=250,40,1\n"
+   "   --dirnames=250,40,1)\n"
"  -w SEC,   --watchdog=SEC activate the watchdog timer with a timeout of SEC\n"
"   seconds (default: %d); '0' disables the watchdog\n"
"\n",
diff --git a/vdr.c b/vdr.c
index 083d838..31c1928 100644
--- a/vdr.c
+++ b/vdr.c
@@ -539,7 +539,7 @@ int main(int argc, char *argv[])
"--userdump allow coredumps if -u is given (debugging)\n"
"  -v DIR,   --video=DIRuse DIR as video directory (default: %s)\n"
"  -V,   --version  print version information and exit\n"
-   "--vfat for backwards compatibility (same as\n"
+   "--vfat for backwards compatibility, same as\n"
"   --dirnames=250,40,1\n"
"  -w SEC,   --watchdog=SEC activate the watchdog timer with a timeout of SEC\n"
"   seconds (default: %d); '0' disables the watchdog\n"
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New tool to load VDR with XMLTV Data

[Lars Hanisch]

Hi,

 Do you know the xmltv2vdr plugin?
 http://projects.vdr-developer.org/git/vdr-plugin-xmltv2vdr.git/

 Maybe it's sufficient to write a grabber (aka downloader) for it?

Regards,
Lars.

Am 23.12.2013 23:25, schrieb Adam Flott:
> XMLTV communicates with schedules direct. I let xmltv do the downloading / 
> transformation before parsing.
> 
> On Dec 23, 2013, at 4:04 PM, "Timothy D. Lenz"  wrote:
> 
>> So this would read data from Schedules Direct? I started trying to come up 
>> with something, but never got far with it.
>>
>> On 12/23/2013 2:46 PM, Adam Flott wrote:
>>> I wrote a tool to load VDR with XMLTV data. Written in Go with 0
>>> external dependencies and does a few things nicer than that perl script
>>> that's been floating around
>>>
>>> Source: https://github.com/adamflott/vdr-epg-tool
>>> Usage: http://adamflott.com/loading-vdr-with-xmltv-data/
>>>
>>> Probably not 100% bug free, but it works for me.
>>>
>>> $ tv_grab_na_dd --days 1 --output /tmp/epg_schedules_direct.xml \
>>>   && vdr-epg-tool -c /var/lib/vdr/channels.conf -x
>>> /tmp/epg_schedules_direct.xml epg-load \
>>>   && rm /tmp/epg_schedules_direct.xml
>>>
>>>
>>> Enjoy!


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3

[Lars Hanisch]

Am 05.01.2014 12:42, schrieb Klaus Schmidinger:
> VDR developer version 2.1.3 is now available at
> 
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.3.tar.bz2
> 
> A 'diff' against the previous version is available at
> 
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.2-2.1.3.diff
> 
> MD5 checksums:
> 
> 054f80e0045aa6fad118e9285b52f4f2  vdr-2.1.3.tar.bz2
> 3c5ab05d5c4d0b984b34e84190e80949  vdr-2.1.2-2.1.3.diff
> 
> WARNING:
> 
> 
> This is a *developer* version. Even though *I* use it in my productive
> environment, I strongly recommend that you only use it under controlled
> conditions and for testing and debugging.
> 
> 
> Originally I intended to release this version only after the new DiSEqC
> configuration dialog was finished. But in the meantime quite a few other 
> things
> have come up, so I decided to postpone that dialog and first release what has
> piled up so far.
> 
> 
> The changes since version 2.1.2:
> 
> - Changed the return value of cPositioner::HorizonLongitude() to 0 in case the
>   latitude of the antenna location is beyond +/-81 degrees.
> - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
> - Fixed some compiler warnings with gcc-4.6.3 (thanks to Rolf Ahrenberg).
> - Changed the name of the SVDRP command RENR to MOVR (suggested by Rolf 
> Ahrenberg).
> - When cutting a recording it is now checked whether there is already an 
> edited
>   version of this recording (with the same name, but starting with '%'), and 
> the
>   user is prompted for confirmation to overwrite it (suggested by Rolf 
> Ahrenberg).
> - Revoked "Added maximum signal strength value for TechniSat SkyStar 2 DVB-S 
> rev 2.3P"
>   because it broke things for the "TechniSat AirStar 2" DVB-T card.
> - The LIRC remote control now connects to the socket even if it doesn't yet 
> exist when
>   VDR is started (thanks to Lars Hanisch).
> - Changed the absolute latitude limit for visible satellites to 81.2 degrees.
> - Added code for parsing LCN and AVC descriptors to libsi (thanks to Rolf 
> Ahrenberg).
> - In the "Select folder" menu pressing Ok now selects the folder, even if 
> this is a
>   folder that contains sub folders (marked with "..."). To open such a folder 
> you
>   can press the Red key.
> - Fixed a possible access to uninitialized data in cEIT::cEIT() (reported by 
> Dominik
>   Strasser).
> - The new menu category mcRecordingEdit is now used to mark menus that edit 
> recording
>   properties (suggested by Stefan Braun).
> - Changes in the teletext PID no longer cause retuning (and thus interrupting 
> a
>   recording).
> - Removed '_' from the FileNameChars and CharMap translations in uk_UA.po.
> - Updated the Italian OSD texts (thanks to Diego Pierotto).
> - Fixed a missing initialization in the c'tor of cSkinLCARSDisplayChannel 
> (thanks to
>   Marko Mäkelä).
> - Simplified some conditional expressions in skinlcars.c and skinsttng.c 
> (suggested
>   by Marko Mäkelä).
> - Fixed uninitialized item area coordinates in cSkinLCARSDisplayMenu 
> (reported by
>   Marko Mäkelä).
> - Fixed a possible crash if the recordings list is updated externally while 
> the
>   Recordings menu is open (reported by Lars Hanisch).
> - Added a missing closing ')' in the help and man page entry of the --vfat 
> option
>   (reported by Lars Hanisch).
> - Fixed setting the name of the video directory to avoid a crash when using 
> --genindex,
>   and also to use the correct directory with --edit (the latter reported by 
> Marko
>   Mäkelä).
> - The Recordings menu can now be called with a cRecordingFilter, which allows 
> the
>   caller to have it display only a certain subset of the recordings (thanks 
> to Lars
>   Hanisch).
> - Added handling UTF-8 'umlaut' characters to cKbdRemote (thanks to Lars 
> Hanisch).
> - Made it clear that the Data parameter in cDevice::StillPicture() may point 
> to a
>   series of packets, not just a single one (thanks to Thomas Reufer).
> - cDevice::TrickSpeed() now has an additional parameter named Forward, which 
> indicates
>   the direction in which replay is being done (suggested by Thomas Reufer). 
> This
>   information may be necessary for some output devices in order to properly 
> implement
>   trick modes. Authors of plugins that implement output devices will need to 
> add this
>   parameter to their derived cDevice class, regardless of whether they will 
> make use
>   of it or not.
> - Added a note to ePlayMode in device.h that VDR itself always uses 
> pmAudioVideo when
>   replaying a recording (suggested by Thomas Reufer).
>

Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3

[Lars Hanisch]

Am 05.01.2014 13:01, schrieb fnu:
>>  I will! :)
> 
> Who not ... ;-)
> 
>>  Thanks for a bunch of little gems in this release like "obsolete
>> channels".
> 
> Yes, indeed ... :tup
> 
>>  Have to dig into the new CAM stuff, maybe now it's possible to
>> integrate the CI of Digital Devices...
> 
> That would be great, christmas has gone recently, but I wouldn't say no for
> delayed present.

 "I'll do my very best..." :)

Lars.

> 
> ===
> Kind regards
> fnu
> 
>> -Original Message-
>> From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf
>> Of Lars Hanisch
>> Sent: Sunday, January 05, 2014 12:54 PM
>> To: vdr@linuxtv.org
>> Subject: Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
>>
>> Am 05.01.2014 12:42, schrieb Klaus Schmidinger:
>>> VDR developer version 2.1.3 is now available at
>>>
>>>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.3.tar.bz2
>>>
>>> A 'diff' against the previous version is available at
>>>
>>>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.2-2.1.3.diff
>>>
>>> MD5 checksums:
>>>
>>> 054f80e0045aa6fad118e9285b52f4f2  vdr-2.1.3.tar.bz2
>>> 3c5ab05d5c4d0b984b34e84190e80949  vdr-2.1.2-2.1.3.diff
>>>
>>> WARNING:
>>> 
>>>
>>> This is a *developer* version. Even though *I* use it in my productive
>>> environment, I strongly recommend that you only use it under
>>> controlled conditions and for testing and debugging.
>>>
>>>
>>> Originally I intended to release this version only after the new
>>> DiSEqC configuration dialog was finished. But in the meantime quite a
>>> few other things have come up, so I decided to postpone that dialog
>>> and first release what has piled up so far.
>>>
>>>
>>> The changes since version 2.1.2:
>>>
>>> - Changed the return value of cPositioner::HorizonLongitude() to 0 in
>> case the
>>>   latitude of the antenna location is beyond +/-81 degrees.
>>> - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
>>> - Fixed some compiler warnings with gcc-4.6.3 (thanks to Rolf
>> Ahrenberg).
>>> - Changed the name of the SVDRP command RENR to MOVR (suggested by
>> Rolf Ahrenberg).
>>> - When cutting a recording it is now checked whether there is already
>> an edited
>>>   version of this recording (with the same name, but starting with
>> '%'), and the
>>>   user is prompted for confirmation to overwrite it (suggested by Rolf
>> Ahrenberg).
>>> - Revoked "Added maximum signal strength value for TechniSat SkyStar 2
>> DVB-S rev 2.3P"
>>>   because it broke things for the "TechniSat AirStar 2" DVB-T card.
>>> - The LIRC remote control now connects to the socket even if it
>> doesn't yet exist when
>>>   VDR is started (thanks to Lars Hanisch).
>>> - Changed the absolute latitude limit for visible satellites to 81.2
>> degrees.
>>> - Added code for parsing LCN and AVC descriptors to libsi (thanks to
>> Rolf Ahrenberg).
>>> - In the "Select folder" menu pressing Ok now selects the folder, even
>> if this is a
>>>   folder that contains sub folders (marked with "..."). To open such a
>> folder you
>>>   can press the Red key.
>>> - Fixed a possible access to uninitialized data in cEIT::cEIT()
>> (reported by Dominik
>>>   Strasser).
>>> - The new menu category mcRecordingEdit is now used to mark menus that
>> edit recording
>>>   properties (suggested by Stefan Braun).
>>> - Changes in the teletext PID no longer cause retuning (and thus
>> interrupting a
>>>   recording).
>>> - Removed '_' from the FileNameChars and CharMap translations in
>> uk_UA.po.
>>> - Updated the Italian OSD texts (thanks to Diego Pierotto).
>>> - Fixed a missing initialization in the c'tor of
>> cSkinLCARSDisplayChannel (thanks to
>>>   Marko Mäkelä).
>>> - Simplified some conditional expressions in skinlcars.c and
>> skinsttng.c (suggested
>>>   by Marko Mäkelä).
>>> - Fixed uninitialized item area coordinates in cSkinLCARSDisplayMenu
>> (reported by
>>>   Marko Mäkelä).
>>> - Fixed a possible crash if the recordings list is updated externally
>> while the
>>>   Recordings menu is open (reported by Lars Hanisch).
>>> - Added a missing closing &

[vdr] [PLUGIN] recsearch - a simple search for recordings

[Lars Hanisch]

Hi,

 For all, who wonder, where this change for vdr 2.1.3 comes from:

> - The Recordings menu can now be called with a cRecordingFilter, which allows 
> the
>   caller to have it display only a certain subset of the recordings

 here's the plugin, which uses it: recsearch

 https://github.com/flensrocker/vdr-plugin-recsearch

 It's a simple search for name, shorttext and description, the status 
(new/edited) and age of a recording.
 The main reason for me was to get a quick list of the new recordings of the 
last week.

 You can save various templates, organize them in categories and add a hotkey 
to them, so you can use something like

User1 @recsearch 1

 in your keymacros.conf to quickly execute a search.

 For vdr versions older than 2.1.3 there's a clone of the recordings menu of 
vdr 2.0.4 included, so you can use it for
the current stable release.


 Comments are welcome.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PLUGIN] recsearch - a simple search for recordings

[Lars Hanisch]

Am 19.01.2014 13:53, schrieb Stephan Loescher:
> Am 01/19/14 11:37, schrieb Lars Hanisch:
>>
>>   here's the plugin, which uses it: recsearch
>>
> [...]
>>   It's a simple search for name, shorttext and description, the status 
>> (new/edited) and age of a recording.
>>   The main reason for me was to get a quick list of the new recordings of 
>> the last week.
> 
> Hi Lars,
> 
> Wonderful!
> 
> Would it be possible (as a new feature) to filter/search/sort for recordings 
> by recording-lifetime and/or if it is SD or
> HD?

 "sorting" is done by recordings menu of vdr. No chance, that recsearch can add 
there an alternative sort mechanism (for
now).

 "lifetime" is a property of cRecording, so yes, it's possible to add a filter 
for this.

 Neither cRecording nor cRecordingInfo provides anything so recsearch can 
decide, if it's SD or HD. Sorry, can't add
something there...

Regards,
Lars.

> My use case is this: I normally like to view "important" and high-quality 
> recordings first, which I typically sort
> manually in this order:
> 
> 1. Lifetime (L) 99 and HD
> 2. L99 + SD
> 3. L98 + HD
> 4. L98 + SD
> 5. L<98 + HD
> 6. L<98 + SD
> 
> Regards,
> Stephan.
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PLUGIN] recsearch - a simple search for recordings

[Lars Hanisch]

Am 19.01.2014 16:09, schrieb Carsten Koch:
> On 01/19/14 13:53, Stephan Loescher wrote:
>>
>>
>> Would it be possible (as a new feature) to filter/search/sort for recordings 
>> by recording-lifetime and/or if it is SD
>> or HD?
> 
> I had the same problem (long time ago).
> As a simple solution, I wrote a small python script
> that creates folders with "virtual" recordings
> (symbolic links to the real recordings).
> The tool creates /video/Surround, /video/HD
> and /video/Surround+HD. Inside each of them
> there is the same subfolder structure as under
> /video, except that they contain only the corresponding
> subset.
> 
> Here is the source:
> 
> import os
> import shutil
> import sys
> 
> video_dir = "/video"
> 
> 
> def linkto(root, name):
> 
>components = []
>for root_component in root.split('/')[2:]:
>   components.append(root_component)
>   if root_component.startswith('%'):
>  break
>source = os.path.join(video_dir, '/'.join(components))
>target = os.path.join(video_dir, name, '/'.join(components))
>target_parent = os.path.join(video_dir, name, '/'.join(components[:-1]))
>if not os.path.exists(target_parent):
>   os.makedirs(target_parent)
>os.symlink(source, target)
>   
>   
>   
>  
>   
>   
>   
>  
> for subdir in ("Surround", "HD", "Surround+HD"):
>path = os.path.join(video_dir, subdir)
>if os.path.exists(path):
>   shutil.rmtree(path)
>os.mkdir(path)
>   
>   
>   
>  
> surround_dirs = []
> hd_dirs = []
> surround_hd_dirs = []
> for root, dummy_dirs, files in os.walk(video_dir, followlinks=True):
>if '%' in root and ("info" in files or "info.vdr" in files):
>   surround = False
>   hd = False
>   for line in open(os.path.join(root, "info" if "info" in files else 
> "info.vdr")):
>  if line.startswith("X "):
> if " 5.1" in line:
>surround = True

> elif "high definition Video" in line:
>hd = True

 Ah, the components of a recording.
 Have to look into it, maybe I can detect H.264/MPEG2 encodings.

 I'll add them to my TODO list.

Regards,
Lars.

>   if surround:
>  surround_dirs.append(root)
>   if hd:
>  hd_dirs.append(root)
>   if surround and hd:
>  surround_hd_dirs.append(root)
> 
> for root in surround_dirs:
>linkto(root, "Surround")
> for root in hd_dirs:
>linkto(root, "HD")
> for root in surround_hd_dirs:
>linkto(root, "Surround+HD")
> 
> 
> 
> Cheers, Carsten.
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PLUGIN] recsearch - a simple search for recordings

[Lars Hanisch]

Hi,

Am 21.01.2014 21:31, schrieb Joerg Bornkessel:
> 
>> Hi,
> 
> Thanks Lars,
> very usefull plugin :)
> 
> some hints...
> 
> can you please name your release tags with a proper name?
> i.e v0.2.2 > vdr-recsearch-0.2.2.tar.gz
> this makes it more clear, if you mirror the files in the WWW

 The tar.gz is generated by GitHub. Of course I could prefix the version with 
"recsearch-", but on other
git-web-platforms these kind of tags looks weird, see

 http://projects.vdr-developer.org/git/vdr.git/tag/?id=vdr-2.0.5

 Actually the pure version number is the best tag, since then it can be easily 
used with git-buildpackage, see "the
other godfather" :)

 https://github.com/torvalds/linux/releases

 On my debian-branch I can just ran

 git-buildpackage -tc

 with the following gbp.conf (will add that to my git):

[DEFAULT]
upstream-branch = master
debian-branch = debian

[git-buildpackage]
upstream-tag = v%(version)s

 Hm, writing this, of course I can configure git-buildpackage to recognize 
other version tags... should have omit the
'v'... :)

> in the untared package it should be named
> recsearch-0.0.2

 For the yaVDR Launchpad PPA I use:
 git archive --format=tar.gz --prefix=vdr-plugin-recsearch-0.2.2/ 
--output=../vdr-plugin-recsearch_0.2.2.orig.tar.gz
origin/master

 With this you can do whatever you need with the tarball.

> I know, there is no standard, but a closer look over the shoulder how
> the godfather KLS himself it does, should be a good orientation :)
> 
> the 2 files last.conf searches.conf should be handled in the vdr
> cache dir, not in the vdr plugins dir?
> else as you can the templates easy handle by the plugins colored
> buttons on OSD

 I decided to use the config-dir, because "cache-dir" sounds a bit "volatile" 
(a good place for e.g. epg.data which can
fully be rebuild) and the resource-dir should/may be read-only. And after all 
they are configuration files.

> anyway, this is crying on highest level ;)

 That's good. :)

> thanks

 I thank you for your comments.

Lars.

> 
> /dev/joerg
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] softhddevice and alsa dmixer

[Lars Hanisch]

Hi,

Am 13.02.2014 17:01, schrieb Poubelle:
> I would use the same xbmc softhddevice time . It works with the command:
> svdrsend PLUG softhdevice ATTA
> But I have a problem with the sound output. Softhddevice only supports ALSA 
> therefore no possibility of using PULSEAUDIO .
> I would like to share my SPDIF between XBMC and Softhddevice .
> 
> I run vdr with the following command line :
> 
> vdr -P'sofhddevice -v vdpau -v -a plughw : 0,1 '

 You can use the pulse-ALSA-module for connecting softhddevice to pulseaudio 
with "-a pulse" or an .asoundrc with

pcm.pulse {
  type pulse
}

ctl.pulse {
  type pulse
}

Regards,
Lars.

> 
> My .asoundrc file :
> pcm.dmixer {
>   type dmix
>   ipc_key 2048
>   slave {
> pcm "hw:0,1" # Always use pure hw. dmix will reformat/resample audio.
> period_size 512 # If you get stuttering/or non-working audio, fiddle 
> around with these
> buffer_size 4096
> rate 48000 # HDMI, I'll assume 48kHz
> format S16_LE # Should be default for pretty much any soundcard.
>   }
>   bindings {
> 0 0
> 1 1
>   }
> }
> 
> pcm.!default {
>   type plug
>   slave.pcm dmixer
> }
> 
> 
> My aplay -l output :
>  Liste des Périphériques Matériels PLAYBACK 
> carte 0: NVidia [HDA NVidia], périphérique 0: ALC1200 Analog [ALC1200 Analog]
>   Sous-périphériques: 1/1
>   Sous-périphérique #0: subdevice #0
> carte 0: NVidia [HDA NVidia], périphérique 1: ALC1200 Digital [ALC1200 
> Digital]
>   Sous-périphériques: 1/1
>   Sous-périphérique #0: subdevice #0
> carte 0: NVidia [HDA NVidia], périphérique 3: HDMI 0 [HDMI 0]
>   Sous-périphériques: 1/1
>   Sous-périphérique #0: subdevice #0
> 
> The options are tested:
> 
> XBMC SPDIF solfthddevice with -a plughw : 0.1 => XBMC OK, VDR no sound
> XBMC Default , solfthddevice with -a plughw : 0,1 => XBMC no sound, VDR OK
> XBMC Default ; solfthddevice with -a dmix => XBMC no sound, VDR OK
> 
> The only solution that works is :
> XBMC SPDIF solfthddevice with -a plughw : 0,3 (HDMI) : OK XBMC , VDR OK
> 
> but the HDMI sound on my TV is bad, this is why I like to have everything on 
> the SPDIF.
> 
> Senufo
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] CAM questions

[Lars Hanisch]

Hi,

Am 23.05.2014 01:54, schrieb jacek burghardt:
> I wonder if this plugin would work for you ? 
> https://github.com/flensrocker/vdr-plugin-ddci/blob/master/README

 This plugin is superseded by ddci2 from here:

 https://github.com/jasmin-j/vdr-plugin-ddci2

 With this plugin, vdr 2.1.6 and a CI from Digital Devices/Linux4Media it's 
possible to decode the TS from any card.

 
http://www.l4m-shop.de/index.php?language=en&cat=c7_Common-Interface-Module-Common-Interface-Module.html

 MTD is not included yet, but is worked on.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TT S2 6400 not working correctly on a single tuner

[Lars Hanisch]

Hi,

Am 28.05.2014 09:03, schrieb Klaus Schmidinger:
> On 28.05.2014 07:59, Richard Scobie wrote:
>> I am currently having problems with either cabling or the Diseq switch 
>> attached to tuner 0 on my TT S2 6400, so as a
>> workaround, I thought I could use the "- D 1" switch to vdr, to force using 
>> tuner 1 only.
>>
>> When I do this, it seems vdr does not see the card as full featured any more 
>> - no MPEG decoder and no OSD:
>> ...
> 
> That's because the "full featured" part of the TT S2-6400 is linked to tuner 
> 0.

 I'm not a DVB-S user, but maybe you can use the diseqc.conf to bound device 1 
(tuner 0) to a source you haven't in your
channels.conf (like a none existing S1E).

 OTOH you can write a plugin which provides an device hook, that returns always 
false in "DeviceProvidesTransponder" if
the given device is a cDvbDevice and has an adapter/frontend of 0/0.

Lars.

> 
> Klaus
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

[Lars Hanisch]

Hi,

 There's also the "suspendoutput" plugin. I don't know, where its upstream is 
currently located, but it's available in
the yavdr-PPA:

 
https://launchpad.net/~yavdr/+archive/ubuntu/unstable-vdr/+sourcepub/4067463/+listing-archive-extra

 As far as I know it stops live TV so the device (streamdev-client in this 
case) has no receivers anymore and the server
is free for another client.

Regards,
Lars.

Am 08.07.2014 15:41, schrieb Norm Dressler:
> Thanks for the good info in this thread.  I have done a couple of things.  I 
> have configured irexec and the power off in
> vdr to shutdown vdr on the client, and another button to start up vdr.  That 
> seems to do the trick for the time being.
> Also I've matched the framerate from video to TV and it is much better - 
> thanks Thomas!
> 
> I have 2 other issues with the RPI:
> On an older LCD with a buggy edid, when I turn off the TV, then turn it back 
> on I must reset the RPI at just the right
> time to get video back.  It doesn't seem to be sending an HDMI command to 
> reset (or whatever command it needs) at any
> point.  
> Also on this older TV, any non-2 channel audio is being heard.  Anyone know 
> how to downgrade 5 or 6 channel sound to 2
> channel for proper HDMI out?
> 
> Regarding shutdown based on whether the TV is on or not, perhaps CEC could 
> help in most instances.  In my case with the
> one older TV it wouldn't help but that's my problem.  :)
> 
> Norm
> 
> 
> On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer  > wrote:
> 
> Hi
> 
> > When I'm watching TV with one of the RPI's and want to move to the other
> > RPI, I cannot change the channel from what the first RPI was viewing.  
> I am
> > not sure how to tell streamdev to stop streaming so that I can watch TV 
> on
> > the other RPI?  I hope I've been clear with that - it does sound a bit
> > confusing.  I know there is a mainmenu entry that says suspend server, 
> but
> > it didn't seem to do anything, unless its done in the background.
> 
> Especially for devices like Raspberry Pi it would be very nice to have 
> kind of a "standby" function in VDR, which
> detaches active receivers and call an appropriate function on the primary 
> device to suspend and blank the output.
> Then resuming VDR would only take a fraction of a second...
> 
> > In regards to the rpihddevice I am seeing some tearing or 'flutter' when
> > there is high motion with 1080 HD.  Its not so bad that it isn't usable 
> -
> > it most certainly works 99% of the time just fine.
> 
> Have you set the HDMI frame rate according your video format?
> 
> > The one feature I miss
> > with the rpihddevice that softhddevice had was the automatic zoom - 
> hoping
> > that gets added to the wish list at some point.
> 
> I'm afraid this might take a while, since accessing the decoded image is 
> not that easy, however possible. But
> rpihddevice supports the ScaleVideo() method, so in principle it's 
> possible to do it manually.
> 
> Regards,
> Thomas
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org 
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

[Lars Hanisch]

Am 09.07.2014 18:47, schrieb Lars Hanisch:
> Hi,
> 
>  There's also the "suspendoutput" plugin. I don't know, where its upstream is 
> currently located, but it's available in
> the yavdr-PPA:
> 
>  
> https://launchpad.net/~yavdr/+archive/ubuntu/unstable-vdr/+sourcepub/4067463/+listing-archive-extra

 vdr-wiki is back online, here's the official source:

 http://phivdr.dyndns.org/vdr/vdr-suspendoutput/

Lars.

> 
>  As far as I know it stops live TV so the device (streamdev-client in this 
> case) has no receivers anymore and the server
> is free for another client.
> 
> Regards,
> Lars.
> 
> Am 08.07.2014 15:41, schrieb Norm Dressler:
>> Thanks for the good info in this thread.  I have done a couple of things.  I 
>> have configured irexec and the power off in
>> vdr to shutdown vdr on the client, and another button to start up vdr.  That 
>> seems to do the trick for the time being.
>> Also I've matched the framerate from video to TV and it is much better - 
>> thanks Thomas!
>>
>> I have 2 other issues with the RPI:
>> On an older LCD with a buggy edid, when I turn off the TV, then turn it back 
>> on I must reset the RPI at just the right
>> time to get video back.  It doesn't seem to be sending an HDMI command to 
>> reset (or whatever command it needs) at any
>> point.  
>> Also on this older TV, any non-2 channel audio is being heard.  Anyone know 
>> how to downgrade 5 or 6 channel sound to 2
>> channel for proper HDMI out?
>>
>> Regarding shutdown based on whether the TV is on or not, perhaps CEC could 
>> help in most instances.  In my case with the
>> one older TV it wouldn't help but that's my problem.  :)
>>
>> Norm
>>
>>
>> On Tue, Jul 8, 2014 at 6:59 AM, Thomas Reufer > <mailto:tho...@reufer.ch>> wrote:
>>
>> Hi
>>
>> > When I'm watching TV with one of the RPI's and want to move to the 
>> other
>> > RPI, I cannot change the channel from what the first RPI was viewing.  
>> I am
>> > not sure how to tell streamdev to stop streaming so that I can watch 
>> TV on
>> > the other RPI?  I hope I've been clear with that - it does sound a bit
>> > confusing.  I know there is a mainmenu entry that says suspend server, 
>> but
>> > it didn't seem to do anything, unless its done in the background.
>>
>> Especially for devices like Raspberry Pi it would be very nice to have 
>> kind of a "standby" function in VDR, which
>> detaches active receivers and call an appropriate function on the 
>> primary device to suspend and blank the output.
>> Then resuming VDR would only take a fraction of a second...
>>
>> > In regards to the rpihddevice I am seeing some tearing or 'flutter' 
>> when
>> > there is high motion with 1080 HD.  Its not so bad that it isn't 
>> usable -
>> > it most certainly works 99% of the time just fine.
>>
>> Have you set the HDMI frame rate according your video format?
>>
>> > The one feature I miss
>> > with the rpihddevice that softhddevice had was the automatic zoom - 
>> hoping
>> > that gets added to the wish list at some point.
>>
>> I'm afraid this might take a while, since accessing the decoded image is 
>> not that easy, however possible. But
>> rpihddevice supports the ScaleVideo() method, so in principle it's 
>> possible to do it manually.
>>
>> Regards,
>> Thomas
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org <mailto:vdr@linuxtv.org>
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] softhddevice fails to compile

[Lars Hanisch]

Hi,

Am 14.08.2014 um 19:51 schrieb cedric.dew...@telfort.nl:
> Hi All,
> 
> I am trying to compile softhddevice. how can I solve below error?

 Don't you have the vdr pkgconfig file vdr.pc installed? It's missing the right 
CFLAGS and CXXFLAGS from the vdr
settings for plugins (like -fPIC).

Regards,
Lars.

> Kind regards,
> Cedric
> 
> /vdr-plugin-softhddevice$ make
> Makefile:115: CFLAGS not set
> Makefile:118: CXXFLAGS not set
> cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
> -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
>  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU 
> -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
> -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o video.o 
> video.c
> cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
> -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
>  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU 
> -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
> -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o audio.o 
> audio.c
> cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
> -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
>  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU 
> -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
> -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o codec.o 
> codec.c
> codec.c: In function ‘Codec_get_buffer’:
> codec.c:217:2: warning: ‘age’ is deprecated (declared at 
> /usr/include/libavcodec/avcodec.h:1063) [-Wdeprecated-declarations]
> codec.c:248:2: warning: ‘age’ is deprecated (declared at 
> /usr/include/libavcodec/avcodec.h:1063) [-Wdeprecated-declarations]
> codec.c: In function ‘CodecAudioDecode’:
> codec.c:1474:5: warning: ‘avcodec_decode_audio3’ is deprecated (declared at 
> /usr/include/libavcodec/avcodec.h:4131)
> [-Wdeprecated-declarations]
> cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
> -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
>  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU 
> -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
> -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o 
> ringbuffer.o ringbuffer.c
> g++  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
> -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
>  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU 
> -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
> -g -W -Wall -Wextra -Winit-self -Werror=overloaded-virtual  -shared 
> softhddevice.o softhddev.o video.o audio.o codec.o
> ringbuffer.o -lasound   -lvdpau   -lxcb-screensaver -lxcb-dpms -lxcb   -lrt 
> -lavcodec -lX11-xcb -lX11 -lxcb-icccm
> -lxcb   -o libvdr-softhddevice.so
> /usr/bin/ld: softhddevice.o: relocation R_ARM_THM_MOVW_ABS_NC against 
> `Remotes' can not be used when making a shared
> object; recompile with -fPIC
> softhddevice.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make: *** [libvdr-softhddevice.so] Error 1
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] softhddevice fails to compile

[Lars Hanisch]

Hi,

Am 15.08.2014 um 02:28 schrieb cedric.dew...@telfort.nl:
> Hi Lars,
> I do have 3 directories with .pc files on my system:
> root@a20-OLinuXino:/# cd /usr/
> root@a20-OLinuXino:/usr# find -iname pkgconfig
> ./local/lib/pkgconfig
> ./share/pkgconfig
> ./lib/arm-linux-gnueabihf/pkgconfig
> ./lib/pkgconfig

 Which version of vdr do you use? It should be part of vdr-dev on the 2.0.x 
branch.

Regards,
Lars.

> 
> kind regards,
> Cedric
> 
>> Origineel Bericht
>> Van : cedric.dew...@telfort.nl
>> Datum : 15/08/2014 02:22
>> Aan : vdr@linuxtv.org
>> Onderwerp : Re: [vdr] softhddevice fails to compile
>>
>> Hi Lars,
>>
>> I don't have vdr.pc anywhere on my system:
>> root@a20-OLinuXino:/usr# cd /
>> root@a20-OLinuXino:/# find -iname vdr.pc
>> root@a20-OLinuXino:/#
>>
>> Where can I get this file for debian on an Allwinner A20? 
>>
>> I already installed vdr-dev:
>> root@a20-OLinuXino:~# apt-get install vdr-dev
>> Reading package lists... Done
>> Building dependency tree   
>> Reading state information... Done
>> vdr-dev is already the newest version.
>>
>> Kind regards,
>> Cedric
>>
>>> Origineel Bericht
>>> Van : d...@flensrocker.de
>>> Datum : 14/08/2014 22:41
>>> Aan : vdr@linuxtv.org
>>> Onderwerp : Re: [vdr] softhddevice fails to compile
>>>
>>> Hi,
>>>
>>> Am 14.08.2014 um 19:51 schrieb cedric.dew...@telfort.nl:
 Hi All,

 I am trying to compile softhddevice. how can I solve below error?
>>>
>>> Don't you have the vdr pkgconfig file vdr.pc installed? It's missing the 
>>> right CFLAGS and CXXFLAGS from the vdr
>>> settings for plugins (like -fPIC).
>>>
>>> Regards,
>>> Lars.
>>>
 Kind regards,
 Cedric

 /vdr-plugin-softhddevice$ make
 Makefile:115: CFLAGS not set
 Makefile:118: CXXFLAGS not set
 cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
 -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS 
 -DUSE_VDPAU -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
 -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o 
 video.o video.c
 cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
 -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS 
 -DUSE_VDPAU -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
 -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o 
 audio.o audio.c
 cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
 -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS 
 -DUSE_VDPAU -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
 -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o 
 codec.o codec.c
 codec.c: In function ‘Codec_get_buffer’:
 codec.c:217:2: warning: ‘age’ is deprecated (declared at 
 /usr/include/libavcodec/avcodec.h:1063) [-Wdeprecated-declarations]
 codec.c:248:2: warning: ‘age’ is deprecated (declared at 
 /usr/include/libavcodec/avcodec.h:1063) [-Wdeprecated-declarations]
 codec.c: In function ‘CodecAudioDecode’:
 codec.c:1474:5: warning: ‘avcodec_decode_audio3’ is deprecated (declared 
 at /usr/include/libavcodec/avcodec.h:4131)
 [-Wdeprecated-declarations]
 cc  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
 -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS 
 -DUSE_VDPAU -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
 -g -W -Wall -Wextra -Winit-self -Wdeclaration-after-statement   -c -o 
 ringbuffer.o ringbuffer.c
 g++  -I/usr/include/alsa -DPLUGIN_NAME_I18N='"softhddevice"' 
 -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000   
  -DUSE_PIP -DUSE_VDR_SPU -DUSE_ALSA -DUSE_OSS 
 -DUSE_VDPAU -DUSE_SCREENSAVER  -DGIT_REV='"4a4de36"' 
 -g -W -Wall -Wextra -Winit-self -Werror=overloaded-virtual  -shared 
 softhddevice.o softhddev.o video.o audio.o codec.o
 ringbuffer.o -lasound   -lvdpau   -lxcb-screensaver -lxcb-dpms -lxcb   
 -lrt -lavcodec -lX11-xcb -lX11 -lxcb-icccm
 -lxcb   -o libvdr-softhddevice.so
 /usr/bin/ld: softhddevice.o: relocation R_ARM_THM_MOVW_ABS_NC against 
 `Remotes' can not be used when making a shared
 object; recompile with -fPIC
 softhddevice.o: could not read symbols: Bad value
 collect2: ld returned 1 exit status
 make: *** [libvdr-softhddevice.so] Error 1


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr with different type DVB tuners

[Lars Hanisch]

Am 15.12.2014 um 19:44 schrieb Antti Hartikainen:
> On Mon, Dec 15, 2014 at 08:31:41PM +0200, Jari Fredriksson wrote:
[...]
> If you plan to add more DVB-T tuners, then better way would be patching 
> drivers or VDR to ignore DVB-T capability for the DVB-C tuner.

 This can be solved with a plugin that makes use of the device-hooks provided 
by vdr.
 UFO @ vdr-portal.de wrote a proof-of-concept plugin[1], but you have to 
"configure" this plugin on compile time, see [2].

 Maybe someone should extend this plugin with some OSD menus etc.

Lars.

[1] http://www.escape-edv.de/endriss/vdr/vdr-delsys-0.0.1.tgz
[2] 
http://www.vdr-portal.de/board1-news/board101-news-archiv/p1047621-announce-vdr-developer-version-1-7-23/?#post1047621

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 2.1.7

[Lars Hanisch]

Hi,

Am 18.01.2015 um 15:40 schrieb Joerg Bornkessel:
> Am 18.01.2015 15:11, schrieb Manuel Reimer:
>> 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?

 Yes, I should have documented that feature a bit... My fault, will try to do 
in the next days.

> 
>> Have a look at the vdr4arch repository: 
>> https://github.com/VDR4Arch/vdr4arch
> 
>> We already used this feature using the patch created by Lars.
> 
>> This new feature is especially useful when using systemd or other
>> event driven init systems. It now no longer is required to
>> "somehow" construct a command line. Just start VDR
> 
> 
> Oh Oh, systemd crap...

 It's not only systemd. In fact, it hasn't anything to do with systemd. But it 
helps to strip down the various init
scripts, regardless if systemd, Upstart or SysV.

 And of course everything works with the old scripts. :)

>> vdr4arch places the plugin config files to /etc/vdr/conf.available 
>> first. It's the user's job to create a symlink to /etc/vdr/conf.d
>> to enable the plugin or delete the symlink to disable a plugin.
> 
> this looks like, as has the user a lot of activity to do
> in my opinion, prevent the end user from a lot of editing some files
> or symlinking etc.
> anyway, systemd is not my working place and i will see what ideas
> comes from Lucian M. He is the manager of the systemd crap part in the
> gentoo-vdr-scripts

 It helps distributors for preconfiguring the vdr and its plugins, but also you 
can created multiple conf.d directories
and symlink the one or the other to /etc/vdr/conf.d to test different 
configuration without messing with the old and
working config.

 Just play a bit with it, you may find it helpful. "vdr --showargs[=DIR]" will 
output all options from /etc/vdr/conf.d
or the given directory. You might even use this to generate lines for "old 
style" init scripts with all options on the
commandline.

Lars.

> 
> Thx for your reply
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New conf.d support + ONEDIR option. Need opinions.

[Lars Hanisch]

Hi,

Am 29.01.2015 um 18:28 schrieb VDR User:
> VDR-2.1.7 added the following:
> 
> - 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.
> 
> It seems like this is a welcome change. I plan on moving my command
> line options into a single .conf I can share with all my VDR clients
> for convenience, and to simplify my tv script. But, I also take
> advantage of the ONEDIR option in Make.config because it's easier for
> me to keep track of & backup all of VDRs files. And I hate having
> files spread all over the place anyways. For those unfamiliar:
> 
> # Use 'make ONEDIR=1' to have all data in one single directory:
> ifdef ONEDIR
> VIDEODIR = /video
> CACHEDIR = $(VIDEODIR)
> CONFDIR  = $(VIDEODIR)
> RESDIR   = $(VIDEODIR)
> endif
> 
> To stay in line with the idea that ONEDIR actually keeps all data in
> one single directory, it makes sense that $ARGSDIR (where the conf.d
> files would otherwise go) be included as well. Otherwise, ONEDIR isn't
> actually consolidating all VDR data.
> 
> I'm proposing adding ARGSDIR = $(VIDEODIR) to the ONEDIR ifdef. If
> anyone can think of a good reason not to do this, please voice your
> opinion.

 Klaus forwarded this to vdr-portal.de. I think vdr 2.1.8 will include a patch 
to add

 ARGSDIR = $(VIDEODIR)/conf.d

 to the ONEDIR case. Because vdr reads all *.conf files from ARGSDIR, you 
cannot use VIDEODIR because of setup.conf,
channels.conf etc.

 And I should have documented this feature in more detail (and I will do), as 
time permits next week.

Lars.

> 
> Thanks
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Documentation and thoughts on ARGSDIR (first draft)

[Lars Hanisch]

Hi,

 I wrote down the thoughts I had in mind when developing the conf.d patch which 
got integrated in vdr 2.1.7.

 Also I like to give some advice to distributors how I think, this feature 
should be used. If we can agree on a
consistent naming and file-layout all users can profit.

 At the end there's an RFC for an interface to a not-yet-written tool "vdrctl" 
for managing the args-conf-files.

 Any comments and improvements are welcome.

Regards,
Lars.


Using ARGSDIR
-

The target of the "conf.d patch" is to simplify the start of vdr esp. with the 
newer init systems Upstart and systemd.
These systems expect a single "exec" line to start a daemon. Additionally they 
provide mechanism for monitoring, restart
on failure and controlled stopping on shutdown with defined dependencies.

In the past vdr needed a long list of options, every plugin had to be 
mentioned, and if a plugin also needs options, the
commandline gets longer and confusing. There's also the runvdr template for 
controlling the start and restart of vdr,
which has to be adjusted to your personally needs, which makes it difficult for 
distributions to update these script.
That is why the different distributions developed their own starting mechanisms 
and reading options for vdr and plugins
from different files. Now with all options separated from the starting script, 
it will be easier to share the same
configuration on different platforms and improve helping each other in adding 
the right options to your vdr installation.

By default, the conf-files are located at /etc/vdr/conf.d, of course this can 
be changed via the Make.config, but not on
the commandline itself, because a vdr with an option won't read the options 
from the conf-files to maintain backwards
compatibility, so you can't choose a directory on demand. But what you can do, 
is to symlink different files to your
conf.d-directory or even symlink the whole directory, to adjust your 
configuration. Additionally the directory can be
retrieved by using "pkg-config --variable=argsdir vdr".

To check the current configuration the vdr would use if you start it right now, 
you can call "vdr --showargs".

Here's an example from my installation:

  $ vdr --showargs
  --video=/srv/vdr/video.00
  --config=/var/lib/vdr
  --lib=/usr/lib/vdr/plugins
  --record=/usr/lib/vdr/vdr-recordingaction
  --shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
  --epgfile=/var/cache/vdr/epg.data
  --user=vdr
  --grab=/tmp
  --port=6419
  --resdir=/usr/share/vdr
  --cachedir=/var/cache/vdr
  --dirnames=,,1
  --watchdog=0
  --userdump
  --plugin=epg2vdr
  --plugin=channellists
  --plugin=sundtek
  --plugin=avahi4vdr
  --plugin=dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks
--shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper 
--upstart
  --plugin=epgsearch -f /usr/bin/svdrpsend
  --plugin=live --port=8008 --ip=0.0.0.0 --log=INFO 
--epgimages=/var/cache/vdr/epgimages
  --plugin=menuorg
  --plugin=vnsiserver -t 10
  --plugin=streamdev-server
  --plugin=softhddevice -D
  --plugin=epgsearchonly
  --plugin=recsearch
  --plugin=restfulapi --port=8002 --ip=0.0.0.0 
--epgimages=/var/cache/vdr/epgimages
--channellogos=/usr/share/vdr-channellogos 
--webapp=/var/lib/vdr/plugins/restfulapi/webapp
  --plugin=quickepgsearch
  --plugin=conflictcheckonly
  --plugin=skindesigner --epgimages=/var/cache/vdr/epgimages
  --plugin=dynamite

The corresponding conf file looks like:

 /etc/vdr/conf.d/vdr.conf
[vdr]
--video=/srv/vdr/video.00
--config=/var/lib/vdr
--lib=/usr/lib/vdr/plugins
--record=/usr/lib/vdr/vdr-recordingaction
--shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
--epgfile=/var/cache/vdr/epg.data
--user=vdr
--grab=/tmp
--port=6419
--resdir=/usr/share/vdr
--cachedir=/var/cache/vdr
--dirnames=,,1
--watchdog=0
--userdump

[epg2vdr]

[channellists]

[sundtek]

[avahi4vdr]

[dbus2vdr]
--shutdown-hooks=/usr/share/vdr/shutdown-hooks
--shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
--upstart

[epgsearch]
-f /usr/bin/svdrpsend

[live]
--port=8008
--ip=0.0.0.0
--log=INFO
--epgimages=/var/cache/vdr/epgimages

[menuorg]

[vnsiserver]
-t 10

[streamdev-server]

[softhddevice]
-D

[epgsearchonly]

[recsearch]

[restfulapi]
--port=8002
--ip=0.0.0.0
--epgimages=/var/cache/vdr/epgimages
--channellogos=/usr/share/vdr-channellogos
--webapp=/var/lib/vdr/plugins/restfulapi/webapp

[quickepgsearch]

[conflictcheckonly]

[skindesigner]
--epgimages=/var/cache/vdr/epgimages

[dynamite]
 end of /etc/vdr/conf.d/vdr.conf

"showargs" takes as an optional parameter a directory. It will read all *.conf 
files from the given directory and prints
the corresponding configuration. This is helpful if you have various 
configurations and want to compare them.

Distributors


In the example above I use a single conf file. For a self maintained 
installation this may be usable, but from the
perspective of a distributor the configuration should be splitted into one file 
per plugin