Re: [vdr] [PATCH] Device power saving feature

2016-06-01 Thread Lars Hanisch
Hi,

Am 26.05.2016 um 17:36 schrieb glenvt18:
> I know about the dynamite plugin, but 1) it does much more then this, 2)
> still requires a VDR patch, which is bigger, 3) doesn't work reliably
> for me and 4) I think this functionality should be part of the VDR
> core.

 I agree with you. I hope, dynamite was a little inspiration for you. :)

 I plan (for several years now, sadly) to break out the udev-part of dynamite 
to make the vdr more dynamic in device
management. The idle-part is a good first step in that direction.

> +  virtual void PowerDown(bool On) {};
> +   ///< Actually powers the device down/up.

 I think the name of the parameter is a bit misleading. With On == true you 
mean, that the device is powered down.
 Either rename the parameter to "Down" or the function to something like 
"PowerSaveMode".

Lars.

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


Re: [vdr] vdr 2.1.2 segfaults in libc using vdr --genindex

2016-02-14 Thread Lars Hanisch
Hi,

Am 14.02.2016 um 11:18 schrieb g.bruno:
> Hallo Klaus,
> 
> I already tried VDR version 2.2.0, but it does not run, because the 
> VDR-plugin-xineliboutput is missing for this
> Version. The Version I used with VDR 2.1.2 does not compile.

 Have you tried the latest commits from:
 git clone git://projects.vdr-developer.org/xineliboutput.git

 It's better to fix xineliboutput as to work with old vdr versions. :)
 If you have problems with compiling xineliboutput, please ask.

 At yavdr we use some patches to compile it with recent libcec versions. They 
are attached, look at the series files for
the order of the patches.

Lars.


xineliboutput-patches.tar.gz
Description: GNU Zip compressed data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] How setup VDR to import external EPG data (XMLTV file)

2016-01-13 Thread Lars Hanisch
Hi,

Am 11.01.2016 um 17:21 schrieb Chris R.:
> Hello
> 
> i have got a rpi2 + dvb-t tuner that run under openelec 6 and VDR for the TV.
> This system work well and i would now import external EPG data...
> 
> i read several thread about xmltv2vdr and it isn't so clear for me :
> 
> - i was thinking of download xmltv file from internet (kazer.org 
>  for france) with a cron task
> 
> - and use xmltv2vdr to import the downloaded file into VDR
> 
> Is it possible to do like this ?

 It should be. Have a look at

 
https://projects.vdr-developer.org/git/vdr-plugin-xmltv2vdr.git/tree/dist/epgdata2xmltv

 It's an add on for the xmltv2vdr plugin, which downloads data from 
epgdata.com, transform the xml files into the xmltv
format and pipes it into the plugin. In the plugin you define at which time of 
day new data should be downloaded, so you
don't have to use an external cron job.
 You have to modify the source according to you epg-source and adjust the 
mapping to the channels.

 Or you can use the "file" import, but I don't have any experience with that. 
If the README doesn't help, you must read
the source...

Lars.

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


[vdr] [PLUGIN] pulsecontrol - configure Pulseaudio via vdr's OSD

2015-12-26 Thread Lars Hanisch
Hi all,

 While releasing yaVDR 0.6[1] (blog post will come after the holidays) I wrote 
a little plugin called pulsecontrol:

 Announce:
 
http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/127846-

 Source:
 https://github.com/flensrocker/vdr-plugin-pulsecontrol

 If you use Pulseaudio for audio output, you can change some settings of it via 
the vdr's OSD like moving a sink-input
between sinks or selecting different card profiles. You can also change the 
passthrough settings of a card.

 If you want to select a specific card profile or sink on vdr's startup, you 
can place a file called "startup.script" in
the plugin's config directory. The plugin will run it while starting. For now 
only two commands are supported:
set-card-profile and move-sink-input. But more will come if needed.

 If there are multiple files with the script-extension in this directory you 
can select and run them via OSD.

 Hopefully someone will find it useful. :)

 A hint for pulseaudio-newbies: if you want to use AC3 etc. passthrough over 
hdmi with softhddevice, select the profile
"output:hdmi-stereo", not "output:hdmi-surround". And don't forget to activate 
passthrough in softhddevice. It's a bit
confusing to use the stereo-profile, but it's the right one. With Kodi you have 
to select it as well.

 Hint 2: On my Asrock HT330 pulseaudio always forgets the selected profile. You 
