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

2012-05-06 Thread Klaus Schmidinger

On 06.05.2012 01:29, Midas wrote:

Am 05.05.2012 16:31, schrieb Klaus Schmidinger:

On 05.05.2012 09:22, Midas wrote:

Hi there,

i have two satellite devices in an lnb-sharing setup. As said in the
topic since update to vdr 1.7.27 recordings do not put data on the disk
anymore and AV liveview with the vdr-sxfe frontend freezes if bonding
sets the Twinhan Card to master.

The setup is Technisat Skystar HD and KWorld DVBS Satellite Card (clone
of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27.

I have been using vdr 1.7.21 before with lnb-sharing applied. In the old
setup there was a similar problem in that switching to vertical didn't
work reliably or at all respectively. I managed to overcome this
behaviour by patching the Twinhan driver to eliminate _any_ voltage
output on the card. Once i found a working patch vdr has been running
for months without any problems anymore.

Note that the 'new' issue occurs with the vanilla Twinhan driver and my
patched version as well.

Is it maybe possible to force the use of one card as Master bonding
device or does anyone have other ideas to overcome the problems?


If the master of a set of bonded devices doesn't get a signal, VDR
should automatically switch the master to the next of the bonded devices.
See cDvbTuner::Action(), case tsTuned:

   if (bondedTuner  bondedMaster)
  bondedMasterFailed = true; // give an other tuner a chance in
case the sat cable was disconnected

Of course, making sure the devices work properly in the first place
might be a good idea ;-)


Do i get the term Master wrong? Master in my assumption should be the
device where the liveview signal comes from unless there is a recording
in which case the device tuned to the recording transponder should be
Master.


In the context of device bonding master means the device that actually
controls the LNB (either trough voltage/tone or DiSEqC). It has nothing to
do with whether this device is used for live view or recording.


 In the first case the slave cannot steal the tuning parameters
to prevent breaking liveview whereas in the second the liveview slave
cannot interefere with the ongoing recording.

Concerning my issue the ongoing search for transponders on the
non-liveview device seems to break with the liveview device which should
not happen. Yet in case of recordings i am bit unsure what interferes
with what. I am also still unsure if it is a driver or lnb sharing issue
though the v/h issue in my former setup points to the first case at
least for a certain kind.

Do i conclude right, setting the bondedMasterFailed to false in the
switch construct would be a dirty hack to workaround my bogus setup?


I'm not sure about that.
I would suggest you use VDR with only one single device at a time and
make sure it can receive all polarizations and bands. If a device or
driver fails to deliver that, you should try to fix it. VDR assumes that
a device actually works ;-)

Klaus

___
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-06 Thread Midas
Am 06.05.2012 11:51, schrieb Klaus Schmidinger:
 On 06.05.2012 01:29, Midas wrote:
 Am 05.05.2012 16:31, schrieb Klaus Schmidinger:
 On 05.05.2012 09:22, Midas wrote:
 Hi there,

 i have two satellite devices in an lnb-sharing setup. As said in the
 topic since update to vdr 1.7.27 recordings do not put data on the
 disk
 anymore and AV liveview with the vdr-sxfe frontend freezes if bonding
 sets the Twinhan Card to master.

 The setup is Technisat Skystar HD and KWorld DVBS Satellite Card
 (clone
 of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27.

 I have been using vdr 1.7.21 before with lnb-sharing applied. In
 the old
 setup there was a similar problem in that switching to vertical didn't
 work reliably or at all respectively. I managed to overcome this
 behaviour by patching the Twinhan driver to eliminate _any_ voltage
 output on the card. Once i found a working patch vdr has been running
 for months without any problems anymore.

 Note that the 'new' issue occurs with the vanilla Twinhan driver
 and my
 patched version as well.

 Is it maybe possible to force the use of one card as Master bonding
 device or does anyone have other ideas to overcome the problems?

 If the master of a set of bonded devices doesn't get a signal, VDR
 should automatically switch the master to the next of the bonded
 devices.
 See cDvbTuner::Action(), case tsTuned:

if (bondedTuner  bondedMaster)
   bondedMasterFailed = true; // give an other tuner a chance in
 case the sat cable was disconnected

 Of course, making sure the devices work properly in the first place
 might be a good idea ;-)

 Do i get the term Master wrong? Master in my assumption should be the
 device where the liveview signal comes from unless there is a recording
 in which case the device tuned to the recording transponder should be
 Master.

 In the context of device bonding master means the device that actually
 controls the LNB (either trough voltage/tone or DiSEqC). It has
 nothing to
 do with whether this device is used for live view or recording.

  In the first case the slave cannot steal the tuning parameters
 to prevent breaking liveview whereas in the second the liveview slave
 cannot interefere with the ongoing recording.

 Concerning my issue the ongoing search for transponders on the
 non-liveview device seems to break with the liveview device which should
 not happen. Yet in case of recordings i am bit unsure what interferes
 with what. I am also still unsure if it is a driver or lnb sharing issue
 though the v/h issue in my former setup points to the first case at
 least for a certain kind.

 Do i conclude right, setting the bondedMasterFailed to false in the
 switch construct would be a dirty hack to workaround my bogus setup?

 I'm not sure about that.
 I would suggest you use VDR with only one single device at a time and
 make sure it can receive all polarizations and bands. If a device or
 driver fails to deliver that, you should try to fix it. VDR assumes that
 a device actually works ;-)

