[vdr] need help with GOTOX patch.

2009-06-09 Thread lucian orasanu

 Hy,

I want to use this patch, but i dont know how. Only this is necesary to move 
the motor:

S5.0W 11700 V  9750 G v t
S5.0W 9 V 10600 G v T
S5.0W 11700 H  9750 G V t
S5.0W 9 H 10600 G V T


or should be like this:

S1.0W 11700 V  9750 G v t [e0 31 6e 01(this bite should be positon in rotor ?]
S1.0W 9 V 10600 G v T [e0 31 6e 01]
S1.0W 11700 H  9750 G V t [e0 31 6e 01]
S1.0W 9 H 10600 G V T [e0 31 6e 01]

with settings like this my motor wont move!

And in lnb setup menu at degres what should i put there, my position?

How this pach works??


  

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


Re: [vdr] Any really working HD video output systems for VDR?

2009-06-09 Thread Mattia Rossi
On Mon, 2009-06-08 at 21:54 +0200, Georg Acher wrote:
 On Mon, Jun 08, 2009 at 09:40:04PM +0200, Mattia Rossi wrote:
  
  The need for time in such a discovery process, at least on my part, is
  fully understood, I only wish that sometimes the guys from Reel would
  provide a little more documentation (in english) about how they do some
  things in the avantgarde, but this is probably what is actually giving
  the avantgarde the edge over a normal vdr install, so I won't complain.
 
 Just ask, there are no secrets ;) There's just not enough time to guess what
 will be of interest...
 

Hi Georg,
sorry if that came out as 'they are hiding something', I was really
thinking more in terms of 'there are so many variables that the best
combination is probably achieved in an environment where the user has
much less control as we have in a custom vdr compiled environment,
without even taking into account the endless combinations of display
devices that people will want to connect to the eHd'

That said, I really really would like a different option than 'don't use
the scaler on the eHd-HDMI output, it's crap', is there a way to change
the scaling algorithm it uses ?

Is there any other setting we can work on regarding the eHd outputs,
even if they are not listed in the reelbox-3 setup ?

For example, I am using the coax digital output on the eHd mini-din,
instead of the pass through HDMI (the HDMI cable goes straight to the
VPR, the coax cable goes to my main amp), I had to change a couple of
lines in the reelbox-3 plugin in order to allow for AC3 to pass through
the digital output. The option was there, it just wasn't compiled in
because of REELBOXLITE ifdefs

What I would like to achieve is decent quality (either scaled or
unscaled) SD MPEG-2 output, and by decent I mean at least at the same
quality of the MPEG-2 output of a FF card without having to use a 2Keuro
deinterlacer. Please note that I'm talking about MPEG processing
quality, not still image quality 

I understand that this is not easy to fine tune because of all the
different variables and because of all the 'not straightforward' test
environments every single vdr user will have set up.

At the moment my vdr 1.7.x install is really basic (vdr, extensions
patch, reelbox3 filebrowser xinemediaplayer and menuorg plugins) and I
am completely satisfied by the stability (both of vdr and of the eHd) ,
I even don't notice the problems with the recordings handling (the
single frame forward in a recording isn't really working, it looks like
it is skipping from i-frame to i-frame (doesnt'do that when going
backwards, it is the opposite behaviour as with the ff card, where
forward skipping works, while backward skipping goes from i_frame to
i-frame ..)

If this is still not technical enough I'll go back to my test machine,
experiment some more, and come back with more detailed questions ...

Thanks

Mattia
 



-- 
---MR.-


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


Re: [vdr] need help with GOTOX patch.