can modify /etc/pulse/system.pa (or
default.pa) for selecting it or the plugin's startup.script. With "svdrpsend 
plug pulsecontrol list-cards" you can
determine the right card and profile name.

 Bug reports and feature wishes are welcome.

Lars.


[1] 
http://www.vdr-portal.de/board16-video-disk-recorder/board99-distributionen/board96-yavdr/127885-announce-yavdr-0-6-0/

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


Re: [vdr] Softhddevice, 10 dupes per second

2015-10-28 Thread Lars Hanisch
Am 26.10.2015 um 08:39 schrieb Torgeir Veimo:
> Any hope for yavdr 0.6 soon? I presume not supporting multiple
> recording directories out of the box would warrant a new version
> number.

 Hopefully by the end of the year, based on trusty.

Lars.

> 
> On 26 October 2015 at 17:36, Alexander Grothe
>  wrote:
>> Hello,
>>
>> softhddevice does not work terribly well if you use it with a compositor
>> (like compiz) for your desktop environment.
>> In yaVDR a slim window manager (openbox) is used and compositing is disabled
>> by default in the x-server configuration:
>>
>> Section "Extensions"
>>   Option "Composite"Disabled
>> EndSection
>>
>> If you want to use vdr 2.2.0 with yaVDR 0.5, all you have to do is to use
>> the packages from yaVDR's testing PPAs (we won't copy them to stable because
>> the support for multiple video directories has been dropped):
>> sudo add-apt-repository ppa:yavdr/testing-vdr
>> sudo add-apt-repository ppa:yavdr/testing-xbmc
>> sudo add-apt-repository ppa:yavdr/testing-yavdr
>>
>> Create a file for apt to prefer installation of packages from these PPAs:
>> --- cut ---
>> # /etc/apt/preferences.d/yavdr-testing
>>
>> Package: *
>> Pin: release o=LP-PPA-yavdr-testing-vdr
>> Pin-Priority: 1001
>>
>> Package: *
>> Pin: release o=LP-PPA-yavdr-testing-xbmc
>> Pin-Priority: 1001
>>
>> Package: *
>> Pin: release o=LP-PPA-yavdr-testing-yavdr
>> Pin-Priority: 1001
>>
>> --- cut ---
>>
>> And finally run the upgrade:
>> sudo apt-get update && sudo apt-get dist-upgradeAm 26.10.2015 um 00:19
>> schrieb Teemu Suikki:
>>>
>>> Hi!
>>>
>>> I was recently using Yavdr with no real problems, but now I decided to
>>> build my own VDR system on top of Linux Mint. Main reason was that
>>> Yavdr stable still doesn't have vdr 2.2.0..
>>>
>>> I've got everything working nicely, but I have weird "duped frames"
>>> problem with softhhddevice. Video and audio are fine and nicely in
>>> sync, and usually you can't see anything wrong. But fast moving
>>> objects sometimes have "tearing" and jerky movement.
>>>
>>> Also if I open Softhddevice stats from the VDR main menu, I see that
>>> "duped" field increases steadily maybe 9-10 per second! "dropped" and
>>> "missed" stays at zero usually.
>>>
>>> There is nothing special on the log. Sometimes I get logs like this:
>>>
>>> Oct 26 01:09:42 puucee vdr: video: slow down video, duping frame
>>> Oct 26 01:09:42 puucee vdr: video: 22:17:22.060  +55  311   0/\ms  23+7
>>> v-buf
>>> Oct 26 01:10:29 puucee vdr: video: slow down video, duping frame
>>> Oct 26 01:10:29 puucee vdr: video: 22:18:09.380  +53  285   0/\ms  26+7
>>> v-buf
>>>
>>> But as you can see, these are almost a minute apart, and the actual
>>> "duped" count increased by several hundreds already during that time.
>>> So this logged "duping" is normal a/v sync, what I see is something
>>> different.
>>>
>>>
>>> This is VDR 2.2.0, and quite recent softhddevice from yavdr ppa:
>>> 1:0.6.1rc1.git20150924.1231-0yavdr0~trusty
>>>
>>> And the very same hardware worked just nicely with full yavdr install,
>>> with vdr 2.0.x and some old version of softhddevice. Oh, and I have
>>> nvidia GT210.
>>>
>>>
>>
>>
>> ___
>> 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] Simultanous recording doesn't work

