Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not declared in this scope

[fnu]

Martin,

just in case you missed it, that is obviously an issue of 
vdr-plugin-dvbhddevice and not core VDR, maintained by Klaus ...

Cheers
Frank

-Ursprüngliche Nachricht-
Von: vdr  Im Auftrag von Martin Gansser
Gesendet: Dienstag, 9. Oktober 2018 10:27
An: vdr@linuxtv.org
Betreff: Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not 
declared in this scope

Hello Klaus,

will you provide a kernel> = 4.8 patch or will I need to contact the kernel 
developer for this?

Martin

Gesendet: Sonntag, 30. September 2018 um 11:36 Uhr
Von: "Klaus Schmidinger" 
An: vdr@linuxtv.org
Betreff: Re: [vdr] dvbhdffdevice.c:569:33: error: 'AUDIO_GET_PTS' was not 
declared in this scope On 9/28/18 8:05 PM, Jasmin J. wrote:
> Hi!
>
> This is obsolete since Kernel 4.8:
> https://www.kernel.org/doc/html/v4.8/media/uapi/dvb/audio-get-pts.html
> So VDR would already have needed to be changed quite some time ago.
> I guess it is time to do it now.

BTW: I always thought that Linux kernel policy is not to allow userspace 
applications to break. Apparently this is no longer the case :-(.

Klaus

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

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


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

Re: [vdr] Translation question en -> fr

[fnu]

Hi Bernard,

 

Klaus does translate this into german word "alles", "tout" in french.

 

Cheers

Frank

 

Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Bernard Jaulin
Gesendet: Sonntag, 2. Juli 2017 12:15
An: VDR Mailing List 
Betreff: [vdr] Translation question en -> fr

 

Hello,

 

For a better translation, did someone can explain to me what is this msgid and 
the context.

 

> msgid "full"

 

Regards,

 

BJA.

 

 

 

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

Re: [vdr] VDR 2.3.2 and Plugins

[fnu]

Hi there,

all of Rolf Ahrenbergs Plugins should run flawless with VDR 2.3.2:

- satip
- iptv
- skinsoppalusikka
- femon

Use master branch of each plugin on rofafor's github repository.

If anyone is interessted in Debian/Ubuntu VDR 2.3.2 packages, may give them a 
try:

- https://launchpad.net/~fnu/+archive/ubuntu/unstable-vdr-fnu/+packages

I'm going to fill it with plugins slowly. Packages are built for system.d and 
vdr.conf loader.

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Richard Scobie
Gesendet: Donnerstag, 5. Januar 2017 21:17
An: Klaus Schmidinger's VDR <vdr@linuxtv.org>
Betreff: [vdr] VDR 2.3.2 and Plugins

Just wanted to draw attention to this thread at vdrportal for anyone who is 
discouraged from trying the 2.3.x vdr due to plugins not working.

<http://www.vdr-portal.de/board17-developer/board97-vdr-core/130045-produktive-problem-und-pluginl%C3%B6sungen-f%C3%BCr-vdr-2-3-2-und-h%C3%B6her>

Or, for English only speakers:

<https://translate.googleusercontent.com/translate_c?depth=1=en=translate.google.com=de=en=http://www.vdr-portal.de/board17-developer/board97-vdr-core/130045-produktive-problem-und-pluginl%25C3%25B6sungen-f%25C3%25BCr-vdr-2-3-2-und-h%25C3%25B6her/%3Fs%3D6cf8f53d317a8e7e627d38a7d7674e400fcad608=ALkJrhjGdT3TSomAcn2oslhn2UWfi8ZN7A>

Klaus has very generously jumped in and updated some and more are sure to 
follow.

Anyone wanting extra skin capabilities, I have found SkinFlatPlus to work well.

https://projects.vdr-developer.org/projects/plg-skinflatplus

Have been running vdr 2.3.2 + dvdhddevice, femon, dvd, dvdswitch, 
streamdev-server and skinflatplus without problems for a couple of weeks now.

Regards,

Richard

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


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

> Out of curiosity, whats the ballpark average bitrate of your non-sports 1080p 
> content?

Following the European Broadcasting Union (EBU) guidelines there's no 1080p 
broadcast in Europe and will most propably not happen. The HD formats in Europe 
are 1280x720p50, 1440x1080i25 and 1920x1080i25. The majority of the european 
public service broadcasting institutions are using 720p50. The privat 
broadcasting stations are using one of the 1080i25 formats, a majority 
1920x1080i25. Bitrate on the 720p50 channels is up to 16Mbit/s but rarely below 
10Mbit/s. The range for the private 1080i25 channels is much wider, from real 
bad 8Mbit/s up to 20Mbit/s on some sports channels.

Thanks to Nvidias VDPAU capabilities there's no difference watching 720p or 
1080i, even 576i looks like HD.

=> https://tech.ebu.ch/docs/techreports/tr005.pdf

Stations & industries are working on 4k broadcasting, means 3840 × 2160i/p.

fnu


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

Derek,

you're right it's maybe possible to stack channels somewhat, but not on the 
user end of the "one cable". It must be "stacked" on the other end of the "one 
cable" and splitted again on the user side of that cable. And here's the 
problem, there are VDR users out there they cannot change the hardware on the 
other end, either not allowed or technically not possible. See my other message 
for the varied reasons ...

As Andreas said we need to deal here with 4 sync levels on the European Astra 
satellites, to cover every all channels, horizontal-high, horizontal-low, 
vertical-high, vertical-low. So, any multiswitch does need 4 input cables from 
LNB, one for each level, to deliver every channel. The Multiswitch can then be 
a model working along CENELEC EN50494/EN50607, SCR/CSS, what does deliver 
multiple user bands over one cable and than splitted on user side.

fnu


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

> Are you saying people are not allowed to put a switch at the point where the 
> cable plugins into their dvb device? It would be no different that putting an 
> ethernet switch on your ethernet line. You don't need to alter anything aside 
> of instead of the cable going into your dvb card, it goes into your switch. 
> 100% internal, 100% your own hardware.

Derek,

your simple idea sounds fantastic, I really would like to recommend that to all 
these users. Well, we all would have done that already, be sure ... ;-)

Unfortunately the reality is little bit more difficult, one COAX cable is not 
enough to cover all needs for receiving satellite signal. It's enough to power 
one DVB card (or two in case of device bonding), if there's proper 
infrastructure on the other end of the cable, delivering all needs for SAT 
receiption.

Unlike terrestric or cable signals, you cannot just split one COAX cable for 
satellite signals. Each DVB-S/S2 card does need to control individualy its 
parameters to receive a specific transponder/channel. So it's possible to mount 
a splitter, but VDR must be able to control that. VDR can do exactly that with 
device bonding aka LNB sharing ...

fnu


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

Derek,

pretty simple, there are users who cannot change their SAT infrastructure 
easily. The reasons are varied, e.g. they are tenants and not allowed to change 
it by the owners, they own it and cannot change it due to the rules of 
commonhold association or the own it and the construction of apartment/house 
doesn't allow changes etc.

Unlike USA, Canada, not many people own houses in Europe or are living in 
houses with that flexibility.

You're right, to have one cable for each DVB adapter is nice to have, but is 
sometimes not doable. The individuals who can do, will run decent SAT 
infrastructure, for sure.

fnu


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

Derek,

they do in vdr-portal.de ... as I already do remember a bunch of users still 
using that function and the reasons why, so no what-if-scenarios.

fnu


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

> So I take it you yourself are *not* using this feature, right?

Not active anymore, but in the past for many years, just up to a couple of 
years ago for my development machine.

Getting rid of that feature may also causing the comeback of any sort of patch, 
maybe causing other issue, nobody can control ...

As I said just my 2 cents.

Cheers
Frank


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

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[fnu]

Hi Klaus,

well, you're right it's a hack, but IMHO not really an ugly one. A similar 
function is up today part of some premium products from Loewe or Metz, bonding 
two DVB-S/S2 tuners.

Originally it was limited to two devices, what really can make sense. I have 
never seen any reason to make that bonding available almost unlimited. For me 
it doesn't make sense to tie more than two adapters onto same ZF level. And 
you're right, today seems with SCR (EN50494 & EN50607) or SAT>IP more elegant 
solutions available.

But, it would be cool to keep it for that specific two DVB-S/S2 tuner setup, if 
possible. There might be people out there, having just one SAT cable in their 
apartment and not the possibility to change the that. They would keep their 
chance to run "1,5 DVB-S/S2" adapters with VDR ...

Just my two cents.

Happy new year 2017 to all VDR fans following that Mailingslist.

Cheers
Frank

-Ursprüngliche Nachricht-
Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Klaus Schmidinger
Gesendet: Sonntag, 1. Januar 2017 13:29
An: VDR Mailing List 
Betreff: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB 
sharing)?

Implementing "device bonding" (formerly known as "LNB sharing") has had quite 
an impact on VDR's dvbdevice.c, and made the code quite a bit more complex. 
Since this feature is really just an ugly hack, and it makes much more sense to 
provide each device with its own antenna cable, rather that connecting two or 
more devices to the same cable and having to limit them to the same 
polarization and frequency band, I'd very much like to remove that code from 
VDR's source.

I would therefore like to know if there are any users who actually use this, 
and *really* need it.

Klaus

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


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

Re: [vdr] Sat>IP-plugin: how to configure 2 DD Octopus NETs with different satellites

[fnu]

Hi,

I remember that Rolf always does suggest to use "OctopusNet" or "minisatip"
as device name.

So your definition is recommended to look like this:

--server=192.168.1.21|DVBS2-4|OctopusNet1;192.168.1.20|DVBS2-2,DVBT2-2|Octop
usNet2

The other stuff, hmm, I don't know, as the plugin follows quite straight the
SAT>IP specifications. Your add-on is maybe the point to discuss with the
original author Rolf.

Regards
fnu

-Ursprüngliche Nachricht-
Von: Patrick Boettcher [mailto:patrick.boettc...@posteo.de] 
Gesendet: Montag, 18. Juli 2016 17:43
An: fnu <v...@auktion.hostingkunde.de>
Cc: 'VDR Mailing List' <vdr@linuxtv.org>
Betreff: Re: [vdr] Sat>IP-plugin: how to configure 2 DD Octopus NETs with
different satellites