Just to add this missing info: Both devices work perfectly in a single
device setup. Both devices were even capable in the former 1.7.21 dual
device setup (with my patch).

thx

Michael

___
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-06 Thread Klaus Schmidinger

On 06.05.2012 11:59, Midas wrote:

Am 06.05.2012 11:51, schrieb Klaus Schmidinger:

On 06.05.2012 01:29, Midas wrote:

Am 05.05.2012 16:31, schrieb Klaus Schmidinger:

On 05.05.2012 09:22, Midas wrote:

Hi there,

i have two satellite devices in an lnb-sharing setup. As said in the
topic since update to vdr 1.7.27 recordings do not put data on the
disk
anymore and AV liveview with the vdr-sxfe frontend freezes if bonding
sets the Twinhan Card to master.

The setup is Technisat Skystar HD and KWorld DVBS Satellite Card
(clone
of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27.

I have been using vdr 1.7.21 before with lnb-sharing applied. In
the old
setup there was a similar problem in that switching to vertical didn't
work reliably or at all respectively. I managed to overcome this
behaviour by patching the Twinhan driver to eliminate _any_ voltage
output on the card. Once i found a working patch vdr has been running
for months without any problems anymore.

Note that the 'new' issue occurs with the vanilla Twinhan driver
and my
patched version as well.

Is it maybe possible to force the use of one card as Master bonding
device or does anyone have other ideas to overcome the problems?


If the master of a set of bonded devices doesn't get a signal, VDR
should automatically switch the master to the next of the bonded
devices.
See cDvbTuner::Action(), case tsTuned:

if (bondedTuner   bondedMaster)
   bondedMasterFailed = true; // give an other tuner a chance in
case the sat cable was disconnected

Of course, making sure the devices work properly in the first place
might be a good idea ;-)


Do i get the term Master wrong? Master in my assumption should be the
device where the liveview signal comes from unless there is a recording
in which case the device tuned to the recording transponder should be
Master.


In the context of device bonding master means the device that actually
controls the LNB (either trough voltage/tone or DiSEqC). It has
nothing to
do with whether this device is used for live view or recording.


  In the first case the slave cannot steal the tuning parameters
to prevent breaking liveview whereas in the second the liveview slave
cannot interefere with the ongoing recording.

Concerning my issue the ongoing search for transponders on the
non-liveview device seems to break with the liveview device which should
not happen. Yet in case of recordings i am bit unsure what interferes
with what. I am also still unsure if it is a driver or lnb sharing issue
though the v/h issue in my former setup points to the first case at
least for a certain kind.

Do i conclude right, setting the bondedMasterFailed to false in the
switch construct would be a dirty hack to workaround my bogus setup?