2015-05-27 Thread Lars Hanisch
Am 27.05.2015 um 22:35 schrieb Klaus Schmidinger:
 On 27.05.2015 21:02, Marx wrote:
 After upgrade of VDR I can't simultanously record from 2 different programs 
 on DVB-T tuner. Even from the same MUX,
 and additionally  I've got dual tuner. Log doesn't show any error, no 
 conflicts.
 It's timer 1 (62 2038-2155 'Na dobre i na złe - odc. 601 which didn't 
 start, because  timer 1 (61 2033-2355 'Piłka
 nożna  is currently recording.
 Marx


 May 27 20:32:16 wuwek vdr: [2370] timer 1 (65 1958-2245 ' beata~Dobre kino: 
 Blow') set to event Śro 27.05.2015
 20:00-22:35 'Dobre kino: Blow'
 May 27 20:32:16 wuwek vdr: [2370] timer 1 (62 2038-2300 ' beata~Stazysci') 
 set to event Czw 28.05.2015 20:40-22:50
 'Stazysci'
 May 27 20:32:16 wuwek vdr: [2370] timer 1 (61 2118-2330 ' marek~Weekendowy 
 Hit Jedynki - Jestem numerem cztery') set
 to event Pią 29.05.2015 21:20-23:20 'Weekendowy Hit Jedynki - Jestem numerem 
 cztery'
 May 27 20:32:16 wuwek vdr: [2370] timer 1 (67 2158- ' marek~Mechanik: 
 Prawo zemsty') set to event Sob 30.05.2015
 22:00-23:50 'Mechanik: Prawo zemsty'
 May 27 20:32:16 wuwek vdr: [2370] timer 1 (61 2148-2255 'Agenci T. A. R. C. 
 Z. Y.~Agenci T. A. R. C. Z. Y. - odc.
 11/22,~2015.06.02-21:50-wto') set to event Wto 02.06.2015 21:50-22:45 
 'Agenci T. A. R. C. Z. Y. - odc. 11/22,'
 May 27 20:32:17 wuwek vdr: [2373] timer 1 (65 1958-2245 ' beata~Dobre kino: 
 Blow') set to event Śro 27.05.2015
 20:00-22:35 'Dobre kino: Blow'
 May 27 20:32:17 wuwek vdr: [2373] timer 1 (62 2038-2300 ' beata~Stazysci') 
 set to event Czw 28.05.2015 20:40-22:50
 'Stazysci'
 May 27 20:32:17 wuwek vdr: [2373] timer 1 (61 2118-2330 ' marek~Weekendowy 
 Hit Jedynki - Jestem numerem cztery') set
 to event Pią 29.05.2015 21:20-23:20 'Weekendowy Hit Jedynki - Jestem numerem 
 cztery'
 May 27 20:32:17 wuwek vdr: [2373] timer 1 (67 2158- ' marek~Mechanik: 
 Prawo zemsty') set to event Sob 30.05.2015
 22:00-23:50 'Mechanik: Prawo zemsty'
 May 27 20:32:17 wuwek vdr: [2373] timer 1 (61 2148-2255 'Agenci T. A. R. C. 
 Z. Y.~Agenci T. A. R. C. Z. Y. - odc.
 11/22,~2015.06.02-21:50-wto') set to event Wto 02.06.2015 21:50-22:45 
 'Agenci T. A. R. C. Z. Y. - odc. 11/22,'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (61 2033-2355 'Piłka nożna - Liga 
 Europejska - FINAŁ :Dnipro
 Dniepropietrowsk - Sevilla FC ( 1 połowa )') set to event Śro 27.05.2015 
 21:45-23:05 'Piłka nożna - Liga Europejska -
 FINAŁ: Dnipro Dniepropietrowsk - Sevilla FC ( 2 połowa )'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (61 2118-2330 ' marek~Weekendowy 
 Hit Jedynki - Jestem numerem cztery') set
 to event Pią 29.05.2015 21:20-23:20 'Weekendowy Hit Jedynki - Jestem numerem 
 cztery'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (61 2148-2255 'Agenci T. A. R. C. 
 Z. Y.~Agenci T. A. R. C. Z. Y. - odc.
 11/22,~2015.06.02-21:50-wto') set to event Wto 02.06.2015 21:50-22:45 
 'Agenci T. A. R. C. Z. Y. - odc. 11/22,'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (62 2038-2155 'Na dobre i na złe 
 - odc. 601 - Lęki, lęki...') set to event
 Śro 27.05.2015 20:40-21:45 'Na dobre i na złe - odc. 601 - Lęki, lęki...'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (62 2038-2300 ' beata~Stazysci') 
 set to event Czw 28.05.2015 20:40-22:50
 'Stazysci'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (65 1958-2245 ' beata~Dobre kino: 
 Blow') set to event Śro 27.05.2015
 20:00-22:35 'Dobre kino: Blow'
 May 27 20:32:20 wuwek vdr: [19818] timer 1 (67 2158- ' marek~Mechanik: 
 Prawo zemsty') set to event Sob 30.05.2015
 22:00-23:50 'Mechanik: Prawo zemsty'
 May 27 20:32:40 wuwek vdr: [2149] switching device 2 to channel 61 (TVP1 HD 
 OBSOLETE)
 May 27 20:33:00 wuwek vdr: [2149] switching device 2 to channel 61 (TVP1 HD 
 OBSOLETE)
 May 27 20:33:00 wuwek vdr: [2149] timer 6 (61 2033-2355 'Piłka nożna - Liga 
 Europejska - FINAŁ :Dnipro
 Dniepropietrowsk - Sevilla FC ( 1 połowa )') start
 May 27 20:33:00 wuwek vdr: [2149] Title: 'Piłka nożna - Liga Europejska - 
 FINAŁ: Dnipro Dniepropietrowsk - Sevilla FC
 ( 2 połowa )' Subtitle: ''
 May 27 20:33:00 wuwek vdr: [2149] recording file name 'Piłka nożna - Liga 
 Europejska - FINAŁ :Dnipro Dniepropietrowsk
 - Sevilla FC ( 1 połowa )' truncated to 'Piłka nożna - Liga Europejska - 
 FINAŁ'
 May 27 20:33:00 wuwek vdr: [2149] executing 
 '/usr/lib/vdr/vdr-recordingaction before
 /var/lib/video/Piłka_nożna_-_Liga_Europejska_-_FINAŁ/2015-05-27.20.33.61-0.rec'
 May 27 20:33:00 wuwek recordingaction: executing 
 /usr/share/vdr/recording-hooks/R90.custom before recording
 /var/lib/video/Piłka_nożna_-_Liga_Europejska_-_FINAŁ/2015-05-27.20.33.61-0.rec
 May 27 20:33:00 wuwek vdr: [2149] record 
 /var/lib/video/Piłka_nożna_-_Liga_Europejska_-_FINAŁ/2015-05-27.20.33.61-0.rec
 May 27 20:33:00 wuwek vdr: [2149] creating directory 
 /var/lib/video/Piłka_nożna_-_Liga_Europejska_-_FINAŁ
 May 27 20:33:00 wuwek vdr: [2149] creating directory
 /var/lib/video/Piłka_nożna_-_Liga_Europejska_-_FINAŁ/2015-05-27.20.33.61-0.rec
 May 27 20:33:00 wuwek vdr: 

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

2015-04-16 Thread Lars Hanisch
Am 16.04.2015 um 16:09 schrieb VDR User:
[...]
 Dynamite is used by all yaVDR users.
 Restfulapi is now part of OpenELEC.
 
 They sound successful. Unfortunately
 https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/README is
 just an advertisement for yavdr and gives no actual information on
 what exectly restfulapi does. From what I could find searching
 elsewhere, it's just an alternative way to display epg information
 (returned as json or xml formatted). Is this correct?

 Please have a look at:
 https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/API.html

 It's a plugin for communicating with and controlling vdr with http-request, so 
it's a good counterpart for webapps on
smartphones, tablets etc.. There are also the one or other webapp using it, so 
you can benefit from a new user interface
to vdr. It's not just displaying the OSD on a remote screen, it's used for a 
new kind of menu to control the most common
tasks of vdr like browsing EPG, manage timers, view/edit recordings...

 You won't be able to use plugins like tvguide or femon etc. as long as the 
won't publish their data in some way,
restfulapi can consume (via some servicecall or something) and put it into 
json/xml, so the remote can display it in
some useful way.

 For streaming streamdev is used. There were some nice features added to 
streamdev, for example now recordings can be
started at some arbitrary timestamp.

 Here's an announcement of an actual app (unfortunatly in german):
 http://www.vdr-portal.de/board1-news/board2-vdr-news/125859-/

 But this all is not a real replacement for xineliboutput/vdr-sxfe (to come 
back to topic...). :)

Lars.

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


Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

2015-04-15 Thread Lars Hanisch
Am 15.04.2015 um 18:37 schrieb VDR User:
 On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs v...@dachsweb.de wrote:
 Proper server/client has been on the user wishlist for ages. There's
 no reason to be rude to someone looking for something better. If those
 solutions were all that great then there wouldn't be any reason to
 ask. Of all the people who are scolded with `code it yourself then`,
 how many actually can? Probably very very very few, so why bother with
 such useless comments?

 Nonsense, I have not been rude. I have even some examples where I told this
 to other users
 that started coding afterwords. That made it a very useful comment.

 To not say it and miss a change to get it done is useless.
 
 Who, and what have they coded? Project names?

 restfulapi and dynamite are two of them.
 And he encouraged me to start with dbus2vdr.

 Nothing with client/server-streaming yet, but who knows what the future will 
bring. :)

Lars.

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


Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

2015-04-15 Thread Lars Hanisch
Am 15.04.2015 um 22:49 schrieb VDR User:
 On Wed, Apr 15, 2015 at 9:56 AM, Gerald Dachs v...@dachsweb.de wrote:
 To not say it and miss a change to get it done is useless.
 Who, and what have they coded? Project names?

 So, you name me a liar? Would it change something if I would name projects?
 
 I'm genuinely curious who you talked into learning to code, and what
 projects they've done.

 He didn't say that he taught someone to code, but made them start to code on 
something someone need.

 I think there are some misunderstandings here. :)

 Gerald and me met on a VDR user meeting and he convinced me to start on 
something that would make it possible to
start vdr before all dvb-devices are initialised. That was the start of the 
dynamite-patch/plugin.
 And I think, this is a feature that vdr should learn. As soon as time permits 
I will rework on it doing all the things
more right and implementing it more straight forward from what I've learned. 
And without a plugin, just as a patch
that can be activated with a commandline switch.

 No more sleep-loops in boot scripts... :)

Lars.

 Should've been easy enough to do. But, I
 expected nothing more than the completely predictable response you
 gave. I doubt anyone did. People love making claims like that but hate
 backing them up ... you know, for some reason.
 
 ___
 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] Documentation and thoughts on ARGSDIR (first draft)

2015-02-18 Thread Lars Hanisch
Hi,

 There has been some progress around vdrctl.

Am 08.02.2015 um 15:05 schrieb Lars Hanisch:
[...]
 vdrctl
 --
 
 What I like to see in the future is a tool vdrctl which will add/remove 
 those symlinks or list the available or
 actived plugins etc. I would like to only specify an API for this tool, so 
 every distribution can develop its own tool.
 Of course there can be a reference implementation like a simple shell-, Perl- 
 or Python-script.
 
 In the following ARGSDIR is the configured conf.d path in your Make.config 
 (or read by pkg-config).
 AVAILDIR is ARGSDIR/../conf.avail if not another directory is given.
 Filenames are the names of the files without their directory.
 
 Usage:
   vdrctl [global options] command [command options]
 
 Global options:
   --argsdir=directory
 read files from directory instead of ARGSDIR
   --availdir=directory
 read files from directory instead of ARGSDIR/../conf.avail
 
 Commands:
 
 list
   (without options)
   print a sorted list of all configuration files from AVAILDIR
 
   --enabled
   print a sorted list of all configuration files from ARGSDIR
 
   --disabled
   print a sorted list of all configuration files from AVAILDIR which are not 
 symlinked to ARGSDIR
 
 enable filename
   create a symlink in ARGSDIR pointing to the file in AVAILDIR
 
 disable filename
   remove the symlink in ARGSDIR
 
 edit filename
   start an editor so the user can add/remove options to the file in AVAILDIR

Added a new command:

 status
   print a list of all available configuration files and if it's enabled 
(symlinked),
   disabled (no symlink in ARGSDIR) or static (regular file in ARGSDIR).

 A reference implementation has been started on github:

  https://github.com/CReimer/vdrctl

 For the next vdr developer release I will send a patch so it will possible to 
print the commandline help of a single
plugin instead of having the help of vdr and the given plugin. And maybe the 
help will have a (selectable) custom
format, so it can be directly used in a conf-file. In the extended_edit-branch 
this help is embedded into the conf-file
when invoking vdrctl edit (and is removed before saving it, just like git or 
mercurial are doing it with commit messages).

 A kind of useful tool, if you have made the work and split all the parameters 
across some files.

Stay tuned...

Lars.

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


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

2015-02-18 Thread Lars Hanisch
Am 18.02.2015 um 22:17 schrieb Tobi:
 Just a quick thumbs for the whole ARGSDIR feature!
 
 Most likely I'll start migrating the Debian VDR package to this with the
 2.2.0 release.

 Great news! I'm looking forward to it!

Lars.

 
 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] Restart of frontend

2015-02-15 Thread Lars Hanisch
Am 15.02.2015 um 07:57 schrieb cedric.dew...@telfort.nl:
 
 We have no times for this isolated feature of starting X and vdr
 parallel, because we do more.
 We don't use lircd, but eventlircd, because eventlircd has not to wait
 until the remote devices are ready, so the vdr don't need to wait for
 them too.
 Many current dvb tuners need long time to get ready, sometimes because
 usb enumeration happens late, or firmware has to be loaded. For this
 Lars has invented the dynamite plugin that collects tuners when they are
 ready and gives them to the vdr.
 Other distributions have to wait with the vdr start till the last dvb
 tuner is ready. We don't wait for any of them. The vdr will show a
 picture when the first tuner comes ready. Of course it is very hardware
 related, but 10 seconds from bios post till live tv is possible. We had
 even some customized setups that did it in 6 seconds.

 Gerald

 Hi Gerald,
 
 This sounds great. What is the name of the distribution you are refering to?

 As he is the founder of yaVDR, it's yaVDR. :)

Lars.

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


Re: [vdr] Restart of frontend

2015-02-14 Thread Lars Hanisch
Am 13.02.2015 um 01:28 schrieb René:
 
 On 13.02.2015 01:22, Joerg Riechardt wrote:
 start softhddevice suspended: ./vdr -P'softhddevice -g 1920x1080 -s'
 resume softhddevice: svdrpsend plug softhddevice RESU suspend again:
 svdrpsend plug softhddevice SUSP Jörg
 Thanks! I'll try this out. Hopefully a sequence of SUSP and RESU after a
 freeze will wake it up! :-)

 As an alternative you can start softhddevice in detched mode (-D) and use the 
commands DETA/ATTA.

 At yavdr we use this feature to start X and vdr in parallel and attach 
softhddevice when X is ready.
 And you can restart X when softhddevice is detached.

 Difference: if softhddevice is suspended a keypress can resume it 
automatically. And if X isn't ready at this point
you'll get an error (as far as I know).

Lars.

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


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

2015-02-08 Thread 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 and a file 

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

2015-02-01 Thread 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


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

2015-01-18 Thread 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] vdr with different type DVB tuners

2014-12-17 Thread 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] softhddevice fails to compile

2014-08-14 Thread 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] Raspberry Pi, Streamdev + rpihddevice

2014-07-09 Thread 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 tho...@reufer.ch 
 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


Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

2014-07-09 Thread 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 tho...@reufer.ch 
 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] TT S2 6400 not working correctly on a single tuner

2014-05-28 Thread 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] softhddevice and alsa dmixer

2014-02-13 Thread 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] [PLUGIN] recsearch - a simple search for recordings

2014-01-22 Thread 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] [PLUGIN] recsearch - a simple search for recordings

