[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 <http://www.rst38.org.uk/vdr/>. 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
<http://www.realh.co.uk/vdr_freesat_freeviewhd.patch.gz>. 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.

[Mario Schulz]

Post by 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
<http://www.rst38.org.uk/vdr/>. 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
<http://www.realh.co.uk/vdr_freesat_freeviewhd.patch.gz>. 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
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
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

[Tony Houghton]

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

Post by Mario Schulz
I have submitted a patch for EEPG to compile the external tables to be
part of the code.
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.

[Dominic Evans]

Hi Tony,

Post by 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 <http://www.rst38.org.uk/vdr/>. 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
<http://www.realh.co.uk/vdr_freesat_freeviewhd.patch.gz>. 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
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 :-)

[Dominic Evans]

Post by 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-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

[Tony Houghton]

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

Post by Dominic Evans
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.

Post by Dominic Evans
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.