Hi fnu,

Thank you for your answer.

On Mon, 18 Jul 2016 10:29:58 +0200
"fnu" <v...@auktion.hostingkunde.de> wrote:

> Dear Patrick,
> 
> changes in "sources.conf" are IIRC only necessary if you have a DiSEqC 
> configuration controlled by VDR. But using a/the generic sources.conf 
> doesn't harm VDR operation, I guess most users do have one without 
> DiSEqC.

That seems to be true. Before looking at the code of the satip-plugin I
thought that I could limit magically the created (virtual) satipDevices to
the Sources assigned to them via the diseqc.conf.

> You may use a workaround by using CAID field for specific adapter:
> 
> https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#CA_-
> _Conditional_access

Yeah, no, I don't like this.
 
> But I do not now if it is possible to cover more than 4 devices and no 
> good idea how to tie a SAT>IP device always to the same number.

As said above, I dug into the code and saw that nothing can be done with
standard vdr-config-files. Neither diseqc.conf nor sources.conf can help.

However, I added some code and now it works as I wanted it to work.

I did this by adding a Source-member to the satipFrontend created by
satipServer and in satipFrontend::Assign() I additionally check whether the
requested source can be delivered by this frontend.

In my environment, where I have one VDR which will use all satip-devices,
this is exactly what I need.

Now, how to get that correctly done?

Automatic detection? I haven't seen any option on the Octopus-device that
would help the satip-plugin to identify automatically the source/input when
it does the discovery.

So, I'd opt for the command-line-parameter-option: I'd add an additional
parameter to the plugin which will assign the correct source to the
satipFrontend. Which would only work if the -s-option is given.
Maybe it could be even part of the -s-option.. Let's try:

  --server=192.168.1.21|DVBS2-4|Octo1;192.168.1.20|DVBS2-2,DVBT2-2|Octo2

becomes

  --server=192.168.1.21|DVBS2-4|Octo1|S19.2E,S19.2E,S19.2E,S19.2E; \
192.168.1.20|DVBS2-2,DVBT2-2|Octo2|S28.2E,S28.2E,T,T

Looks good to me. I'll try that. 

This will surely work, however, right now, the satip-plugin does not use the
fe=-parameter the RTSP-URL for that. So even with this syntax, it won't be
possible to mix different satellites on _one_ Octopus NET.

Like '[..]Octo2|S28.2E,S19.2E,S28.2E,S19.2E' wouldn't work without changing
the URL-creation-method. It even looked like that the URL is created before
the satipFrontend is chosen. That would have to be changed.

best regards,
--
Patrick Boettcher


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

Re: [vdr] SatIP>plugin: how to configure 2 DD Octopus NETs with different satellites

[fnu]

Dear Patrick,

changes in "sources.conf" are IIRC only necessary if you have a DiSEqC 
configuration controlled by VDR. But using a/the generic sources.conf doesn't 
harm VDR operation, I guess most users do have one without DiSEqC. And well, 
"diseqc.conf" does IMHO explain by itself it's function.

With SAT>IP you don't use DiSEqC and it is from my understanding not foreseen 
to distinguish within the SAT>IP clients configuration between different 
orbital positions. SAT>IP specs do cover several positions but managed by the 
SAT>IP server. In your case one Octopus Net mainboard holding all of your flex 
modules and VDR is asking for the different positions by using the different 
channel.conf entries.

You may use a workaround by using CAID field for specific adapter:

https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#CA_-_Conditional_access

But I do not now if it is possible to cover more than 4 devices and no good 
idea how to tie a SAT>IP device always to the same number.

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr [mailto:vdr-boun...@linuxtv.org] Im Auftrag von Patrick Boettcher
Gesendet: Sonntag, 17. Juli 2016 15:36
An: VDR Mailing List <vdr@linuxtv.org>
Betreff: [vdr] SatIP>plugin: how to configure 2 DD Octopus NETs with different 
satellites

Hi,

I have 2 DD Octopus NET devices. One is a 2x DVB-S(2) + 2x DVB-T(2) (let's call 
it AA) and the other one is 4x DVB-S(2) (BB).

AA's satellite orientation is Astra 28.2, BB's one is Astra 19.2.

How can I associate AA's or BB's inputs in VDR's configuration so that it uses 

  1) the right input for the right source

  2) the maximum number of devices in parallel for recording,
 epg-scanning etc.

conf.d/50-satip.conf contains 

  --devices=8
  --server=192.168.1.21|DVBS2-4|Octo1;192.168.1.20|DVBS2-2,DVBT2-2|Octo2


I found discussions where they say that in sources.conf one needs to assigned 
device numbers, so I tried:

  S19.2E 1 Astra 1KR/1L/1M/2C
  S19.2E 2 Astra 1KR/1L/1M/2C
  S19.2E 3 Astra 1KR/1L/1M/2C
  S19.2E 4 Astra 1KR/1L/1M/2C
  S28.2E 5 Astra 1N/2A/2F
  S28.2E 6 Astra 1N/2A/2F

This isn't working, it seems that even for S28.2 channels it selects the 
S19.2-devices.

Then I changed the diseqc.conf to

  1 2 3 4:
  S19.2E  11700 V  9750  t v W15 [E0 10 38 F0] W15 A W15 t
  S19.2E  9 V 10600  t v W15 [E0 10 38 F1] W15 A W15 T
  S19.2E  11700 H  9750  t V W15 [E0 10 38 F2] W15 A W15 t
  S19.2E  9 H 10600  t V W15 [E0 10 38 F3] W15 A W15 T

  5 6:
  S28.2E  11700 V  9750  t v W15 [E0 10 38 F4] W15 B W15 t
  S28.2E  9 V 10600  t v W15 [E0 10 38 F5] W15 B W15 T
  S28.2E  11700 H  9750  t V W15 [E0 10 38 F6] W15 B W15 t
  S28.2E  9 H 10600  t V W15 [E0 10 38 F7] W15 B W15 T

Didn't help.

Is there anything I can do? 

Thanks in advance for any help.

Best regards,
--
Patrick.

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


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

Re: [vdr] DVB-T2 device in France

[fnu]

Nicolas,

ok, two points just for my couriousity.

1. Why don't you share channels.conf from your server as you do it with EPG 
data?
2. Why don't you enable EPG scan just for a few hours for the channels scan and 
delete epg.data afterwards again?

By chance I tested the same a couple of days ago on my Octopus (DVBS-8) and it 
took just 20min to fill the channels.conf with ~1300 channels from Astra 19.2°E 
...

Regards
Frank

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von 
Nicolas Huillard
Gesendet: Montag, 28. September 2015 16:40
An: VDR Mailing List <vdr@linuxtv.org>
Betreff: Re: [vdr] DVB-T2 device in France

Le lundi 28 septembre 2015 à 12:55 +0200, fnu a écrit :
> per specs channel scan is not inteded for the SAT>IP servers, this is 
> client's responsibility.

I fully understand this point, but since the Octopus has a web interface and 
apparently also acts as a DLNA DMS, I think it could be a nice addition to have 
at least basic channel scanning, just to provide a smoother starting with the 
device (which is neally neat in every other aspects).

> VDR doesn't provide an active channel scan option, so don't blame and 
> point just the plugin, which does run awesome stable here since spring 
> 2014.

I don't "blame" anything, and I trust that plugin to work flawlessly. I still 
have power supply issues on the Raspberry Pi which masks all that stability ;-) 
As of now, this is a task for the soldering iron.

> VDR does provide a passive channel scan, only caveat you need at least 
> one working line in channels.conf. If you have that, go to OSD / Setup 
> / DVB and set "Update channels:" to "add new transponders" (setup.conf 
> / UpdateChannels = 5). After some time of patience you should find a 
> properly filled channels.conf, ready to be sorted.

That's what I tried, with the channel.conf I have from the VDR server, but it 
didn't catch newer channels, even though "some time" was a day or two.
I suspect this is something related to MANUAL.gz stating "Note that adding new 
transponders only works if the "EPG scan" is active.", and the fact that EPG is 
currently meant to be shared from the VDR server, and apparently not working... 
Even UpdateChannels = 4 didn't add anything.

I'll deal with this and bother the ML if I can't manage it ;-)

> Cheers
> Frank
> 
> -Ursprüngliche Nachricht-
> Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im 
> Auftrag von Nicolas Huillard
> Gesendet: Montag, 28. September 2015 12:18
> An: VDR Mailing List <vdr@linuxtv.org>
> Betreff: Re: [vdr] DVB-T2 device in France
> 
> Thanks for all your answers !
> 
> I finally opted for the Digital Devices Octopus Net, which DVT-T2 tuners are 
> equipped with Sony D2837ER demodulators, which happen to completely solve the 
> bad reception issue. Great !
> 
> Now I have a whole new set of problems : SAT>IP (with the satip plugin which 
> seems to be great, and channel scan which is as of now non-solved ; too bad 
> the Octopus couldn't channel-scan by itself and provide an initial 
> channel.conf or VLC playlist) and Raspberry Pi client which is a bit tricky 
> (power issues, media player, disappointingly weak CEC support on the TV side, 
> etc...).
> 
> At least, I can upgrade the VDR server without breaking the DVB kernel 
> drivers, and upgrade the VDR client without breaking X.org or xinelib 
> ;-)
> 
> Le lundi 21 septembre 2015 à 15:37 +0100, Stuart Morris a écrit : 
> > I have a 290e I use for DVB-T2 reception and it has worked really 
> > well for some time now.
> > Shame you can't buy them anymore :-(
> > 
> > On 19 September 2015 at 10:21, Jari Fredriksson <ja...@iki.fi> wrote:
> > 
> > > On 17.9.2015 15:01, Nicolas Huillard wrote:
> > >
> > >> Hello all,
> > >>
> > >> My previous mail to this ML is apparently dated 2011 ;-) 
> > >> Everything was OK there since then... Except that my Hauppauge 
> > >> Nova-T-500 died recently, and my ancient PCI cards do not work in the 
> > >> 2013 server.
> > >>
> > >> I'm looking for advice for a new DVB-T2 device, which should :
> > >> * have a good tuner, because some channels (transponders, ie.
> > >> frequencies) are difficult to catch here ; the TV set (Panasonic) 
> > >> works perfectly well, and I've added an RF amplifier on the roof, 
> > >> so I guess the Nova-T-500 tuner was not good enough
> > >> * have a PCI or preferably PCI-e bus, and dual tuner (I don't 
> > >> really like USB sticks, which tend to lead to a mess of cable)
> > >> * be robustly supported w