2014-01-20 Thread 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. L98 + HD
 6. L98 + 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

2014-01-20 Thread 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


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

2014-01-19 Thread 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] [ANNOUNCE] VDR developer version 2.1.3

2014-01-05 Thread 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).
 - Fixed some spellings in positioner.h and Doxyfile (thanks to Ville Skyttä).
 - Changed '%a' to the POSIX compliant '%m' in all scanf() calls (thanks to 
 Ville
   Skyttä).
 - The new function cCamSlot::Decrypt() can be used by derived classes to 
 implement a
   CAM slot that can be freely assigned to any device, without being directly 
 inserted
   into the full TS data stream in hardware. A derived class that implements 
 Decrypt()
   will also need to set the new parameter ReceiveCaPids in the call to the 
 cCamSlot
   base class constructor to true

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

2014-01-05 Thread 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 ')' 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

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

2013-12-24 Thread 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 tl...@vorgon.com 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


[vdr] [PATCH] spelling in usage text

2013-11-16 Thread 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] vdr 1.7 - 2.1 upgrade tips (FHS)

2013-11-04 Thread 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] reconnect to lirc socket even if it doesn't exist on startup

2013-10-26 Thread 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 wird in 3:00 Minuten ausschalten

2013-10-17 Thread 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


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

2013-10-16 Thread 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] searching a HW problem

