Re: [vdr] Freeview HD support

[Tony Houghton]

On Tue, 03 Apr 2012 19:47:25 +0200
Mario Schulz  wrote:

> I have submitted a patch for EEPG to compile the external tables to be
> part of the code.
> If that is interesting for you as well, you can find it here:
> 
> http://projects.vdr-developer.org/issues/903
> http://projects.vdr-developer.org/attachments/897/patch.txt.gz

AFAICT EEPG uses a sort of "halfway house". The tables are embedded in
one of the header files so it doesn't need to open external files any
more, but the strings still use the same format as the original files
rather than being in the form of arrays, so they still need to be
parsed.

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

[vdr] [ANNOUNCE] vdr-osdteletext 0.9.3

[Tobi]

The new version should compile with VDR 1.7.27 and fix the issues with the
TT6400 OSD.

Special thanks in random order to Udo Richter, gda and nox from
vdrportal.de, Andreas 'powARman' Regel, Rolf Ahrenberg and Uwe

The changes:

* VDR 1.7.27 compatibility (Closes #919), Credit goes to nox and gda fro
  vdrportal.de
* Instead of doing mixed drawing to cOsd and cBitmap only draw to cBitmap
  (Closes #899, this should fixe the issues with the TT6400)

As always: Any help is welcome!

Development site:
  http://projects.vdr-developer.org/projects/plg-osdteletext

Downloads:
  http://projects.vdr-developer.org/projects/plg-osdteletext/files

Git-Web:
  http://projects.vdr-developer.org/git/vdr-plugin-osdteletext.git/

Anonymous Git-access :
  git://projects.vdr-developer.org/vdr-plugin-osdteletext.git


This is intended to be a community maintained project! Don't expect me
to fix your problems, I'm merely maintaining the project!

Please report any bugs, ideas or feature requests to the project site (no
registration required for this!). If you want to contribute patches, new
features or whatever, post an issue or patch to the projects issue tracker
or request to join the project. I would happily add everyone as a project
member, who would like to contribute to the project!

Tobias


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

Re: [vdr] Freeview HD support

[Tony Houghton]

On Tue, 3 Apr 2012 17:33:49 +0100
Dominic Evans  wrote:

> On 3 April 2012 16:23, Tony Houghton  wrote:
> 
> Also, I noticed that (like the EEPG plugin) Dominic's patch only looks
> for Freesat EIT data on PID 3842 (BAT & SDT data is on PID 3841). This
> is where the EPG data can be found on the majority of the
> transponders, broadcast at a symbol rate of 22.0 MSymb/s.
> 
> However, on the Arqiva transponder (11.427 GHz [1]) the data is
> instead present on PID 3002 (BAT & SDT) and PID 3003 (EIT), and is
> transmitted at the much faster symbol rate of 27.5 MSymb/s. This
> should allow a full EPG to be retrieved far more quickly. RdioCaroline
> (one of the radio channels) is a channel you can tune your receiver to
> in order to lock on to this transponder.

Thanks for that info. I knew there was a transponder where the EIT was
broadcast at a much faster rate (I've heard you can get a complete
week's EPG in ~30 seconds instead of the normal ~30 minutes) but I
didn't realise it was on yet another pid.

Back on the subject of Freeview HD, do you happen to know which part of
the SI refers to the Freeview HD channel/transport? It doesn't appear to
be listed in the standard NIT, although once you tune to that channel
everything appears to be normal, other than the Huffman-encoded EIT and
that even its own NIT doesn't refer to itself AFAICT.

> Ideally the patch could be updated to watch for both EIT PIDs, and
> (even more ideally) the VDR EPG idle scan code could be patched to
> immediately jump to Arqiva on S28.2E and retrieve the EPG rather than
> laboriously cycling through all the transponders.

You don't have to cycle through all transponders for Freesat anyway,
unless you want pids for the video, audio etc streams, because the SDT
and EIT are of the "other channel" variety. You can do a complete
channel scan (apart from getting pids) on any one Freesat transponder in
a few seconds.

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

Re: [vdr] Freeview HD support

[Dominic Evans]

On 3 April 2012 16:23, Tony Houghton  wrote:
> Freeview HD's EPG uses the same encoding as Freesat, but for some reason
> the EEPG plugin doesn't recognise it; it probably only uses the extended
> decoder when it's using Freesat's non-standard PIDs.

Also, I noticed that (like the EEPG plugin) Dominic's patch only looks
for Freesat EIT data on PID 3842 (BAT & SDT data is on PID 3841). This
is where the EPG data can be found on the majority of the
transponders, broadcast at a symbol rate of 22.0 MSymb/s.

However, on the Arqiva transponder (11.427 GHz [1]) the data is
instead present on PID 3002 (BAT & SDT) and PID 3003 (EIT), and is
transmitted at the much faster symbol rate of 27.5 MSymb/s. This
should allow a full EPG to be retrieved far more quickly. RdioCaroline
(one of the radio channels) is a channel you can tune your receiver to
in order to lock on to this transponder.

Ideally the patch could be updated to watch for both EIT PIDs, and
(even more ideally) the VDR EPG idle scan code could be patched to
immediately jump to Arqiva on S28.2E and retrieve the EPG rather than
laboriously cycling through all the transponders.

---

[1] http://www.satscan.net/transponder.php?SatelliteID=2&TransponderID=1328

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

Re: [vdr] Freeview HD support

[Dominic Evans]

Hi Tony,

On 3 April 2012 16:23, Tony Houghton  wrote:
> Freeview HD's EPG uses the same encoding as Freesat, but for some reason
> the EEPG plugin doesn't recognise it; it probably only uses the extended
> decoder when it's using Freesat's non-dtandard PIDs.
>
> EEPG's code is a bit tortuous, and it has a memory leak, so I decided to
> look again at the Freesat patch from . It
> needed a bit of updating for recent versions of VDR, and I also updated
> the tables with data from the EEPG plugin.
>
> And it works nicely :-). I haven't been using it long, but it looks like
> it isn't leaking, and all the text in the EPG looks correct.
>
> I've uploaded it to
> . If you use
> Debian or Ubuntu you can add it to the source package with quilt import.
> But also add this line to debian/vdr.install (I got errors after
> trying to add it to the patch):
>
> freesat.t*                              var/lib/vdr/
>
> If not using debs you'll have to copy the freesat.t1 and .t2 files there
> manually, or redefine FREESAT_DATA_DIRECTORY in libsi/freesat.c if you
> want them to live somewhere else.

I'd similarly previously sent a rebased version of the patch to
Dominic Morris (the original author), though he was a bit unsure about
putting it on the homepage until he had time to test it himself.

I've added him on CC so he knows that's you've done this update and
its working with Freeview HD as well. With any luck we can get the
updated version put up on rst38 :-)

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

Re: [vdr] Freeview HD support

[Mario Schulz]

Am 03.04.2012 17:23, schrieb Tony Houghton:
> Freeview HD's EPG uses the same encoding as Freesat, but for some
> reason the EEPG plugin doesn't recognise it; it probably only uses
> the extended decoder when it's using Freesat's non-dtandard PIDs.
> 
> EEPG's code is a bit tortuous, and it has a memory leak, so I
> decided to look again at the Freesat patch from
> . It needed a bit of updating for
> recent versions of VDR, and I also updated the tables with data
> from the EEPG plugin.
> 
> And it works nicely :-). I haven't been using it long, but it looks
> like it isn't leaking, and all the text in the EPG looks correct.
> 
> I've uploaded it to 
> . If you
> use Debian or Ubuntu you can add it to the source package with
> quilt import. But also add this line to debian/vdr.install (I got
> errors after trying to add it to the patch):
> 
> freesat.t*  var/lib/vdr/
> 
> If not using debs you'll have to copy the freesat.t1 and .t2 files
> there manually, or redefine FREESAT_DATA_DIRECTORY in
> libsi/freesat.c if you want them to live somewhere else.
> 
> ___ vdr mailing list 
> vdr@linuxtv.org 
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 