Re: [vdr] DVB-T2 device in France

[fnu]

Hi Nicolas,

per specs channel scan is not inteded for the SAT>IP servers, this is client's 
responsibility.

VDR doesn't provide an active channel scan option, so don't blame and point 
just the plugin, which does run awesome stable here since spring 2014.

VDR does provide a passive channel scan, only caveat you need at least one 
working line in channels.conf. If you have that, go to OSD / Setup / DVB and 
set "Update channels:" to "add new transponders" (setup.conf / UpdateChannels = 
5). After some time of patience you should find a properly filled 
channels.conf, ready to be sorted.

Cheers
Frank

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von 
Nicolas Huillard
Gesendet: Montag, 28. September 2015 12:18
An: VDR Mailing List 
Betreff: Re: [vdr] DVB-T2 device in France

Thanks for all your answers !

I finally opted for the Digital Devices Octopus Net, which DVT-T2 tuners are 
equipped with Sony D2837ER demodulators, which happen to completely solve the 
bad reception issue. Great !

Now I have a whole new set of problems : SAT>IP (with the satip plugin which 
seems to be great, and channel scan which is as of now non-solved ; too bad the 
Octopus couldn't channel-scan by itself and provide an initial channel.conf or 
VLC playlist) and Raspberry Pi client which is a bit tricky (power issues, 
media player, disappointingly weak CEC support on the TV side, etc...).

At least, I can upgrade the VDR server without breaking the DVB kernel drivers, 
and upgrade the VDR client without breaking X.org or xinelib ;-)

Le lundi 21 septembre 2015 à 15:37 +0100, Stuart Morris a écrit : 
> I have a 290e I use for DVB-T2 reception and it has worked really well 
> for some time now.
> Shame you can't buy them anymore :-(
> 
> On 19 September 2015 at 10:21, Jari Fredriksson  wrote:
> 
> > On 17.9.2015 15:01, Nicolas Huillard wrote:
> >
> >> Hello all,
> >>
> >> My previous mail to this ML is apparently dated 2011 ;-) Everything 
> >> was OK there since then... Except that my Hauppauge Nova-T-500 died 
> >> recently, and my ancient PCI cards do not work in the 2013 server.
> >>
> >> I'm looking for advice for a new DVB-T2 device, which should :
> >> * have a good tuner, because some channels (transponders, ie.
> >> frequencies) are difficult to catch here ; the TV set (Panasonic) 
> >> works perfectly well, and I've added an RF amplifier on the roof, 
> >> so I guess the Nova-T-500 tuner was not good enough
> >> * have a PCI or preferably PCI-e bus, and dual tuner (I don't 
> >> really like USB sticks, which tend to lead to a mess of cable)
> >> * be robustly supported with stock kernels in Debian (jessie and 
> >> future), which does not seem to be a problem anymore...
> >>
> >> If there are some dual-tuner, DVB-T2 + S2 card out there which are 
> >> well supported by VDR, that's OK too. I may prefer to add another 
> >> DVB-S2 card later on though (there is no sat-dish on the roof yet).
> >>
> >> TIA !
> >>
> >
> >
> > I use an USB tuner "PCTV Systems nanoStick T2 290e" from Hauppauge. 
> > It has a good Sony tuner, and DVB-T2 in my setup works fine even 
> > with an desktop antenna (the broadcast mast is in visible range though).
> >
> > Driver is in kernel, and this was the first Linux tuner for DVB-T2 
> > and supported even in the older kernels. I use it in a Raspberry Pi 
> > 2 with two DVB-C tuners and I'm all happy.
> >
> >
> > --
> > jarif.bit
> >
> > ___
> > 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

--
Nicolas Huillard
nico...@huillard.net
Fixe : +33 9 52 31 06 10
Mobile : +33 6 50 27 69 08

http://www.350.org/


___
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 version 2.2.0 released - Celebrating 15 years of VDR!

[fnu]

Well done mate, congrats for 15 wonderful years, what changed TV life and
habbits of many people worldwide!

Thanks for all of your work and passion.

===
Cheers
Frank

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Klaus Schmidinger
Gesendet: Donnerstag, 19. Februar 2015 11:39
An: vdr@linuxtv.org
Betreff: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years
of VDR!

VDR version 2.2.0 is now available at

   ftp://ftp.tvdr.de/vdr/vdr-2.2.0.tar.bz2

A 'diff' against the previous developer version is available at

   ftp://ftp.tvdr.de/vdr/vdr-2.1.10-2.2.0.diff

MD5 checksums:

8853f64c0fc3d41ffd3b4bfc6f0a14b7  vdr-2.2.0.tar.bz2
2d75806f90a4f1c8b3e30d7568891dc6  vdr-2.1.10-2.2.0.diff

A summary of all the major changes since the last stable version 2.0.0 can
be found at

  http://www.tvdr.de/changelog.htm

When updating from an earlier version of VDR please make sure you read the
INSTALL and MANUAL files that come with the VDR source _before_ doing so!
Please make sure you have backup copies of all your configuration files, and
verify carefully that your timers will be set to the correct channels after
switching to this new version.

Thanks to the many people who have contributed in the making, testing and
debugging of this new version of VDR, and also to all users who have been
enjoying VDR over the past 15 years!

Please also visit the VDR homepage at

  http://www.tvdr.de

and VDR's facebook page at

  https://www.facebook.com/VideoDiskRecorder

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

Re: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!

[fnu]

http://www.heise.de/newsticker/meldung/Seiner-Zeit-voraus-Klaus-Schmidingers
-Video-Disk-Recorder-VDR-2552972.html

Great!

Thank you Tobias, Mirko Doelle and Peter Siering!

===
Regards
Frank 


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

Re: [vdr] DVB-S2 PCIe or USB tuner recommendations?

[fnu]

Hi Stephan,

search for Linux4Media/DigitalDevices CineS2 cards. Either revision V5.4/5.5
which does use kernel module ngene, what is upstream since kernel version
3.0 (IIRC). You or your Linux distro just need to provide a proper firmware
file ngene_18.fw. I did run these cards rock solid over very long time in
my VDR, but you can't get them new anymore.

Alternatively you could go for revision v6.2, what does use kernel module
ddbridge, kernel upstream since version 3.2 (iirc), no firmware file
needed. I do run one of these still in my main VDR using upstream kernel
module, but also sometimes with additional packages like dddvb or
media_build_experimental. You can get these cards still new at Linux4Media
online shop.

http://www.l4m-shop.de/index.php?cat=c6_L4M-Twin-Karten-PCIexpress-L4M-Twin-
Karten-PCIexpress.html

===
Kind regards
Frank

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Stephan Loescher
Gesendet: Samstag, 7. Februar 2015 20:20
An: VDR Mailing List
Betreff: [vdr] DVB-S2 PCIe or USB tuner recommendations?

Hi!

I am planning to build a new VDR system for HDTV and DVB-S2.

So I am searching for DVB-S2 tuners either PCIe (low profile) or USB.

The best tuner would be one which is supported by the vanilla Linux kernel
without patching or installing additional drivers.
(Installing a firmware file is no problem.)

I have already searched http://www.linuxtv.org/wiki/, but there are only a
few current tuners, which are documented as works with vanilla kernel out
of the box, e.g. Pinnacle PCTV DVB-S2 Stick (461e) or TeVii S471.
(The others good working ones are not any longer available, even not as
second hand.)

So I am looking for your recommendations for current DVB-S2 PCIe/USB tuners,
which work out of the box and work stable for a 7x24 running VDR.

TIA and best regards,
Stephan.

--
loesc...@gmx.de
http://www.loescher-online.de/

___
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] Advice from native speakers needed: To bisect or to halve?

[fnu]

Hi Klaus,

yes, very good ... :)

===
Kind regards
Frank

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Klaus Schmidinger
Gesendet: Freitag, 6. Februar 2015 18:22
An: vdr@linuxtv.org
Betreff: Re: [vdr] Advice from native speakers needed: To bisect or to
halve?

Thanks for all the helpful responses.

The final verdict is:

   Initial duration for adaptive skipping (s) = 120
  Defines the number of seconds to jump from the
current replay
  position in either direction, when pressing the
'1' or '3'
  key for the first time after the Reset timeout
for adaptive
  skipping.
  The valid range is 10...600.

   Reset timeout for adaptive skipping (s) = 3
  Defines the number of seconds after which pressing
the
  '1' or '3' key falls back to the Initial duration
for adaptive
  skipping.
  The valid range is 0...10. Setting the timeout to
0 disables
  the adaptive mode and makes '1' and '3' always
skip the number
  of seconds configured as the initial duration.

   Alternate behavior for adaptive skipping = no
  When skipping in adaptive mode with the '1' and
'3' keys, the
  distance of the skip is halved with every key
press after the
  first change of direction. While this allows for
locating a
  particular position in a recording very fast, once
you make
  one step too many in the current direction you
have no chance
  of ever reaching the desired point any more. You
will have to
  wait for the timeout to occur and start adaptive
skipping anew.
  If this option is set to 'yes', the skip distance
will only be
  halved if the direction actually changes. That
way, even if
  you missed the target point, you can still back up
to it.

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] still image at end of replay

[fnu]

 This really sounds like something that should be solved in parenting and
not code.

I fully agree to that, as dad of now almost adult kids, espacially if it's
bed time ...

If these kids are so little, why do they watch TV at all w/o parental advice
and why could there be a channel underneath showing something what the
little ones shouldn't watch?

But kids are kids, doing whatever come to their minds, they can't be
controlled all times. What may be sufficient is to implement a kind of PIN
control, like on commercial receivers. A function where to set a white list
of channels which can be watched w/o PIN and the list is then valid for
recordings, too, where the source channel is also stored. But bed time is
still human responsibility ... ;-)

===
Kind regards
fnu 


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

Re: [vdr] still image at end of replay