2013-10-15 Thread 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

2013-10-15 Thread 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

2013-10-14 Thread 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] Deactivate a Tuner

2013-08-25 Thread 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 driver.

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 other parameters as usual

 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

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

 Hi,
 thanks for the tips, unfotunately I ended up needing to keep using a
 FF Card for a short while.

 So I followed the CT tip and added a TT C-2300 Cable FF card that is
 not connected to cable at all.
 That part seems to work really well.

 Using the -D parameter in VDR I limited VDR to using the first 4 DVB
 Devices and this is what it gave me:

 Aug 11 11:09:31 localhost vdr: [936] frontend 0/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 Aug 11 11:09:31 localhost vdr: [936] frontend 1/0 provides DVB-C with
 QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DVB-C)
 Aug 11 11:09:31 localhost vdr: [936] frontend 2/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 Aug 11 11:09:31 localhost vdr: [936] frontend 4/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)

 So tuners 1-3 of the Cine S2 and Duoflex are now in use. DBV device 1
 provides nothing but MPEG output.

 I guess I'll keep an eye on the DVB device ordering for a while to see
 how it goes.

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

 Hi,
 well the DVB device numbering is not consistent:

 VDR-Test-Cellar(SDA2):  15:25   [995] frontend 3/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 VDR-Test-Cellar(SDA2):  15:25   [995] frontend 2/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 VDR-Test-Cellar(SDA2):  15:25   [995] frontend 1/0 provides DVB-C with
 QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DVB
 VDR-Test-Cellar(SDA2):  15:25   [995] frontend 0/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)

 VDR-Test-Cellar(SDA2):  05:10   [1018] frontend 3/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 VDR-Test-Cellar(SDA2):  05:10   [1018] frontend 2/0 provides DVB-C with
 QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DV
 VDR-Test-Cellar(SDA2):  05:10   [1018] frontend 1/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 VDR-Test-Cellar(SDA2):  05:10   [1018] frontend 0/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)

 VDR-Test-Cellar(SDA2):  06:52   [1080] frontend 3/0 provides DVB-C with
 QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DV
 VDR-Test-Cellar(SDA2):  06:52   [1080] frontend 2/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 VDR-Test-Cellar(SDA2):  06:52   [1080] frontend 1/0 provides
 DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard)
 VDR-Test-Cellar(SDA2):  06:52   [1080] frontend 0/0 provides
 DVB-S,DVB-S2,DSS with QPSK

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

