Hello,
for most of the GB TV channels it is common to only have the current and the next event in the EPG list.
I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin.
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Thank you very much in advance
Greetings,
Manuel
On Sun, 09 Mar 2014 14:38:48 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
for most of the GB TV channels it is common to only have the current and the next event in the EPG list.
I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin.
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Thank you very much in advance
I guess you're using satellite because there was never a problem with the SD channels on DVB-T (Freeview). The eepg plugin supports Freesat and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD, so instead I use a patch which various people have tweaked over time. I can't find a web download site for it or when it was last posted on this list, so if you're interested and others don't mind a 225K attachment I can post it here again.
I think you are looking for this patch http://www.rst38.org.uk/vdr/ Unfortunately it's quite old.
Christopher
Am 09.03.2014 15:19, schrieb Tony Houghton:
On Sun, 09 Mar 2014 14:38:48 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
for most of the GB TV channels it is common to only have the current and the next event in the EPG list.
I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin.
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Thank you very much in advance
I guess you're using satellite because there was never a problem with the SD channels on DVB-T (Freeview). The eepg plugin supports Freesat and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD, so instead I use a patch which various people have tweaked over time. I can't find a web download site for it or when it was last posted on this list, so if you're interested and others don't mind a 225K attachment I can post it here again.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
That's an older version of the patch I use. Someone updated it to embed the Huffman tables in the source code (now that the tables are complete/stable there's no advantage to loading them from separate files). More recently I had to edit it again to deal with an API change in VDR 2.
On Sun, 09 Mar 2014 16:52:44 +0100 Christopher Reimer vdr@creimer.net wrote:
I think you are looking for this patch http://www.rst38.org.uk/vdr/ Unfortunately it's quite old.
Christopher
Am 09.03.2014 15:19, schrieb Tony Houghton:
On Sun, 09 Mar 2014 14:38:48 +0100 Manuel Reimer manuel.reimer@gmx.de wrote:
for most of the GB TV channels it is common to only have the current and the next event in the EPG list.
I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin.
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Thank you very much in advance
I guess you're using satellite because there was never a problem with the SD channels on DVB-T (Freeview). The eepg plugin supports Freesat and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD, so instead I use a patch which various people have tweaked over time. I can't find a web download site for it or when it was last posted on this list, so if you're interested and others don't mind a 225K attachment I can post it here again.
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
From: Tony Houghton h@realh.co.uk To: vdr@linuxtv.org Sent: Sunday, March 9, 2014 3:19 PM Subject: Re: [vdr] EPG for BBC TV channels?
The eepg plugin supports Freesat
and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD,
I downloaded eepg, e.g. lasst time September 2013, from git-source (http://projects.vdr-developer.org/git/vdr-plugin-eepg.git/). With this and various versions before I have epg on BBC HD (satelite) and never ran into this memory leak which is quoted here and there. If it occurs, it must be running vdr 24 hours a day nonstop. Can someone bring light into this?
Am 15.03.2014 11:30, schrieb Bernd Butscheidt:
I downloaded eepg, e.g. lasst time September 2013, from git-source (http://projects.vdr-developer.org/git/vdr-plugin-eepg.git/). With this and various versions before I have epg on BBC HD (satelite) and never ran into this memory leak which is quoted here and there. If it occurs, it must be running vdr 24 hours a day nonstop. Can someone bring light into this?
It was reported by users running their server 24x7. But I dont know about the current status.
The mechanics used in EEPG look suspicious, it is using a repetitive file load scheme for the tables originating from dark times where these were not yet 100% available.
The VDR patch approach puting these tables into the compiled code once has been suggested for EEPG, but did stay in some experimental branch, you may want to take a look at the EEPG GIT.
- Mario
I have several VDR boxes that all run 24/7 without being restarted for weeks/months at a time. Even then a restart was only necessary due to a system update such as kernel or drive update. All of these boxes use the EEPG plugin and none of them display any kind of memory problem. I strongly urge anyone who wants to try, or thinks there's a problem, to grab the latest git source and see if these problems actually (still) exist.
Am 09.03.2014 14:38, schrieb Manuel Reimer:
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Freesat uses a Huffman encoding for EGP data, which has not made its way into VDR core.
a) Plugin EEPG has these tables (and covers some other EPGs as well) b) A Freesat patch extends VDR to just the Freesat code tables.
- Mario
On Sun, 09 Mar 2014 15:20:31 +0100 Mario Schulz drcms@arcor.de wrote:
Am 09.03.2014 14:38, schrieb Manuel Reimer:
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Freesat uses a Huffman encoding for EGP data, which has not made its way into VDR core.
a) Plugin EEPG has these tables (and covers some other EPGs as well) b) A Freesat patch extends VDR to just the Freesat code tables.
The patch also covers Freeview HD (which uses the same encoding as Freesat, but with standard PIDs instead of Freesat's custom ones), which EEPG doesn't, unless it's been updated since I last used it.
Freesat uses a Huffman encoding for EGP data, which has not made its way into VDR core.
a) Plugin EEPG has these tables (and covers some other EPGs as well) b) A Freesat patch extends VDR to just the Freesat code tables.
The patch also covers Freeview HD (which uses the same encoding as Freesat, but with standard PIDs instead of Freesat's custom ones), which EEPG doesn't, unless it's been updated since I last used it.
The author of the EEPG plugin has always been very helpful. You should just contact him about adding Freeview HD support. Then you won't have to monkey around with patches and messing with the VDR core.
On Sun, 9 Mar 2014 09:53:24 -0700 VDR User user.vdr@gmail.com wrote:
The author of the EEPG plugin has always been very helpful. You should just contact him about adding Freeview HD support. Then you won't have to monkey around with patches and messing with the VDR core.
I think concensus is that the patch's code is cleaner than the plugin's. I looked at the plugin code to see if I could work out how to make the Huffman decoding work on standard PIDs for Freeview as well as on Freesat's non-standard ones, and found it too difficult to follow. The original author might not have so much difficulty, but there's also quite a big memory leak which somehow defied my efforts to trace it with valgrind.
I use the Debian packages, so all I have to do when there's an update (rare at the moment because it isn't tracking Klaus' "developer" versions) is ftech the source with one command, copy the patch into the patches folder and compile it with another single command. The hardest part is generating the command to install just the packages I want and miss out the others :-).
The author of the EEPG plugin has always been very helpful. You should just contact him about adding Freeview HD support. Then you won't have to monkey around with patches and messing with the VDR core.
I think concensus is that the patch's code is cleaner than the plugin's. I looked at the plugin code to see if I could work out how to make the Huffman decoding work on standard PIDs for Freeview as well as on Freesat's non-standard ones, and found it too difficult to follow. The original author might not have so much difficulty, but there's also quite a big memory leak which somehow defied my efforts to trace it with valgrind.
I mentioned this thread to him yesterday. He gave a quick look but needs someone with access to Freeview HD to provide debug logs & test since he doesn't have that provider. Also, I've been using the latest git of EEPG for some time and haven't noticed any big memory leaks. When is the last time you've tried this plugin?
I used to have to patch the VDR core to get eit working here too. I must say, it's quite a pleasure to not have to maintain/fix it anymore now that I can just use EEPG. Even if you don't care about support for Freeview HD in EEPG, I don't see why you wouldn't just put your patch into a plugin and never have to hassle with fixing it again. I think most people prefer not to patch the VDR core at all when it can be avoided.
On Mon, 10 Mar 2014 08:45:05 -0700 VDR User user.vdr@gmail.com wrote:
I think concensus is that the patch's code is cleaner than the plugin's. I looked at the plugin code to see if I could work out how to make the Huffman decoding work on standard PIDs for Freeview as well as on Freesat's non-standard ones, and found it too difficult to follow. The original author might not have so much difficulty, but there's also quite a big memory leak which somehow defied my efforts to trace it with valgrind.
I mentioned this thread to him yesterday. He gave a quick look but needs someone with access to Freeview HD to provide debug logs & test since he doesn't have that provider. Also, I've been using the latest git of EEPG for some time and haven't noticed any big memory leaks. When is the last time you've tried this plugin?
Is he aware that the only difference is that Freeview uses the standard EIT PIDs? If he changes the plugin so it can detect and decode Huffman (there is a marker byte or pair of bytes at the start of every string) no matter which PID the data is from, hopefully he should be able to at least confirm for himself that this doesn't interfere with non-Huffman data. And I'm willing to test betas/git with Freeview HD.
I used to have to patch the VDR core to get eit working here too. I must say, it's quite a pleasure to not have to maintain/fix it anymore now that I can just use EEPG. Even if you don't care about support for Freeview HD in EEPG, I don't see why you wouldn't just put your patch into a plugin and never have to hassle with fixing it again. I think most people prefer not to patch the VDR core at all when it can be avoided.
I think gaining enough understanding of VDR's architecture would be harder for me. I don't often even have to re-apply the patch let alone update it for an API change. Whenever there is an API change affecting the patch it would probably affect an equvalent plugin too. In the old days, when I used to compile developer versions instead of using Debian packages, ISTM that the plugins needed changing at nearly every one of Klaus' weekly updates, but no doubt the API is more stable now.
On 3/9/2014 2:38 PM, Manuel Reimer wrote:
Hello,
for most of the GB TV channels it is common to only have the current and the next event in the EPG list.
I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin.
As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get "real" EPG for those channels?
Thank you very much in advance
Greetings,
Manuel
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi, so the suggestions being made here are not "Tricky" ?
I've been using the XMLTV route now for years, it works. And it works reliably for me
Maybe you ought to take another look?
Cheers Brian
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
-
Bernd Butscheidt -
Brian-Imap -
Christopher Reimer -
Manuel Reimer -
Mario Schulz -
Tony Houghton -
VDR User