[fnu]

 You can do that already. Use the iptv plugin, create a channel that shows
a static picture,

Smart idea, but wife is also required to go to bed all the time ... SCNR ...
;-)

===
Kind regards
fnu 


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

Re: [vdr] skipping 5/10 seconds

[fnu]

 If I officially use them for a function that is (IMHO, agreed)
unnecessary, then they would be wasted for future use for functions that
might be more important ;-).

Well these keys are unused for 14  years now and yes, they could be saved
for any usage another 14 years, ..., doing nothing ... ^^

I agree with all supporters, I like that function, and them on discrete
keys. I would also not have problems to patch it further. But it's also ok
to use other discrete keys, e.g. the proposed usage of right/left in replay
mode, just to find a global agreement for core VDR.

Maybe there's a way to make it definable for the rare cases an user doesn't
have a remote with discrete fastfwd/fastrwd keys ...

In the many years of using VDR I rarly used fastfwd/fastrew, since jumping a
few seconds is much more comfortable and therfore important to me.

===
Kind regards
fnu


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

[vdr] [Announce] vdr-plugin-satip 0.0.1 - Make your VDR to a SATIP receiver

[fnu]

Hi VDR followers,

since the author Rolf Ahrenberg obviously isn't part of this mailing list
anymore, I do the annoucement on his behalf:

This plugin integrates SATIP network devices seamlessly into VDR.
You can use any SATIP channel like any other normal DVB channel for
live viewing, recording, etc. The plugin also features full section
filtering capabilities which allow for example EIT information to be
extracted from the incoming stream.

- http://www.saunalahti.fi/~rahrenbe/vdr/satip/

Download and README.

Rolf Ahrenberg also does provide a new vdr-plugin-femon (2.0.3) to support
SATIP devices in VDR.

- http://www.saunalahti.fi/~rahrenbe/vdr/femon/

For Debian  Ubuntu aware users, I already created a DEB package/framework
for further usage:

-
https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007335/+list
ing-archive-extra
-
https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007336/+list
ing-archive-extra
-
https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007363/+list
ing-archive-extra
-
https://launchpad.net/~fnu/+archive/testing-vdr-fnu/+sourcepub/4007362/+list
ing-archive-extra

Use dget -xu ...dsc to grab it for your own usage or repository.

===
Kind regards
fnu



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

Re: [vdr] vdr-fritzbox no longer working after FBF firmware upgrade

[fnu]

Harald,

yes, newer do version work with Fritz!OS beyond 5.5x.

I'm using actually 1.5.2 with Fritz!OS 6.01.

===
Kind regards
fnu

 -Original Message-
 From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf
 Of Harald Milz
 Sent: Tuesday, January 21, 2014 11:06 AM
 To: VDR Mailing List
 Subject: [vdr] vdr-fritzbox no longer working after FBF firmware upgrade
 
 Hi all,
 
 I've been happily using vdr-fritzbox for a very long time. Since the
 last upgrade to Fritz!OS 5.50 and then to 5.53 (54.05.50 respectively
 54.05.53) the plugin cannot connect to the FBF any more. The log:
 
 Jan 21 10:10:58 seneca vdr: [2393] [libfritz++/FritzClient.cpp:210]
 logging into fritz box using old scheme without SIDs.
 Jan 21 10:10:59 seneca vdr: [2393] [libfritz++/FritzClient.cpp:228]
 login successful.
 Jan 21 10:10:59 seneca vdr: [2393] [libfritz++/FritzClient.cpp:317]
 sending callList request.
 Jan 21 10:11:01 seneca vdr: [2393] [libfritz++/FritzClient.cpp:342]
 Exception in connection to 192.168.20.253 - Could not connect Jan 21
 10:11:01 seneca vdr: [2393] [libfritz++/FritzClient.cpp:342] waiting
 3600 seconds before retrying
 
 VDR and plugin are the standard versions in Ubuntu 12.04 LTS:
 
 ii  vdr1.7.22-1
 ii  vdr-plugin-fritzbox1.4.1-4
 
 didn't have an opportunity to check out later versions yet. Should that
 be fixed by now?
 
 THX!
 
 
 --
 Do not overtax your powers.
 
 ___
 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.3

[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.

===
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 always

Re: [vdr] Change vdr shutdown command (into pm-suspend)

[fnu]

Hey Cedric,

 

looks like you are using a Debian based installation, probably with Debian 
packages based on Tobias Grimm's great work over years, and for sure his 
co-workers.

 

Obviously you're dutch and maybe capable to understand some gernan words. So,  
you may have a look into an article Tobias wrote quite a while ago on his 
homepage:

 

http://www.e-tobi.net/blog/2010/11/06/squeeze-vdr-teil-9-suspend-to-ram

 

This way does work also perfectly with Ubuntu … ;-)

 

===

Kind regards

fnu

 

From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of 
cedric.dew...@telfort.nl
Sent: Friday, December 06, 2013 6:18 PM
To: VDR Mailing List
Subject: [vdr] Change vdr shutdown command (into pm-suspend)

 

Hi All,

I'm trying to make my TV server faster by calling pm-suspend instead of 
shutdown. I have made a script that stops vdr, unloads the DVB-t driver, 
suspend, resume, load the DVB-t driver, and restart VDR. This works nicely., 
see here for details:
http://forums.debian.net/viewtopic.php?f=5 
http://forums.debian.net/viewtopic.php?f=5t=109612 t=109612

Now I'm trying to automate it.

VDR is capable of shutting down the PC. This can be setup in /etc/default/vdr

Is there any way to let VDR call pm-suspend instead of /sbin/shutdown? Where is 
the setting for it?

Best regards,
Cedric

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

Re: [vdr] Channel IDs - DVB-C and IPTV

[fnu]

Hey Michael,

glad to here that you got it work. So after using correct SID, NID and TID,
still no EPG from EIT?

Since you may not be the only user in Austria, using A1TV's IPTV channels,
you may post the proven channel.conf entries with correct SID, NID and TID
at vdr-portal.de.

===
Kind regards
fnu

 -Original Message-
 From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf
 Of Michael Frank
 Sent: Tuesday, August 20, 2013 12:03 PM
 To: VDR Mailing List
 Subject: Re: [vdr] Channel IDs - DVB-C and IPTV
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 @fnu
 
 Thank you Frank for your kind help. Analyzing the streams was the first
 step towards success.
 
 Finally I found the reason why RID would not work with my IPTV-Channels.
 It's very simple: apparently SVDRP does not like an NID of zero. As soon
 as you set it to 1 the RID can be used as well.
 
 The import of EPG-data from epgdata.com is now working fine for my IPTV-
 Channels from a1tv.
 
 Thanky again
 
 Kind regards
 Michael
 
 
 Am 2013-08-19 17:35, schrieb fnu:
  Hey Michael,
 
  since I dealt somewhat intensiv with IPTV channels the last days,
  German T-Home Entertain, see vdr-portal, I was able to check this
 quickly.
 
  DVB-S/S2:
  ===
  vdr2-vdr:/home/vdr svdrpsend lstc 1
  220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:12:24 2013;
  UTF-8
  250 1 Das Erste
  HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;51
  06=deu
  @106:5104;5105=deu:0:10301:1:1019:0
  221 vdr2 closing connection
  ===
  vdr2-vdr:/home/vdr svdrpsend lstc S19.2E-1-1019-10301-0
  220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:30:30 2013;
  UTF-8
  250 1 Das Erste
  HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;51
  06=deu
  @106:5104;5105=deu:0:10301:1:1019:0
  221 vdr2 closing connection
  ===
  IPTV:
  ===
  vdr2-vdr:/home/vdr svdrpsend lstc 120
  220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:16 2013;
  UTF-8
  250 120 Das Erste
  HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;2
  58=AC3
  @106:259:0:10301:1:10301:0
  221 vdr2 closing connection
  ===
  vdr2-vdr:/home/vdr svdrpsend lstc I-1-10301-10301-0
  220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:24 2013;
  UTF-8
  250 120 Das Erste
  HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;2
  58=AC3
  @106:259:0:10301:1:10301:0
  221 vdr2 closing connection
  ===
 
  So SVDRP does work proberly here.
 
  I also read this RID hint to give channels a unique touch, but I think
  it might be the better idea to find out correct SID, NID, TID for
  these channels and leave RID=0. I needed to do this, to get the few
  EPG info out of that streams. Luckily I had strong support by plugin's
  author, Rolf Ahrenberg, thanks again for that here.
 
  In short do something like this, I did show my own example from above:
 
  ===
  #/ /usr/bin/multicat -u -d 162000 @23.35.10.1:1 ./dump.ts ===
  Dump 1min of that stream, 81=5min, 162000=1min,
  81000=30sek === Check the dump:
  ===
  #/ dvbsnoop -s ts -if ./dump.ts -tssubdecode -hexdumpbuffer 0x12 |
  grep -m1
  -A8 Service_ID | grep _ID
  ===
  You will get something like this, that shows SID, NID and TID:
  ===
Service_ID: 10301 (0x283d)  [=  -- refers to PMT program_number]
Transport_stream_ID: 10301 (0x283d)
Original_network_ID: 1 (0x0001)  [= Astra Satellite Network 19,2-E |
  Soci-t- Europ-enne des Satellites]
  ===
  ===
  Kind regards
  Frank
 
  -Original Message-
  From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On
  Behalf Of Michael Frank
  Sent: Monday, August 19, 2013 4:52 PM
  To: VDR Mailing List
  Subject: [vdr] Channel IDs - DVB-C and IPTV
 
  Hello,
 
  I have a VDR (2.0.2) setup with yaVDR's distribution using a Sundtek
  stick to watch DVB-C. Additionally I want to add a part of a1tv
  (Austrian IPTV) to the setup. While watching IPTV does not pose any
  problems, getting the EPG into these IPTV-Channels does.
 
  a1tv does not provide EPG via the data stream so I added epgdata.com
  service to the VDR. This again is working fine as far as the DVB-C
  Channels are concerned. As for the IPTV it does not work at all.
 
  So, finally, here is the problem:
 
  In order to get EPG data into a channel one has to map a given
  Channel- EPG-ID with VDR's Channel-ID. Unfortunately many channels of
  a1tv provide the same Channel-ID on VDR. So I tried to modify the RID
  of these channels to get a unique Channel-ID (as mentioned in the
  manual files). Whem sending the EPG to VDR via PUTE the command does
  not accept the RID-extended Channel-ID.
 
  Example for DVB-C (working):
  someone@htpc-vdr:~$ svdrpsend lstc 50
  220 htpc-vdr SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 16:41:33 2013;
  UTF-8
  250 50
  HSE24;UPC:33:C0M256:C:6900:4201=2:4211=deu@3:4301:0:4012:1537:4:0
  221 htpc-vdr closing connection
  someone@htpc-vdr:~$ svdrpsend lstc C-1537-4-4012-0
  220