2013-08-25 Thread Lars Hanisch
Hi,

Am 20.08.2013 08:59, schrieb syrius...@no-log.org:
 Manuel Reimer manuel.rei...@gmx.de 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...

2013-08-25 Thread 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 manuel.rei...@gmx.de 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] Deactivate a Tuner

2013-08-07 Thread 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 other parameters as usual

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] noepg

2013-05-09 Thread 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] RFC: one or many positioners?

2013-04-22 Thread 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


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

2013-04-14 Thread 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] New Makefile system

2013-03-27 Thread 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

2013-03-27 Thread 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


Re: [vdr] New Makefile system

2013-03-25 Thread 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] [ANNOUNCE] 0.1.0

2013-03-23 Thread 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] vdr-1.7.41: what's new way to run vdr out of it's sourcedir?

2013-03-17 Thread 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

2013-03-17 Thread 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

2013-03-17 Thread 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] Femon plugin build failed against vdr-1.7.40

2013-03-10 Thread 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] No data in 8 seconds, queuing no signal image

2013-02-27 Thread 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 demuxer
 Feb 26 15:14:34 media vdr: [11155] receiver on device 2 thread started 
 (pid=0, tid=11155, 

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

2013-02-17 Thread 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 d...@flensrocker.de

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] Red button inconsistency