I'm not sure about that.
I would suggest you use VDR with only one single device at a time and
make sure it can receive all polarizations and bands. If a device or
driver fails to deliver that, you should try to fix it. VDR assumes that
a device actually works ;-)


Just to add this missing info: Both devices work perfectly in a single
device setup. Both devices were even capable in the former 1.7.21 dual
device setup (with my patch).


Well, then please post your exact setup together with a step-by-step
set of instructions on how to reproduce the problem. Maybe I can reproduce
it here on my system.

Klaus

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


Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0

2012-05-06 Thread Marcel Witte
Am Samstag, 5. Mai 2012 schrieb Matti Lehtimäki matti.lehtim...@gmail.com:
 New features in 0.1.0:
 - Support for character set conversion for selected channels.
 - Support for stripping HTML entities.
 - Supply user with extra information for each setup menu option using 
 Info key.
 
 Homepage for the plugin:
 http://projects.vdr-developer.org/projects/plg-epgfixer
 

Hi,

thanks for the plugin, I started today to build openSUSE-packages for this 
plugin in my repository, but for openSUSE Factory it is failing. Perhaps a 
problem with gcc 4.7?

g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -
D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -
DUSE_DDEPGENTRY -DUSE_JUMPINGSECONDS -DUSE_LIEMIEXT -DUSE_LIRCSETTINGS -
DUSE_PLUGINMISSING -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_WAREAGLEICON -
D_GNU_SOURCE -DPLUGIN_NAME_I18N='epgfixer' -DHAVE_PCREPOSIX -
I/usr/include/vdr/include epgfixer.c
In file included from charset.h:11:0,
 from epgfixer.c:10:
tools.h: In instantiation of 'bool cEpgfixerListT::LoadConfigFile(const 
char*, bool) [with T = cRegexp]':
tools.h:81:50:   required from 'bool cEpgfixerListT::ReloadConfigFile(bool) 
[with T = cRegexp]'
epgfixer.c:76:36:   required from here
tools.h:60:20: error: 'Add' was not declared in this scope, and no 
declarations were found by argument-dependent lookup at the point of 
instantiation [-fpermissive]
tools.h:60:20: note: declarations in dependent base 'cListBase' are not found 
by unqualified lookup
tools.h:60:20: note: use 'this-Add' instead
tools.h: In instantiation of 'bool cEpgfixerListT::LoadConfigFile(const 
char*, bool) [with T = cCharSet]':
tools.h:81:50:   required from 'bool cEpgfixerListT::ReloadConfigFile(bool) 
[with T = cCharSet]'
epgfixer.c:78:37:   required from here
tools.h:60:20: error: 'Add' was not declared in this scope, and no 
declarations were found by argument-dependent lookup at the point of 
instantiation [-fpermissive]
tools.h:60:20: note: declarations in dependent base 'cListBase' are not found 
by unqualified lookup
tools.h:60:20: note: use 'this-Add' instead
make: *** [epgfixer.o] Error 1

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


Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0

2012-05-06 Thread Matti Lehtimäki

On 05/06/2012 03:00 PM, Marcel Witte wrote:

Hi,

thanks for the plugin, I started today to build openSUSE-packages for this
plugin in my repository, but for openSUSE Factory it is failing. Perhaps a
problem with gcc 4.7?


The problem seems to be related to gcc 4.7. Could you try the following 
patch.


diff --git a/tools.h b/tools.h
index dfcee30..bf49fac 100644
--- a/tools.h
+++ b/tools.h
@@ -57,7 +57,7 @@ protected:
   cReadLine ReadLine;
   while ((s = ReadLine.Read(f)) != NULL) {
 if (!isempty(s)) {
-   Add(new T());
+   this-Add(new T());
cListT::Last()-SetFromString(s, true);
}
 }

--
Matti

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


Re: [vdr] probs with new ZDF HDchannels

2012-05-06 Thread Thorsten_Stuppi
Hi,