Re: [vdr] Livebuffer for VDR 2.0

[fnu]

 I tested a 1.7.x version some long time ago, but that  did not
 work as well as the original version..

There has never ever been any official Livebuffer feature in any VDR
version.

I hope it'll take a long time to make it into VDR, e.g. as long as it took
to get any file-/recordings-management feature or other really useful stuff
into VDR ... ^^

===
Kind regards
Frank


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

Re: [vdr] New Makefile system

[fnu]

 Klaus is already doing people a massive favour by maintaining this Make
 system and continuing to support it.

FullAck, I guess most people appreciate this way, it makes live not that
bad, some minor changes needed to keep any plugin. There's more work for
many plugins regarding other changes in VDR, despite which Makefile system.
This was IMHO a great job, to keep 99% of the old system with the view into
the future.

With post 2.0 Klaus can now uncompromising cut everything old and
unnecessary, which will probably sort out 80% of all plugins and make
distributors live even easier ... ^^

Thanks for this great work up to now Klaus!

===
Kind regards
fnu 


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

Re: [vdr] [ANNOUNCE] 0.1.0

[fnu]

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 


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

Re: [vdr] small patch for vdr.c: continue even with read-only video directory

[fnu]

 and it's important for me, that vdr cannot write anything to the video
directory.

Since this is important for you personaly, you want to change VDR for all
users, are you serious?

From my personal point of view a read only video directory with an video
disk recorder doesn't make much sense. But I wouldn't deny the need, because
obviously there a single user out there who does need it, strange enough ...

But to change it in a global way like this is IMHO not a way to go. The
correct solution would be that any user needing it, must decide and
configure something. So, a kind of a switch like an OSD option or even a
better way, VDR does check existence of a file in this video directory, e.g.
.vdrro, something similar to .nodelete ...

===
Kind regards
fnu 


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

Re: [vdr] osdteletext and constant disk access with 1.7.38

[fnu]

 Can someone confirm and/or have ideas what might be causing this and if
the osdteletext plugin needs some adjustments to behave properly with new
VDR versions?

IMHO normal behavior ever of that plugin.

Most of us just put that data onto a RAM disk (tmpfs), whereas teletext
data is nothing what need to be saved at shutdown, it's just runtime data
...

===
Kind regards
fnu


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

Re: [vdr] Call for translations for VDR version 2.0.0

[fnu]

 It's definitely difficult to provide short translations of short english
technical keywords and sentences.

If you don't make in couple of words, why translate it? Keep it in the
proper short technical english original, it's not any prose what need to be
translated sensitively. In many cases it is the same with the german
language ...

Or try any similar meaningful short french word, also no need to translate
technical stuff word by word, why? For that 2 people reading it 2 times in 3
years? If they need it, they should look for the meaning of that technical
points ...

Think about a little question, is there a need to translate exit? I know
you guys do it (e.g. sortie), but I guess all of the 7 billion people on
this planet do understand exit in it's sense, or not? So what to say, less
is even more in many cases ...

And to explain specific points, a manual might be better idea instead of
overload VDR with any help fuction, have a look e.g at vdr-wiki.de ...

Happy translating, cheers,

fnu 


___
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

[fnu]

 by VDR User user@gmail.com
 but I guess your friends disagree.

Not only my friends, e.g. one guy of an international customer, a US citizen
living in Germany since 10-15 years, is not willing to talk in german with
us. Just another example, but even our famous foreign workers from all over
Europe do better here, only the french do worse ... ;-)

 I hope you don't misunderstand, I wasn't complaining that vdrportal isn't
english-friendly.

No, no, I got it. What is the most famous english speaking forum?

===
Kind regards
fnu


___
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

[fnu]

 von Klaus Schmidinger
 But with the recent shitstorm I'm having second thoughts...

Hmm, I had also read shitstorms, this does have a different quality. I would
also take it positiv, nobody is questioning your execellent work, in
contrary, a lot of do take part of it and are interessted in. So,
controversial discussions are sometimes necessary ...

Who did post Linux Torvalds words as an example ... ?

===
Kind regards
fnu


___
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

[fnu]

 von Vidar Tyldum vi...@tyldum.com
 Why are the majority of the users German - and why does it stay that way?
Is it for the greater benefit of VDR?

This is not the fault of the german users, VDR is historically a german
speaking project, initiated by a german guy, used by the biggest VDR
community, german, austrian and swiss people. I guess most of them don't
feel save enough to write in english, they don't want to be blamed for not
being nativ speaker and vdr-portal.de is far the better way to find
information and solution.

You should rather ask why the rest does not join this biggest VDR forum?
There are a lot of people answering in english ...

 von Christopher Reimer c.reimer1...@gmail.com
 Then tell me why was there no answer on the mailinglist thread.

Nobody did oversea the consquences and all are surprised due to this eat and
die change, obviously initiated bottomline by one person.

Again it is absolutely not against the change, it might be necessary, but
not now and not in this way. I'm not anymore sure that VDR is a kind of
community project, where here and there are thoughts about all participants.
This number here reminds me more on George Orwells Animal Farm.

Let 1.7.3x become a stable branch and postpone this change to the next
development cycle. So, everybody does get time to get saddled for this
change but with an HDTV capable fallback.

===
Kind regards
fnu


___
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

[fnu]

 As good as vdrportal is as a VDR resource, the language barrier _is_ a
problem for english speakers.

Same with this mailing list for german speakers ... and now?

 or feeling like a welcome visitor/member

A little tale, if I'm in the US, I have to speak english all time. If my US
friends do visit me or colleagues are staying in Germany, I also have to
speak english all the time. They don't even try to speak my/our language
while staying in Germany. And hey, don't think they ever welcomed me in
german language ... ^^

This is just a chicken-and-egg problem, you all don't try to use it, so no
information is collected or any kind of community will be set up. There is
an rarly used international part, but if somebody does ask in english,
she/he gets an answer in english, wherever postet. Time and patience could
solve a lot, even losing shyness of nativ german speakers to answer in
english, but this up to you all ...

Unfortunately the search function of vdr-portal sucks IMHO, so in all
languages, better use google w/ site:vdr-portal.de what-you-search-for.

===
Kind regards
fnu


___
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

[fnu]

 von Manuel Reimer manuel.rei...@gmx.de
 The changes in 1.7.34 are a big change into the right direction!

FullAck, but really at that time of 1.7.xx? At this time where 1.7.xx is
more less saddled by all HDTV users?

Many new festures have been postponed after V2 release. Some of them
wouldn't have this significant impact to the VDR univers, like these changes
on the Makefile structure.

Wouldn't it possible to focus release of V2 and set these changes as very
first change on the upcoming developer release.

===
Kind regards
fnu


___
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

[fnu]

 von  Klaus Schmidinger klaus.schmidin...@tvdr.de
 From what I have seen in this thread lately, I don't think the outcry
would have been any less then...

You're maybe right, but I'm not sure.

Because now, everybody does know, these changes will happen soon, no Plugin
for V2.1 w/o rework.

But V2.1 is near future, so time for rework, V1.7.xx is present, right now,
looking for continuity.

Kick a sibling of 1.7.33 out as V2 or maybe an in between stable release
called V1.8 and go ahead with these important changes in V1.9 ... just a
thought ...

===
Kind regards
fnu




___
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

[fnu]

 von Christopher Reimer c.reimer1...@gmail.com
 Yes, I am happy with the new makefiles.

I'm glad to hear this, but what about all the other developers and users?

Developer version back and forth, VDR 1.7.xx has become silently a somewhat
stable version over the years, due to it's HDTV capability. Becoming an
official stable is honestly long overdue. Nobody can really argue anymore,
1.7 is a developer version, because no HDTV user, not even Klaus, can go
back to stable SDTV VDR 1.6, whereas the majority doesn't have any hardware
for that anymore ...

A massive excluding change like this, is something for a new developer
branch and not a thing for a development cycle where the end could already
be smelled ...

And as far as I remember nobody did complain about the old Makefile
structur, and yes I mean nobody, because the two now known just changed it
w/o warning. Do what ever you need to do, I appriciate it, but remind always
some continuity for all others in the VDR universe.

The situation right now does need a solution, but it can't be the words of
Walter Ulbricht: Vorwärts immer, rückwärts nimmer ...

A compromise must be possible, whatever it looks like, otherwise my
comparison with Louis XIV hasn't been wrong ...

===
Kind regards
fnu


___
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

[fnu]

 Let's not waste more mailing list space with this nonsense.

I got it already, you're way of installation and usage of VDR is the only
valid, all others are stupid. Your statements here are the one and only
truth, even so only you are allowed to make conclusions. Yes man, you're the
very last knight keeping the holy grail of VDR.

===
Kind regards
fnu


___
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

[fnu]

 ... there are way too much changes at the moment :)

FullAck, but the number of changes are not the issue, it's more the
sustainability and the time frame within the changes. Looking to the last 5
versions, each of them do look allmost like a complete new version. There is
allmost no time for other developers (plugins, addons and distros) to react
to them and the worse, they don't now if their work is valid for the next
vdr developer version. If you want to stop any development around VDR, go
ahead like this ...

But don't forget, you don't make a solution liek VDR a success or BBS like
vdr-portal only with a few make; make install users. Over 95% of VDR users
are using a distribution.

===
Kind regards
fnu


___
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

[fnu]

 Keep in mind, all these changes are occurring in the _developer_ version
of VDR, not stable.

Oh damn, I did not even realize this ... ^^