2013-02-10 Thread 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

2013-02-10 Thread Lars Hanisch
Am 10.02.2013 16:59, schrieb VDR User:
 On Sun, Feb 10, 2013 at 5:17 AM, Lars Hanisch d...@flensrocker.de 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

2013-02-10 Thread 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?

2013-02-10 Thread 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?

2013-02-10 Thread 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] Does anyone see this or is the VDR mailing list broken?

2013-02-06 Thread 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] projects.vdr-developer.org - scheduled maintenance on Saturday/Sunday

2013-01-10 Thread 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


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

2013-01-09 Thread 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_plugin's name.sub.service
type 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 can be
deactivated (e.g. 

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

2013-01-06 Thread 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?

2013-01-06 Thread 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?

2013-01-06 Thread 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


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

2013-01-02 Thread 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] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

2013-01-01 Thread 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

2012-12-28 Thread 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] get a segmentation fault when starting vdr (backtrace included)

2012-12-01 Thread 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

2012-12-01 Thread 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] get a segmentation fault when starting vdr (backtrace included)

2012-11-30 Thread 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 http://gnu.org/licenses/gpl.html
 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:
 http://www.gnu.org/software/gdb/bugs/...
 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 Address 0x4080 out of bounds) 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 Address 0x4080 out of bounds) at tools.h:196
 #1  isempty (s=0x4080 Address 0x4080 out of bounds) 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=optimized out, Index=0, 
 s=s@entry=0x2e531d2 1 01 deu 4:3) at epg.c:81
 #4  0x004a40f3 in cEvent::Parse (this=0x2e43360, s=optimized out) 
 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 
 Recordings, DirName=0x2e412b0 /remote/vdr/Sex_and_the_City_2, 
 Foreground=false, LinkLevel=0) at recording.c:1165
 #8  0x004ed32c in cRecordings::ScanVideoDir (this=0x7fe7c0 
 Recordings, DirName=0x2e25ff0 /remote/vdr, Foreground=false, LinkLevel=0) 
 at recording.c:1180
 #9  0x0052694e in cThread::StartThread (Thread=0x7fe7e0 
 Recordings+32) 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] Digital Devices (Linux 4 Media) 4 port (8 tuner) octopus/Duoflex experiences