2009-06-09 Thread Ales Jurik
On Tuesday 09 of June 2009, lucian orasanu wrote:
  Hy,

 I want to use this patch, but i dont know how. Only this is necesary to
 move the motor:

 S5.0W 11700 V  9750 G v t
 S5.0W 9 V 10600 G v T
 S5.0W 11700 H  9750 G V t
 S5.0W 9 H 10600 G V T


 or should be like this:

 S1.0W 11700 V  9750 G v t [e0 31 6e 01(this bite should be positon in rotor
 ?] S1.0W 9 V 10600 G v T [e0 31 6e 01]
 S1.0W 11700 H  9750 G V t [e0 31 6e 01]
 S1.0W 9 H 10600 G V T [e0 31 6e 01]

 with settings like this my motor wont move!
The first config should be ok.

 And in lnb setup menu at degres what should i put there, my position?
Yes, your position.

 How this pach works??
Patch is originaly written by Seppo Ingalsuo 
(http://www.linuxtv.org/pipermail/vdr/2008-March/016164.html).

The patch uses algo from vdr-rotor patch to calculate angle to which motor 
should move and send then the gotox diseqc command [e0 31 6e p1 p2] where p1 
and p2 is calculated angle. If you have dish with closer beam be sure to have 
position of satellites in sources.conf and channels.conf written in right way 
(for example satellites at 1.0W are at 0.83W and 0.75W exactly) to be able to 
receive also weaker transponders.

The patch send this command only when satellite is changing. You should also 
use it for motor behind diseqc switch. The next example is for 4-input diseqc 
switch which has diseqc motor connected to input 4. Please be sure that in 
such way your dvb card will not be overloaded with output current (you should 
use motor which disconnect LNB when moving and card with electronically 
limited output current to prevent damages).

S0.8W 11700 V  9750  t v W15 [E0 10 38 FC] W150 G v t
S0.8W 9 V 10600  t v W15 [E0 10 38 FD] W150 G v T
S0.8W 11700 H  9750  t V W15 [E0 10 38 FE] W150 G V t
S0.8W 9 H 10600  t V W15 [E0 10 38 FF] W150 G V T

BR,

Ales


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


Re: [vdr] need help with GOTOX patch.

2009-06-09 Thread lucian orasanu

I did that, i took my position with an gps, putet ther in lnb config, and 
afther that changing channels.conf form diferent satelites, but i did something 
wrong because i did not manage to get signal, until i setup my antena manualy 
again (form left right switches of motor).

 My idea was to use this patch and stored position from my motor!!

--- On Tue, 6/9/09, Ales Jurik aju...@quick.cz wrote:

 From: Ales Jurik aju...@quick.cz
 Subject: Re: [vdr] need help with GOTOX patch.
 To: vdr@linuxtv.org
 Cc: lucian orasanu o_luc...@yahoo.com
 Date: Tuesday, June 9, 2009, 1:31 PM
 On Tuesday 09 of June 2009, lucian
 orasanu wrote:
   Hy,
 
  I want to use this patch, but i dont know how. Only
 this is necesary to
  move the motor:
 
  S5.0W 11700 V  9750 G v t
  S5.0W 9 V 10600 G v T
  S5.0W 11700 H  9750 G V t
  S5.0W 9 H 10600 G V T
 
 
  or should be like this:
 
  S1.0W 11700 V  9750 G v t [e0 31 6e 01(this bite
 should be positon in rotor
  ?] S1.0W 9 V 10600 G v T [e0 31 6e 01]
  S1.0W 11700 H  9750 G V t [e0 31 6e 01]
  S1.0W 9 H 10600 G V T [e0 31 6e 01]
 
  with settings like this my motor wont move!
 The first config should be ok.
 
  And in lnb setup menu at degres what should i put
 there, my position?
 Yes, your position.
 
  How this pach works??
 Patch is originaly written by Seppo Ingalsuo 
 (http://www.linuxtv.org/pipermail/vdr/2008-March/016164.html).
 
 The patch uses algo from vdr-rotor patch to calculate angle
 to which motor 
 should move and send then the gotox diseqc command [e0 31
 6e p1 p2] where p1 
 and p2 is calculated angle. If you have dish with closer
 beam be sure to have 
 position of satellites in sources.conf and channels.conf
 written in right way 
 (for example satellites at 1.0W are at 0.83W and 0.75W
 exactly) to be able to 
 receive also weaker transponders.
 
 The patch send this command only when satellite is
 changing. You should also 
 use it for motor behind diseqc switch. The next example is
 for 4-input diseqc 
 switch which has diseqc motor connected to input 4. Please
 be sure that in 
 such way your dvb card will not be overloaded with output
 current (you should 
 use motor which disconnect LNB when moving and card with
 electronically 
 limited output current to prevent damages).
 
 S0.8W     11700 V  9750  t v
 W15 [E0 10 38 FC] W150 G v t
 S0.8W     9 V 10600  t v W15
 [E0 10 38 FD] W150 G v T
 S0.8W     11700 H  9750  t V
 W15 [E0 10 38 FE] W150 G V t
 S0.8W     9 H 10600  t V W15
 [E0 10 38 FF] W150 G V T
 
 BR,
 
 Ales
 
 


  

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


Re: [vdr] need help with GOTOX patch.

2009-06-09 Thread Goga777
 The patch send this command only when satellite is changing. 

is it possible to have a look in vdr logs on that disecs commands ?

You should also use it for motor behind diseqc switch. The next example is for 
4-input diseqc 
 switch which has diseqc motor connected to input 4.

did LNB connect to the output of motor ? 

 Please be sure that in 
 such way your dvb card will not be overloaded with output current (you should 
 use motor which disconnect LNB when moving

hmm. I didn't know about that feature of motors. Which motors do you mean ?


-- 
Удачи,
Игорь

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


Re: [vdr] need help with GOTOX patch.

2009-06-09 Thread Ales Jurik
On Tuesday 09 of June 2009, Goga777 wrote:
  The patch send this command only when satellite is changing.

 is it possible to have a look in vdr logs on that disecs commands ?

 You should also use it for motor behind diseqc switch. The next example is
  for 4-input diseqc switch which has diseqc motor connected to input 4.

 did LNB connect to the output of motor ?
Yes. I'm using this configuration for nearly 3 years without problem.

  Please be sure that in
  such way your dvb card will not be overloaded with output current (you
  should use motor which disconnect LNB when moving

 hmm. I didn't know about that feature of motors. Which motors do you mean ?
Nothing special, it was only my idea ;) . But if the consumption of moving 
motor is under 200mA with starting current under 400mA it could be sufficient.


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


Re: [vdr] need help with GOTOX patch.

2009-06-09 Thread Ales Jurik
On Tuesday 09 of June 2009, lucian orasanu wrote:
 I did that, i took my position with an gps, putet ther in lnb config, and
 afther that changing channels.conf form diferent satelites, but i did
 something wrong because i did not manage to get signal, until i setup my
 antena manualy again (form left right switches of motor).

  My idea was to use this patch and stored position from my motor!!

This is not how this patch is working. But if your motor is moving when using 
this patch and you didn't get the signal your motor could be badly oriented to 
the south.

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


[vdr] vdr-xine-0.9.2 - ERROR: cOsd::SetAreas returned 5

2009-06-09 Thread Goga777
Hi

how can I fix my problem with ERROR: cOsd::SetAreas returned 5

Jun  9 21:25:26 arvdr vdr: [12294] VDR version 1.7.7 started
Jun  9 21:25:26 arvdr vdr: [12294] codeset is 'UTF-8' - known
Jun  9 21:25:26 arvdr vdr: [12294] found 23 locales in ./locale
Jun  9 21:25:26 arvdr vdr: [12294] loading plugin: 
./PLUGINS/lib/libvdr-xine.so.1.7.7
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/setup.conf
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/sources.conf
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/diseqc.conf
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/channels.conf
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/timers.conf
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/svdrphosts.conf
Jun  9 21:25:26 arvdr vdr: [12295] video directory scanner thread started 
(pid=12294, tid=12295)
Jun  9 21:25:26 arvdr vdr: [12295] video directory scanner thread ended 
(pid=12294, tid=12295)
Jun  9 21:25:26 arvdr vdr: [12296] video directory scanner thread started 
(pid=12294, tid=12296)
Jun  9 21:25:26 arvdr vdr: [12296] video directory scanner thread ended 
(pid=12294, tid=12296)
Jun  9 21:25:26 arvdr vdr: [12294] reading EPG data from /video/epg.data
Jun  9 21:25:26 arvdr vdr: [12294] probing /dev/dvb/adapter0/frontend0
Jun  9 21:25:26 arvdr vdr: [12294] device 1 provides DVB-S2 (Conexant 
CX24116/CX24118)
Jun  9 21:25:26 arvdr vdr: [12298] tuner on device 1 thread started (pid=12294, 
tid=12298)
Jun  9 21:25:26 arvdr vdr: [12299] section handler thread started (pid=12294, 
tid=12299)
Jun  9 21:25:26 arvdr vdr: [12294] found 1 video device
Jun  9 21:25:26 arvdr vdr: [12294] initializing plugin: xine (0.9.2): Software 
based playback using xine
Jun  9 21:25:26 arvdr vdr: [12300] XineRemote control thread started 
(pid=12294, tid=12300)
Jun  9 21:25:26 arvdr vdr: [12300] Entering cXineRemote thread
Jun  9 21:25:26 arvdr vdr: [12294] setting primary device to 2
Jun  9 21:25:26 arvdr vdr: [12294] assuming manual start of VDR
Jun  9 21:25:26 arvdr vdr: [12294] SVDRP listening on port 2001
Jun  9 21:25:26 arvdr vdr: [12294] setting current skin to sttng
Jun  9 21:25:26 arvdr vdr: [12294] loading /video/themes/sttng-default.theme
Jun  9 21:25:26 arvdr vdr: [12294] starting plugin: xine
Jun  9 21:25:28 arvdr vdr: [12303] KBD remote control thread started 
(pid=12294, tid=12303)
Jun  9 21:25:28 arvdr vdr: [12294] ERROR: remote control XineRemote not ready!
Jun  9 21:25:28 arvdr vdr: [12294] remote control KBD - learning keys
Jun  9 21:25:28 arvdr vdr: [12294] ERROR: cOsd::SetAreas returned 5
Jun  9 21:25:38 arvdr vdr: [12294] switching to channel 3
Jun  9 21:25:39 arvdr vdr: [12311] receiver on device 1 thread started 
(pid=12294, tid=12311)
Jun  9 21:25:39 arvdr vdr: [12312] TS buffer on device 1 thread started 
(pid=12294, tid=12312)
Jun  9 21:25:39 arvdr vdr: [12294] OSD size changed to 720x576 @ 4:3
Jun  9 21:25:39 arvdr vdr: [12294] vdr-xine: new OSD(0, -108) requested with 
coordinates out of range
Jun  9 21:25:39 arvdr vdr: [12294] ERROR: cOsd::SetAreas returned 5
Jun  9 21:25:48 arvdr vdr: [12298] frontend 0 timed out while tuning to channel 
3, tp 110744

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


Re: [vdr] vdr-xine-0.9.2 - ERROR: cOsd::SetAreas returned 5

2009-06-09 Thread Reinhard Nissl
Hi,

Goga777 schrieb:

 how can I fix my problem with ERROR: cOsd::SetAreas returned 5

This number matches the enum value oeWrongAlignment. In VDR's
code excerpt you can see the condition for this error:

  if (Areas[i].x1  Areas[i].x2 || Areas[i].y1  Areas[i].y2 ||
Areas[i].x1  0 || Areas[i].y1  0)
 return oeWrongAlignment;

 Jun  9 21:25:39 arvdr vdr: [12294] vdr-xine: new OSD(0, -108) requested with 
 coordinates out of range
 Jun  9 21:25:39 arvdr vdr: [12294] ERROR: cOsd::SetAreas returned 5

I've no idea why a vanilla VDR-1.7.7 should produce such an
incorrect OSD setup.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de

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


Re: [vdr] Any really working HD video output systems for VDR?

2009-06-09 Thread Georg Acher
On Tue, Jun 09, 2009 at 11:44:29AM +0200, Mattia Rossi wrote:
 
 Hi Georg,
 sorry if that came out as 'they are hiding something', I was really
 thinking more in terms of 'there are so many variables that the best
 combination is probably achieved in an environment where the user has
 much less control as we have in a custom vdr compiled environment,
 without even taking into account the endless combinations of display
 devices that people will want to connect to the eHd'
 
 That said, I really really would like a different option than 'don't use
 the scaler on the eHd-HDMI output, it's crap', is there a way to change
 the scaling algorithm it uses ?
 
 Is there any other setting we can work on regarding the eHd outputs,
 even if they are not listed in the reelbox-3 setup ?

Not really. You can either use upscaling without deinterlacing (and get
tearing for real interlaced moving signals) or use the chips deinterlacer.
That is effectively independent scaling of both fields, so the field order
is correct, but fine details show horizontal ghost lines as the
interpolation doesn't know anything about the full context. It depends a bit
on the display how visible these lines can be seen, some displays seem to
have their own filtering and hide them better.

There is a third possibility that is currently not settable: Blending. That
mixes both fields together. So still pictures are sharp and movements are
only blurred and not teared. I can enable it in a experimental
linux.bin.

BTW: We chose the DeCypher despite a real deinterlacer was missing at the
time, because we were told that it will be enabled later. The rest is
history...
 
 For example, I am using the coax digital output on the eHd mini-din,
 instead of the pass through HDMI (the HDMI cable goes straight to the
 VPR, the coax cable goes to my main amp), I had to change a couple of
 lines in the reelbox-3 plugin in order to allow for AC3 to pass through
 the digital output. The option was there, it just wasn't compiled in
 because of REELBOXLITE ifdefs

That was because the MiniPCI-Card for the Lite used a DeCypher-revision with
a dead SPDIF-port. So we need to feed the AC3 SPDIF output over the main
sound card. The AVG-card has a working SPDIF, so the mainboard sound is used
only for PCM (if enabled).
 
 What I would like to achieve is decent quality (either scaled or
 unscaled) SD MPEG-2 output, and by decent I mean at least at the same
 quality of the MPEG-2 output of a FF card without having to use a 2Keuro
 deinterlacer. Please note that I'm talking about MPEG processing
 quality, not still image quality 

You can output 576i over HDMI and let the display do the deinterlacing. But
there is a dependency with the analog output that allows only 576p when the
analog port should emit 576i (CVBS etc.). For 576i over HDMI you need to
switch the analog port completely off.

 I understand that this is not easy to fine tune because of all the
 different variables and because of all the 'not straightforward' test
 environments every single vdr user will have set up.
 
 At the moment my vdr 1.7.x install is really basic (vdr, extensions
 patch, reelbox3 filebrowser xinemediaplayer and menuorg plugins) and I
 am completely satisfied by the stability (both of vdr and of the eHd) ,
 I even don't notice the problems with the recordings handling (the
 single frame forward in a recording isn't really working, it looks like
 it is skipping from i-frame to i-frame (doesnt'do that when going
 backwards, it is the opposite behaviour as with the ff card, where
 forward skipping works, while backward skipping goes from i_frame to
 i-frame ..)

I guess the vdr 1.7 has it's own intelligence about frame-precise playback
for TS that doesn't match the requirements of the plugin... It took us quite
a while to make it work almost as responsive as on the FF, maybe there are
some dependencies with our old 1.4. But up to now, I had no time to try
1.7...

-- 
 Georg Acher, ac...@in.tum.de 
 http://www.lrr.in.tum.de/~acher
 Oh no, not again ! The bowl of petunias  

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


[vdr] Wrong OSD values in setup.conf (was: Re: vdr-xine-0.9.2 - ERROR: cOsd::SetAreas returned 5)

2009-06-09 Thread Andreas Mair
Hi,

check your setup.conf. Mine has invalid sizes:
FontFix = Courier:Bold
FontFixSize = 0
FontFixSizeP = 0,00
FontOsd = VDRSymbols Sans:Bold
FontOsdSize = 0
FontOsdSizeP = 0,00
FontSml = VDRSymbols Sans:Book
FontSmlSize = 0
FontSmlSizeP = 0,00
OSDHeight = 0
OSDHeightP = 0,00
OSDLanguage = de_DE
OSDLeft = 0
OSDLeftP = 0,00
OSDTop = 0
OSDTopP = 0,00
OSDWidth = 0
OSDWidthP = 0,00

As you can see they are are all 0. I don't know how that could
happen, but I already had that on two VDR instances. Both upgraded
from VDR 1.6.0.
After setting them once in VDR 1.7 they are fine.

What skin do you use?
My own EnigmaNG skin (CVS release) takes care of invalid values ;)

Regards,
Andreas

2009/6/9 Reinhard Nissl rni...@gmx.de:
 Hi,

 Goga777 schrieb:

 how can I fix my problem with ERROR: cOsd::SetAreas returned 5

 This number matches the enum value oeWrongAlignment. In VDR's
 code excerpt you can see the condition for this error:

  if (Areas[i].x1  Areas[i].x2 || Areas[i].y1  Areas[i].y2 ||
 Areas[i].x1  0 || Areas[i].y1  0)
     return oeWrongAlignment;

 Jun  9 21:25:39 arvdr vdr: [12294] vdr-xine: new OSD(0, -108) requested with 
 coordinates out of range
 Jun  9 21:25:39 arvdr vdr: [12294] ERROR: cOsd::SetAreas returned 5

 I've no idea why a vanilla VDR-1.7.7 should produce such an
 incorrect OSD setup.

 Bye.
 --
 Dipl.-Inform. (FH) Reinhard Nissl
 mailto:rni...@gmx.de

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




-- 
http://andreas.vdr-developer.org --- VDRAdmin-AM  EnigmaNG  VDRSymbols
VDR user #303

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