Nobody really want to use VDR 1.6.0 anymore these days, in Europe we would
not be able to watch HDTV. Facing this fact VDR 1.7.3+ is more than just a
developer playground.

All plugins for VDR 1.6.0 are already saddled, for 1.7.x they need keep up
with VDR's development, so that is not a question of choosing the wrong
version. It can't be the right way that there is a VDR developer version,
which is just usable from vanilla source w/o any addon and hardly in any
other environment. How should anybody test it for real life, assuming that
the next version does again deny all work again ... ?

I don't deny changes, quite the contrary, Klaus does now it, I appreciate
them. But the way of the last changes, in best manner of Louis XIV, ignoring
all other needs around can't be the right way.

Derek tell me, do you compile your Linux also from scratch/source? I would
assume you don't do this and rather using something like Fedora, RedHat,
SuSE, Debian, Gentoo etc. using comfortably the offered packages ot their
repositories, even the ones from unstable sources. If I talk about distro, I
do talk rather about these package offerings.

I did compile my VDR from source for many years since the year 2000/2001,
but I appreciate to have it as Debian package or similar later days. I would
also not compile my libreoffice from source, why, it's already there. And I
like to offer up to date Ubuntu packages for interessted users.

VDR is indeed a success and my alltime HTPC favorite, thanks for it Klaus.
But that is not from the users compiling from source. I do not talk about
some dozens of US users compiling VDR themselfs from source. VDR start to
get a huge distribution in Germany and later Europe from pre-packaged ISOs,
like vdr4you, linvdr and especially c't-vdr (thanks Tobi and team). These
days easyvdr, gen2vdr, MLD and yaVDR do provide OOTB VDRs for thousands of
installations in Germany, Europe, maybe worldwide.

Does anybody think these users would be interssted in VDR 1.6.0 nowadays?
No, they are more than happy with these VDR 1.7.x based installations,
modern and capable for HDTV and they do tell this their neighbours using any
crappy satellite receiver with a lot of problems ... ;-)

Linux wouldn't have been that succesfull, if Linus Torvalds would not had an
ear to the needs of others, even business needs ...

===
Kind regards
fnu


___
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

[fnu]

Dominic,

 

good one!

 

I know, a coin has always two sides, but hack, look where Linux nowadays is
. ^^

 

Cheers

Frank

 

Im Auftrag von Dominic Evans
Gesendet: Freitag, 28. Dezember 2012 00:47
An: VDR Mailing List
Betreff: Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make
configuration file in VDR-1.7.35

 

On 27 Dec 2012, at 23:41, fnu wrote:

 

Linux wouldn't have been that succesfull, if Linus Torvalds would not had an
ear to the needs of others, even business needs ...

 

A Christmas message from Linus - IF YOU BREAK USERSPACE I HATE YOU AND YOU
ARE A TERRIBLE PERSON 





 http://article.gmane.org/gmane.linux.kernel/1414106
http://article.gmane.org/gmane.linux.kernel/1414106

___
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

[fnu]

 I think fnu is wrong in his assumption that over 95% of VDR users

I'm not wrong, the users compiling VDR from scratch are far in minority.
Again I'm not just talking about ready to run ISO images.

There are plenty of silent users working the packages out of Linux' distros
repositories, Debian, Ubuntu, Gentoo, Fedrora etc. Many of them run VDR
underneath any other HTPC solution. These users don't argue on mailing lists
nor on the different forum, so nobody can hear them.

On top of these amount, there are a lot of silent users running ISO based
VDRs. I assume there is still a good hundred linvdr installations out there,
running their good old FF cards.

But that is not the topic here, it's more that the few maintainers of these
repositories, what ever kind, are ignored in their needs to provide usable
packages to these quite huge number of users. A few DIY users are more equal
then even fewer distro and packaging maintainers ...

===
Kind regards
fnu


___
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

[fnu]

Oliver Schinagl wrote:
 Nevertheless, good to know that DVB-S2 on the ngene is well supported (I
guess ) :)

Yes it is, but it's a different device, so don't mix it. The kernel modules
ddbridge or ngene do represent the PCIe-Bridges, not the receiving
frontend.

ngene based cards have been the former devices, with less possibilities to
expand tuners, DVB-S2 only available and no CI support. The first versions
of these devices has been a PCIe PCB (V5.4 and prior) with just 2 DVB-S2
tuners and no connector for additional ones. The last version (V5.5) of
ngene based devices had also 2 DVB-S2 tuner and one connector for
additional 2x DVB-S2 (Flex-Modules). I'm running a V5.5 with 4x DVB-S2 in a
VDR since March 2011 connected to a SCR environment, perfect :-)

ddbridge did enhance the possibilities. There are two different solutions
out there, either the classic DVB-S2 dual-tuner PCIe similar to the V5.x
ones, called V6.x. This PCIe PCB do have two connectors for Flex-Modules,
which can be a single CI, dual CI, dual DVB-S2 or Dual DVB-C/T.
Alternatively there are or have been the bridges only (no tuners) available,
either as PCIe 1x PCB or mPCIe. AFAIK there has been two versions out, one
with 2 connectors, one with 4 connectors. With the last you could build a
VDR with up to 8 tuners connected to a single [m]PCIe card ...

The dual Flex-Modules of the V5.5 and V6.2 are interchangable, they are
bottomline the same, just normal product care over the time ...

I'm running also an L4M Dual DVB-S2 V5.4 (ngene) and a V6.2 (ddbridge) in
test and development maschines.

===
Kind regards
fnu


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

Re: [vdr] my PC wakes up one hour late

[fnu]

Nov  2 00:37:03 TV vdr-shutdown: executing 
/usr/share/vdr/shutdown-hooks/S90.acpiwakeup
Nov  2 00:37:03 TV vdr-addon-acpiwakeup: Setting ACPI alarm time to: 
2012-11-02


Hi there,

so, you use acpiwakup, therefor the hardware clock needs to be set to UTC 
time. What does:


- hwclock

say?

===
Regards
fnu 



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

Re: [vdr] Betr: Re: my PC wakes up one hour late

[fnu]

Cedric,

yes of course, you do use ntp, the clock runs correctly, good.

But that wasn't the issue I did ask for. Using acpiwakeup, does need to 
set the hardware clock to UTC timezone.


So, if you don't live in Greenwich next to London or within this timezone at 
all, there should most probably be a difference between the hardware clock 
of your VDR and it's system time.


If your hw clock doesn't run at UTC time, you may see wakeup shifts like you 
did describe it. Some hours before or ahead, where ever you're living.


You can check RTC's time with the command sudo hwclock and check if it 
does run on UTC time, comparing to your systems time, according to 
/etc/timezone.


===
Regards
fnu

PS.: IIRC it is possible to configure acpiwakeup not to need RTC in UTC, 
pls. check documentation for that ... 



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

Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)

[fnu]

 But is it really that necessary?
I guess it depends on the point of view.

It is right not all remotes provide the same key order, but the master plan 
since over 10 years is RGYB. So if a individual doesn't want to use a remote 
following VDR's standard, should find a way around by themself, at least from 
my point of view. But hence, functionality of the color buttons remains still 
the same, even ist YBRG or what ever, pretty sure users get used to it after 
a while ...

 I haven't seen any postings here actually supporting that idea.
 The quasi standard sequence of the color buttons *is* RGYB...

Outside OSD the color buttons can be defined freely, but inside they is kind of 
fixed definitons fixed for these keys by source code. Maybe the target is to 
get a possibilty to change these now somewhat fixed mapping, that each 
individual can define ther what it want to have. Even the order, to match the 
order on the non-VDR remote ...

And yes, I remember 1 or 2 questions in vdr-portal regarding this ... ;-)

Regards
fnu


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

Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)

[fnu]

 I have too.. Already for years (from 2005).. I have RGBY. It's Silver Stone 
 -case with integrated IR remote.

Well then you're already used to the wrong mapping. I guess you'll struggle 
if you get the correct order, isn't it … ?

 

SCNR … ;-)

 

Regards

fnu

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

Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)

[fnu]

 First, it's not true remote have followed some master plan for 10 years 
 that's RGYB.

VDRs master plan, not all remotes. We are talking about VDR here ... :-(


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

Re: [vdr] Theses Client/Server VDR

[fnu]

Dear Tobias,

this was just my vision of a Client/Server capable VDR concept. I felt urged to 
sketch this user friendly concept, after a similar (horrible) discussion here 
on mailing list, where developer did discuss complex solutions just for 
developers.

I don't have the ability to provide a fork and honestly don't want to have one. 
It would rather be cool if some of the ideas become part within the one and 
only VDR.

But I don't know if Klaus does have a sneek view into this vision at all, it's 
up to him. This wasn't a claim, just a sketched design study how an upcoming 
Client/Server capable VDR could look like on the surface. The details under the 
hood are far away from being specified. So, don't wait for it, even if it comes 
(partly) it will be a version 2.2 or further, please let Klaus finish 2.0 with 
all the good new features and HD capability, finally.

Thanks to all, it seems the ideas did found some fellower.

Cheers
Frank

-Original Message-
From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of 
Tobias Hachmer
Sent: Monday, March 12, 2012 9:34 AM
To: vdr@linuxtv.org
Subject: Re: [vdr] Theses Client/Server VDR

Hello list,

this topic seems very interesting. I think it's overdue in times a lot of 
software is client/server oriented to conform the vdr.
Are there any plans how to start with this project? Will the maintainer of vdr 
support this or will there be a fork?

Tobias Hachmer


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

Re: [vdr] Theses Client/Server VDR

[fnu]

Nothing to complain, these thoughts do particularize my sketched vision ...
;-)

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
VDR User
Gesendet: Samstag, 3. März 2012 22:24
An: VDR Mailing List
Betreff: Re: [vdr] Theses Client/Server VDR

Just a few quick thoughts...

Clients have their own independent osd.
Clients have their own display and audio settings.
Clients detect disconnect-from-server and attempt reconnect.
Client labels (living room, office, kids, man cave, etc) for easy
maintenance  identification.