this solution worked on my SuSE-System after updating xine-lib. So far,
so good. However, on my Debian-System I did update xine-lib as well
(without any harder problems) . Then I edited /.xine/config as discribed
below. But Xine seems not to react on this entry. I can see that config
is written each time I enter Xine-Setup at runtime, but in the
Setup-Window (Engine) there is no entry saying Priority for
vdpau_264_alter decoder.
In consequence, xine does not use this alternative decoder...
Hm, as I said, on the SuSE-System everything is fine...
The only difference, as far as I can see, is that on Debian xine gui
language is english, on the Debian System it is english.

Any ideas?
Thorsten

On 05/01/12 21:18, Reinhard Nissl wrote:
 Hi,
 
 Am 01.05.2012 20:08, schrieb Harald Milz:
 
 I just added the new ZDF HD channels (ZDF, KIKA, ZDF neo, kultur and
 info) and
 I get strange effects like the ones described in
 http://www.heise.de/newsticker/meldung/Neue-HDTV-Sender-Ruckler-auf-bestimmten-Receivern-1564225.html.

 It looks as if the color pallette switched every 0.7 s. This didn't
 happen
 with the old ZDF HD channel. My setup is unchanged. Other HD channels
 are not
 affected.

 Did anyone else observe this, and what can we do to fix this?
 
 You didn't mention your setup in detail, but I assume you're using a
 xine-lib VDPAU based solution.
 
 In my vdr-xine setup I had to switch from vdpau_h264 to vdpau_h264_alter
 decoder. The following lines from ~/.xine/config give vdpau_h264_alter a
 higher priority:
 
 # priority for vdpau_h264 decoder
 # numeric, default: 0
 #engine.decoder_priorities.vdpau_h264:0
 
 # priority for vdpau_h264_alter decoder
 # numeric, default: 0
 engine.decoder_priorities.vdpau_h264_alter:1
 
 Bye.

-- 
Thorsten Stuppi

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


Re: [vdr] probs with new ZDF HDchannels

2012-05-06 Thread Thorsten_Stuppi
Sorry - on SuSE it is german...

On 05/06/12 17:11, Thorsten_Stuppi wrote:
 Hi,
 
 this solution worked on my SuSE-System after updating xine-lib. So far,
 so good. However, on my Debian-System I did update xine-lib as well
 (without any harder problems) . Then I edited /.xine/config as discribed
 below. But Xine seems not to react on this entry. I can see that config
 is written each time I enter Xine-Setup at runtime, but in the
 Setup-Window (Engine) there is no entry saying Priority for
 vdpau_264_alter decoder.
 In consequence, xine does not use this alternative decoder...
 Hm, as I said, on the SuSE-System everything is fine...
 The only difference, as far as I can see, is that on Debian xine gui
 language is english, on the Debian System it is english.
 
 Any ideas?
 Thorsten
 
 On 05/01/12 21:18, Reinhard Nissl wrote:
 Hi,

 Am 01.05.2012 20:08, schrieb Harald Milz:

 I just added the new ZDF HD channels (ZDF, KIKA, ZDF neo, kultur and
 info) and
 I get strange effects like the ones described in
 http://www.heise.de/newsticker/meldung/Neue-HDTV-Sender-Ruckler-auf-bestimmten-Receivern-1564225.html.

 It looks as if the color pallette switched every 0.7 s. This didn't
 happen
 with the old ZDF HD channel. My setup is unchanged. Other HD channels
 are not
 affected.

 Did anyone else observe this, and what can we do to fix this?

 You didn't mention your setup in detail, but I assume you're using a
 xine-lib VDPAU based solution.

 In my vdr-xine setup I had to switch from vdpau_h264 to vdpau_h264_alter
 decoder. The following lines from ~/.xine/config give vdpau_h264_alter a
 higher priority:

 # priority for vdpau_h264 decoder
 # numeric, default: 0
 #engine.decoder_priorities.vdpau_h264:0

 # priority for vdpau_h264_alter decoder
 # numeric, default: 0
 engine.decoder_priorities.vdpau_h264_alter:1

 Bye.
 