If you are interested:

I have submitted a patch for EEPG to compile the external tables to be
part of the code.
If that is interesting for you as well, you can find it here:

http://projects.vdr-developer.org/issues/903
http://projects.vdr-developer.org/attachments/897/patch.txt.gz



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

[vdr] Freeview HD support

[Tony Houghton]

Freeview HD's EPG uses the same encoding as Freesat, but for some reason
the EEPG plugin doesn't recognise it; it probably only uses the extended
decoder when it's using Freesat's non-dtandard PIDs.

EEPG's code is a bit tortuous, and it has a memory leak, so I decided to
look again at the Freesat patch from . It
needed a bit of updating for recent versions of VDR, and I also updated
the tables with data from the EEPG plugin.

And it works nicely :-). I haven't been using it long, but it looks like
it isn't leaking, and all the text in the EPG looks correct.

I've uploaded it to
. If you use
Debian or Ubuntu you can add it to the source package with quilt import.
But also add this line to debian/vdr.install (I got errors after
trying to add it to the patch):

freesat.t*  var/lib/vdr/

If not using debs you'll have to copy the freesat.t1 and .t2 files there
manually, or redefine FREESAT_DATA_DIRECTORY in libsi/freesat.c if you
want them to live somewhere else.

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

[vdr] Submitting VDR Debian Patches Upstream

[Dominic Evans]

There are numerous patches in the debian packaging tree for yaVDR,
some of which have been naturally picked up from the standard debian
packages and some of which are yaVDR specific:

https://github.com/yavdr/vdr/tree/master/debian/patches

It is not immediately obvious which of these have been submitted to
Klaus for review, and which have been rejected from inclusion in
vanilla VDR. It would seem to be a good idea to go through all of
these and update the headers of them to indicate if they have either
been rejected, or are considered to be too
major/untested/plugin-specific to be included in the vanilla tree.
Debian have patch tagging guidelines which have appropriate fields
designed for this:

http://dep.debian.net/deps/dep3/

The patches already use these guidelines, with correct values for
Author, Description and sometimes Origin but just don't mention
whether the patches have been reviewed/rejected etc.

Ideally we'd go through all of these and add the 'Forwarded' tag to
either link to the mailing list thread where the patch has been
submitted to Klaus, or setting it to 'Forwarded: not-needed' for
patches that we know don't make sense to include in vanilla VDR (e.g.,
plugin specific etc.). Any patches that have previously been rejected
would also have an appropriate message appended to their description
field to indicate they had been rejected and for what reason (as per
the example on the above dep3 link).

As a first glance, there are a few small patches that it would seem
could be submitted to Klaus:


https://github.com/yavdr/vdr/blob/master/debian/patches/opt-29_syncearly.patch

https://github.com/yavdr/vdr/blob/master/debian/patches/opt-43-x_recordshowfree.patch

https://github.com/yavdr/vdr/blob/master/debian/patches/opt-24_jumpplay.patch

Before I rebase these as patches against the latest vanilla sources
and submit them on the mailing list, does anyone know if these have
previously been submitted, either by their authors (if still active),
or a current maintainer?

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