Servers able to (dis)allow timer privileges (create, modify, delete) for
each client.
Servers able to (dis)allow recording privileges (edit, delete) for each
client.
Servers able to handle multiple clients that may be trying to modify/edit
things such as timers  recordings.
Servers should have smart device selection. For example if dvb-s is
requested, use an available dvb-s device before dvb-s2. If a non-turbo fec
device is requested, use an available non-turbo fec device before one that
supports turbo fec. Or some method by which users can create their own
device priority list.

___
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

[fnu]

 Since automatism may be wrong

No, absolutely not, just to keep it super simple for the user.

But yes, I did imply to give interessted users the possibilty to do an
override, which VDR is princible in users personal VDR cloud or the other
settings. Somewhere deep in the OSD ...

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Lars Hanisch
Gesendet: Samstag, 3. März 2012 18:51
An: vdr@linuxtv.org
Betreff: Re: [vdr] Theses Client/Server VDR

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

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

[fnu]

 about Pause and rewind live TV.

What is live TV there, as it is already recorded ... ?

Only users which didn't got into VDR and epgsearch timers do call for this
live buffer function. They hope for a kind of security, which this function
doesn't really provide.

You want to have a feeling how it feels, if a live buffer is the underlying
central function in a PVR solution, just go and test MythTV.

Cheers
fnu


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

[vdr] Theses Client/Server VDR

[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
- 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

Re: [vdr] SoftHDDevice

[fnu]

Dudes,

did set up a basic VDR on Ubuntu Precise yesterday and it did work as expected.

Install a minimal Ubuntu from alternate installer, add apt-get install xorg 
nvidia-current, VDR e.g. from our yaVDR PPA (ppa:yavdr/unstable-vdr, 
ppa:yavdr/main) incl. vdr-plugin-softhddevice and you're almost done. 
SoftHDDevice does start with this basic Xorg from Ubuntu repository, no 
additional WM like openbox, fluxbox, lightdm etc. needed.

Ok, from this point the most work is now to set up all the odds and ends to get 
proper usable VDR, xorg.conf, sensors, hddtemp, remote control etc. ... ;-)

Have fun.

Regards
fnu

-Ursprüngliche Nachricht-
Von: fnu [mailto:v...@auktion.hostingkunde.de] 
Gesendet: Dienstag, 7. Februar 2012 23:42
An: 'VDR Mailing List'
Betreff: AW: [vdr] SoftHDDevice

 You don't need a windows manager with xine/vdr-xine either, but according to 
 softhddevice own text, -f requires it.

Well xorg alone would not work w/o any basic window management stuff, called it 
window manager or not, but bottomline it is one, included in pure xorg. If 
there wouldn't be a thing like this, you would not be able to open just a basic 
windows, like xterm. And you can do this, nowadays black on black instead of 
herringbone pattern, if you just install basic xorg with it's dependencies. 
There must be something which manages the size of the desktop, advise to open a 
window in a specific size on a defined position, or just fullscreen.

All other stuff known as window manager just adds kind of decoration, widgets, 
buttons, a kind of configuration scripting etc. ...

There was also no need to have an decoration manager to operate the old 
softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-)

Regards
fnu


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

Re: [vdr] SoftHDDevice

[fnu]

 What's the url for this plugin? I would definitely like to try it!

http://projects.vdr-developer.org/projects/plg-softhddevice

 Does it also have a built-in media player?

No, at the end the mplayer- and music-plugin will do this job

 Does it support an HD osd?

Where ist the difference? Plugin does support OSD size up to display
resolution ...

Cheers
fnu


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

Re: [vdr] SoftHDDevice

[fnu]

 How about the new truecolor osd VDR has now?

Well, you did ask regarding a HD OSD which isn't automatically a true
color OSD ...

Whereas AFAIK true color OSD is also possible with SD (576i) output, e.g.
xine/xineliboutput. The main problem, there isn't any real true color OSD
skin out there, to use it ...

But the skins I did test, looked impressive with softhddevice :-)

Regards
fnu


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

Re: [vdr] SoftHDDevice

[fnu]

 - I haven't figured out how to enter fullscreen mode.

Well, AFAIK this is mentioned in the README. There are a couple of
switches/options for the plugin start, one of them is -f for full screen.
An other one is -d for the correct display and -x to start xorg by the
plugin. And no, there is no need for a display manager, I wonder where you
got this information ... most of us do test the plugin on existing Linux
desktop installtion, because there's quit a way to go ...

But VDPAU is IMHO closed to be ready for production use, but not VA-API or
even XvBA ...

Since author johns AFAIK isn't dealing with this mailing list, you could
place your questions here in this tread:

http://www.vdr-portal.de/board17-developer/board21-vdr-plugins/109700-softhd
device-software-vdpau-va-api-cpu-decoder-und-ausgabe-plugin/?s=b83100f9ae841
a9015a5769eb450a5611c1c7cb8

Don't worry just post in english, you'll get the answer also in english. Or
feel free to open a new one in english, you will get answers in english ...
;-)

Regards
fnu


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

Re: [vdr] SoftHDDevice

[fnu]

  -fstart with fullscreen window (only with window manager)

Hmm, AFAIK xorg does come with a build in window manager, I'm not 100% sure,
but I guess it's called xwm.

This provides just basic window work and I did use just pure xorg over years
with the softdevice plugin. There was no need to install openbox, fluxbox
etc.

Regards
fnu


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

Re: [vdr] SoftHDDevice

[fnu]

 You don't need a windows manager with xine/vdr-xine either, but according to 
 softhddevice own text, -f requires it.

Well xorg alone would not work w/o any basic window management stuff, called it 
window manager or not, but bottomline it is one, included in pure xorg. If 
there wouldn't be a thing like this, you would not be able to open just a basic 
windows, like xterm. And you can do this, nowadays black on black instead of 
herringbone pattern, if you just install basic xorg with it's dependencies. 
There must be something which manages the size of the desktop, advise to open a 
window in a specific size on a defined position, or just fullscreen.

All other stuff known as window manager just adds kind of decoration, widgets, 
buttons, a kind of configuration scripting etc. ...

There was also no need to have an decoration manager to operate the old 
softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-)

Regards
fnu


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

Re: [vdr] where can I find a working vnsiserver

[fnu]

Isn't it that vdr-plugin-xvdr has had supersed vdr-plugin-vnsiserver?

https://github.com/pipelka/vdr-plugin-xvdr

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Arturo Martinez
Gesendet: Donnerstag, 19. Januar 2012 19:07
An: vdr@linuxtv.org
Betreff: [vdr] where can I find a working vnsiserver

where can I find a working vnsiserver for vdr 1.7.21 and current git XBMC ?
( I am looking for source code, not a .deb package)

___
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] howto ignore lines in channels.conf

[fnu]

 Even though they'd get lost when VDR writes it, allowing comments there
would be an improvement so distros (and VDR itself) could ship the file with
some comments in it that instruct users what they need to do before things
will work, or what the file is for, or...  Same thing applies to
remote.conf, setup.conf, and timers.conf.

The mentioned files are nothing else than a table of the database VDR. There
is no solution out there, where it is possible to edit the channel list
outside the normal operation, or even to think about comments within it. It
is not possible within MythTV, not on commercial settop boxes, PVRs or any
builtin receivers in TV devices, not even with the famous DBox'es and
Dreamboxes. If you're lucky there might be tool where you could connect from
another PC to the box and edit your channel list within small boundaries, so
advantage VDR, 15:0 ...

So, the information has to be managed from datebases frontend, in case of
VDR the OSD or svdrp. The only sufficient solution might be to have a
switch in OSDs channel editor, to disable or enable a entry in channels
list, like it is available on commercial solutions. Same for all relevant
conf-Files, whereas I don't see any reason to put comments into timers.conf,
weird ...

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Ville Skyttä
Gesendet: Sonntag, 15. Januar 2012 12:29
An: vdr@linuxtv.org
Betreff: Re: [vdr] howto ignore lines in channels.conf

On 2012-01-15 13:01, Klaus Schmidinger wrote:

 VDR reads the channels.conf file and doesn't store any information 
 about comments. It only stores the channel data.
 When it writes the file, it writes only the channel data, and at that 
 point any comments in the original file would be lost.

Even though they'd get lost when VDR writes it, allowing comments there
would be an improvement so distros (and VDR itself) could ship the file with
some comments in it that instruct users what they need to do before things
will work, or what the file is for, or...  Same thing applies to
remote.conf, setup.conf, and timers.conf.

If the AllowComments parameter exists just for the purpose of disallowing
comments in files where VDR doesn't preserve them, I suggest removing that
restriction altogether and allowing comments everywhere.
Allowing comments and preserving them are two different things.  For files
where VDR doesn't preserve them it could note that on the first line of such
files, for example like:

# Warning: VDR will overwrite this file without preserving comments.

___
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] howto ignore lines in channels.conf

[fnu]

 At least when I started to use VDR a long time ago, channels.conf pretty
much *had* to be created with tools that weren't included with VDR (scan
or something like that from dvb-apps). 
 I haven't checked recently, but I suspect it's the same these days.

Well that is an other question and valid argument, why is there no
sufficient solution to scan for channels in VDR, like is quit normal on
commercial solution. Not that I like to have a stupid on, which provides me
4000 channels from satellite, whereas only 40-80 or so are really relevent
for me and do have trouble to sort it out laters, like it is also quit
normal on commercial solutions.

There is at a command line tool available, w_scan or a plugin
vdr-plugin-wirbelscan. But yes I can go with the thought, this should be
rather a nativ VDR function.

But this will be pretty difficult to implement, since VDR runs with a
uncounted number of DVB devices. Whereas commercial solutions do need to
work just with their one and only DVB device type. It doesn't matter if it
is avaiblable with DVB-C/T/S receivers, it's always just one type. So the
software does need to be able to run with 3 different DVB type in max. and
not with a thousend or so ...

Regards
fnu


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

Re: [vdr] howto ignore lines in channels.conf

[fnu]

 I've been living with VDR's auto channel update quite well, back since 
 VDR 1.3.x eliminated the need of the AutoPID patch.

I said, I can go with the thought, it should be rather a native VDR
function. From the technical point of view you're right, it runs perfectly,
this function for people who know what to do. But where to hack is it
written down, that experts and specialist wouldn't like some comfort?
Whereas this might things easier for noob's starting to become an expert ...
;-)