-- 
Thorsten Stuppi
Dipl.-Ing. Nachrichtentechnik

Ingenieurbuero Stuppi
Wueppelser Altendeich 14
D-26434 Wangerland

Phone: +49 (0) 44 25 - 96 91 11
GSM:   +49 (0) 160 - 4 22 83 95
FAX:   +49 (0) 180 - 35 51 86 99 86
EMail: i...@stuppi-engineering.de
Site:  http://www.stuppi-engineering.de

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


Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0

2012-05-06 Thread Marcel Witte
Am Sonntag, 6. Mai 2012 schrieb Matti Lehtimäki matti.lehtim...@gmail.com:
 On 05/06/2012 03:00 PM, Marcel Witte wrote:
  Hi,
 
  thanks for the plugin, I started today to build openSUSE-packages for this
  plugin in my repository, but for openSUSE Factory it is failing. Perhaps a
  problem with gcc 4.7?
 
 The problem seems to be related to gcc 4.7. Could you try the following 
 patch.
 
 diff --git a/tools.h b/tools.h
 index dfcee30..bf49fac 100644
 --- a/tools.h
 +++ b/tools.h
 @@ -57,7 +57,7 @@ protected:
 cReadLine ReadLine;
 while ((s = ReadLine.Read(f)) != NULL) {
   if (!isempty(s)) {
 -   Add(new T());
 +   this-Add(new T());
  cListT::Last()-SetFromString(s, true);
  }
   }

Using this Patch it is compiling :) Thanks

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


Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0

2012-05-06 Thread Marx

W dniu 2012-05-05 20:15, Matti Lehtimäki pisze:

New features in 0.1.0:
- Support for character set conversion for selected channels.
- Support for stripping HTML entities.
- Supply user with extra information for each setup menu option using
Info key.

Homepage for the plugin:
http://projects.vdr-developer.org/projects/plg-epgfixer


Hello
I'm tryin charset recoding but no luck.

1) I currently use VDR headless. It means I can't see OSD and so I don't 
know if epgfixer needs some switching on causing some variables 
written to VDR conf file?


2) Could you implement some log messages about conversion?
I know epgfixer starts, but I don't know if it has read configuration 
files and tries to use them.

My configuration is in charset.conf:
1:iso6937
or
iso6937
I've tried also
iso8859-2
but it doesn't seem to recode anything.

3)I test on one channel only:
:aa
TVP 2;CYFRA 
+:10892:HC34M2S0:S13.0E:27500:167=2:108=pol@4:508:100,1813,500,B00,B01:4808:318:11900:0

Unfortunatelly this channel is encrypted.

VDR alone produces sth like this:
May  6 23:52:53 wuwek vdr: [29565] EPG bugfix statistics
May  6 23:52:53 wuwek vdr: [29565] =
May  6 23:52:53 wuwek vdr: [29565] IF SOMEBODY WHO IS IN CHARGE OF THE 
EPG DATA FOR ONE OF THE LISTED
May  6 23:52:53 wuwek vdr: [29565] CHANNELS READS THIS: PLEASE TAKE A 
LOOK AT THE FUNCTION cEvent::FixEpgBugs()
May  6 23:52:53 wuwek vdr: [29565] IN VDR/epg.c TO LEARN WHAT'S WRONG 
WITH YOUR DATA, AND FIX IT!

May  6 23:52:53 wuwek vdr: [29565] =
May  6 23:52:53 wuwek vdr: [29565] Fix Hits Channels
May  6 23:52:53 wuwek vdr: [29565] 7   5TVP 2
It's sign that charset of epg is broken.
I would like to know if this messages is produced after or before 
epgfixer work.


4) I use UTF-8 in system. I have problem how to recognize charset of epg 
on this channel. I was trying to parse /var/cache/vdr/epg.data but it 
seems that encoding is broken. Seems like some polish characters are 
saved on 2 chars (UTF), but it's not proper pair to create polish character.

So instead of:
100 tysięcy bocianów
I'm getting:
100 tysiЮecy bocianТow

Marx


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