2012-11-27 Thread 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

2012-11-27 Thread 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

2012-11-26 Thread 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] [ANNOUNCE] VDR developer version 1.7.32

2012-11-19 Thread 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] [PATCH] correct some includes at plugins

2012-11-18 Thread Lars Hanisch
Hi,

Am 20.10.2012 15:03, schrieb Lars Hanisch:
 Plugins should use
 
 #include vdr/...
 
  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

2012-11-18 Thread 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 vdr/...

   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] Betr: Re: emergency restart is too fast for my USB DVB-T receiver

2012-10-29 Thread 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 v...@dachsweb.de
 To: VDR Mailing List vdr@linuxtv.org
 Subject: Re: [vdr] emergency restart is too fast for my USB DVB-T receiver
 Reply-To: VDR Mailing List vdr@linuxtv.org


 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 ! :)

2012-10-29 Thread 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] [ANNOUNCE] vdr-rotorng-0.3

2012-10-26 Thread Lars Hanisch
Hi,

Am 25.10.2012 19:44, schrieb Morfsta:
 On Thu, Oct 25, 2012 at 5:42 PM, Lars Hanisch d...@flensrocker.de 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

2012-10-25 Thread 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

2012-10-25 Thread 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


[vdr] [PATCH] correct some includes at plugins

2012-10-20 Thread Lars Hanisch
Hi,

Plugins should use

#include vdr/...

 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 vdr/dvbdevice.h
+#include vdr/dvbspu.h
 
 /// 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 vdr/dvbdevice.h
+#include vdr/dvbspu.h
 
 /// 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 vdr/osd.h
 
 class cDvbOsdProvider : public cOsdProvider {
 private:
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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

2012-09-19 Thread 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


Re: [vdr] Quiet times...

2012-08-10 Thread 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] LNB sharing interrupts recordings with Twinhan DVBS

2012-05-09 Thread 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 driver.

Lars.

___
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

2012-05-02 Thread 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


[vdr] [PATCH] vdr 1.7.27, fix UPDR

2012-04-25 Thread 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

2012-04-25 Thread 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 number to\n
   Move a channel to a new position.,
   NEWC settings\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 settings\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] Local frontend - using XBMC strm vs vdr-sxfe

2012-03-10 Thread 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

2012-03-10 Thread 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

2012-03-10 Thread 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

2012-03-10 Thread 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


Re: [vdr] Segfault in dvbhddevice

2012-03-08 Thread Lars Hanisch

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

Lars Hanischd...@flensrocker.de  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. :-)

Advertisement  ;-)
  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...
/Advertisement


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] Segfault in dvbhddevice

2012-03-07 Thread 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. :-)

Advertisement ;-)
 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...
/Advertisement

 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] Theses Client/Server VDR

2012-03-03 Thread 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] [ANNOUNCE] VDR developer version 1.7.23

2012-01-23 Thread 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] [PATCH v2] multi-frontend-support for vdr 1.7.21

2012-01-08 Thread 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] Rotor / Rotor-NG not working with latest VDR

2012-01-03 Thread Lars Hanisch

Hi,

Am 03.01.2012 11:43, schrieb Morfsta:

On Sun, Dec 25, 2011 at 12:32 PM, ilia maneilmim...@gmail.com  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_castcDeviceSubclass (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] Rotor / Rotor-NG not working with latest VDR

2011-12-24 Thread 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


  1   2   >