But again, I also know this would not be easy to implement, unlike a small
function to enable or disable an entry in channels list thru OSD.

 How long does it take for it to find some channels, and how does that look
like from the user POV?

A couple of weeks ago I did use this feature in a friend's new installation,
it took around 15-20min in the background to gather ~ 500 channels from his
cable provider, while we did watch live tv in foreground. Ok, you need at
least one running entry in channels list, to make it happen. But this could
also be pre-defined iptv entry, like it is done w/ yaVDR ...

Regards
fnu


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

Re: [vdr] resetting recordings

[fnu]

 What level of debugging must be enabled and what do you need to look for
in the syslog to see when vdr is running a scan against the video directory?

Well, none?

===
vdr1-vdr:/var/lib/video.00 touch .update;tail -f /var/log/syslog
Apr 13 09:10:11 vdr1 vdr: [31424] video directory scanner thread started
(pid=31023, tid=31424)
Apr 13 09:10:11 vdr1 vdr: [31423] video directory scanner thread started
(pid=31023, tid=31423)
Apr 13 09:10:11 vdr1 vdr: [31424] video directory scanner thread ended
(pid=31023, tid=31424)
Apr 13 09:10:11 vdr1 vdr: [31423] video directory scanner thread ended
(pid=31023, tid=31423)
===

My main VDR, version 1.7.16 ...

Regards
fnu


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

Re: [vdr] resetting recordings

[fnu]

If you don't have any entry for updating/re-reading recordings in you OSD,
the common way is to touch .update in the appropiate directory of your
recordings, the VDR will then re-read all recordings.

Or just restart VDR services, AFAIK VDR is doing also a re-read here.

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Arturo Martinez
Gesendet: Montag, 11. April 2011 11:06
An: vdr@linuxtv.org
Betreff: [vdr] resetting recordings

My vdr 1.7.x recordings look a bit messy.
I get multiple single entries for the same show although I have put them
physically on the same folder (under the _ subfolder)

How can I force vdr to re-index them?



___
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] BBC HD pixelation

[fnu]

 so I guess it must be a xine-lib problem? or a deinterlacing problem?

Hmm, I don't see a general problem due xinelib, because a couple of guys are
watching BBC HD from Astra 28.2° here in Germany. Due to it's unfavorable
postion, Astra 28.2°, it is basically not easy to get, especially in the
southern parts of germany, but I haven't ever heard there is a general
problem with BBC HD using xine-lib output.

I would rather guess that your setting in config do not fit for watching BBC
HD. It's like in the german ZDF HD, if you have not configured the minimum
buffer setting you wouldn't get any sound, whereas Das Erste HD does work
perfectly, even with the same low buffer settings, ..., so, there are couple
of suggestions for these settings, where you may have look at it?

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Daniel Harris
Gesendet: Samstag, 9. April 2011 22:27
An: VDR Mailing List
Betreff: Re: [vdr] BBC HD pixelation

On Sat, Apr 9, 2011 at 8:05 PM, Klaus Schmidinger
klaus.schmidin...@tvdr.de wrote:




 On 09.04.2011, at 19:03, Daniel Harris mail.dhar...@googlemail.com
wrote:

 Hello

 I am currently experiencing picture pixelation when watching the BBC 
 HD station.  I have tried changing the position of the dish changing 
 deinterlace settings even sending 1080i output to the tv and tuned 
 several paramaters within my xineliboutput config but this seems to 
 have no effect.  The problem does not occur when watching ITV HD so I 
 am confused as to what is causing it.  Is anyone watching freesat BBC 
 HD perfectly and is so how are you doing it.  I have read that other 
 people have had similar problems but that seems to be a few years 
 back so I am not sure if this is a bbc problem a vdr problem or a 
 xine problem.  I would appreciate any help in fixing this.

 I just watched BBC HD live for a couple of minutes and it was totally
fine.

 Klaus



Thank You both for the response, that has cleared thinks up a bit.
vdr using xineliboutput  plays BBC HD live pixelated, plays the recording
pixelated but mplayer plays the file with no pixelation.  so I guess it must
be a xine-lib problem? or a deinterlacing problem? I will give the
xine-plugin a try

Thanks again

Dan

 ___
 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] [Patch] Make RGYB buttons customizeable

[fnu]

Hi there,

to finish discussion if RGYB ist a standard or not or where does it come
from:

- http://www.topteletext.com/en.asp
- http://www.topteletext.com/working/

Regards
fnu

-Ursprüngliche Nachricht-
Von: fnu [mailto:v...@auktion.hostingkunde.de] 
Gesendet: Sonntag, 3. April 2011 16:57
An: 'VDR Mailing List'
Betreff: AW: [vdr] [Patch] Make RGYB buttons customizeable

Well, not only the German one's, there was also a Screenshot from Norway, I
guess a kind of advanced teletext:

http://upload.wikimedia.org/wikipedia/en/d/d0/Digital_teletext_%28NRK%29.jpg

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Klaus Schmidinger
Gesendet: Sonntag, 3. April 2011 12:55
An: vdr@linuxtv.org
Betreff: Re: [vdr] [Patch] Make RGYB buttons customizeable

On 01.04.2011 15:26, Oliver Schinagl wrote:
 I have a iMon remote control, which also doesn't use this 'standard'
 order ;)

 Additionally on my previous mail (I hit send by accident actually :p) 
 I checked the wikipage, and i couldn't find any mention of color or 
 colour in relation to the order of the buttons. Also searching for 
 Yellow didn't result in a single hit, nor did RGYB.

I guess he was referring to the screen shots on that page:

 
http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_l
ebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg
 
http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK%
29.jpg/250px-  Digital_teletext_%28NRK%29.jpg

Klaus


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

Re: [vdr] [Patch] Make RGYB buttons customizeable

[fnu]

===
Your theory that the RGYB color scheme is a worldwide standard with only cheap 
obscure non-media remotes being 'non-compliant' has already been thrown out the 
window.  I don't know why you think pasting a link to an Italian website can 
somehow resurrect the dead theory.  Btw, no link you ever paste will outweigh 
what color scheme people see on their physical remotes.  If you want to argue 
about it further then contact Panasonic, Sony, and your friends at Logitech to 
start with.
===

Well, that's a claim.

It's not just any italian URL, this is the main page of the inventor and 
license holder for TOP Teletext. This is the company where all manufacturer 
do pay their license fees to, if their TV set do provide this function. The 
invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV 
remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) 
B(lue).

Fifteen years later, Klaus adopt these common keys and standardized this order, 
RGYB, for his awesome and incredible solution VDR, as they are anywhere 
available, except on some trashy ones ...

Regards
fnu


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

Re: [vdr] [Patch] Make RGYB buttons customizeable

[fnu]

Well, not only the German one's, there was also a Screenshot from Norway, I
guess a kind of advanced teletext:

http://upload.wikimedia.org/wikipedia/en/d/d0/Digital_teletext_%28NRK%29.jpg

Regards
fnu

-Ursprüngliche Nachricht-
Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von
Klaus Schmidinger
Gesendet: Sonntag, 3. April 2011 12:55
An: vdr@linuxtv.org
Betreff: Re: [vdr] [Patch] Make RGYB buttons customizeable

On 01.04.2011 15:26, Oliver Schinagl wrote:
 I have a iMon remote control, which also doesn't use this 'standard'
 order ;)

 Additionally on my previous mail (I hit send by accident actually :p) 
 I checked the wikipage, and i couldn't find any mention of color or 
 colour in relation to the order of the buttons. Also searching for 
 Yellow didn't result in a single hit, nor did RGYB.

I guess he was referring to the screen shots on that page:

 
http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_l
ebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg
 
http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK%
29.jpg/250px-  Digital_teletext_%28NRK%29.jpg

Klaus


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

Re: [vdr] [Patch] Make RGYB buttons customizeable

[fnu]

 Regardless, users always have the option to patch the feature in if it 
 doesn't become a part of VDR's core.

Here we go! Provide a patch, users can use or not w/o assuming to change 
vdr-core.

Like the majority of users, I do use remotes following kls's VDR standard 
defined a century ago. I don't want to bothered w/ configurable colored keys, 
it can be just another cause for malfunctions, mere you guys are not willing to 
buy a remote which is compatible w/ VDR's standard. This is IMHO not a to high 
expectation, because you also buy DVB devices which are compatible w/ VDR ...

If remotes would be some very expensive devices, I may follow your arguments, 
but you guys do often buy the cheapest you can get and expect that core VDR 
will changed to be usable with these sometimes pulpy devices, wereas also 
compatible devices are available for the same price ...

Regards
fnu


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

Re: [vdr] [Patch] Make RGYB buttons customizeable

[fnu]

 My remote has the color order Yellow, Red, Blue, Green (only an example, i
dont have the remote at hand). Lets say the buttons are Button0, Button1,
Button2, Button3

 My (and perhaps only my) opinion is that vdr should request the leftmost
color button, then the color right next to it (and so on) while learning.
The color displayed in the osd should be assigned via the setup menu.

Are you seriously asking for a major change like this, just for your most
propably unique remote control?

The color order of the RGYB buttons is a common standard, defined for
Teletext centuries ago. So, 99.999% of all remotes providing these keys do
have this order.

http://en.wikipedia.org/wiki/Teletext

Regards
fnu


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

Re: [vdr] [Patch] Make RGYB buttons customizeable

[fnu]

vdr-user:
 That's definitely not true.  I have about 8 different remotes and at least 
 half don't use that button order.  In addition, not every remote has color 
 buttons 4 in a row.  Plenty of them make a square around other buttons such 
 as 'ok/enter' for example.

Oliver Schinagl:
 I wasn't aware that the order of buttons was standarized on remotes

===

Well, could be that not all remotes for each pinchy device might provide color 
keys at all or in this order. But if they are somehow TV oriented, they follow 
this order in a global manner, even the M$ ones, if they have colored keys.

You want an evidence? Just check out the universal remotes form the big three 
manufactures, Philips, Logitech  One-for-All, if the devices do offer colored 
keys, the order is RGYB, nothing left, nothing right, and you should really ask 
yourself, why?

And, the most important point, global standard or not, it has been defined as 
standard in VDR a century ago, and this is a fact.

Regards
fnu


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