Re: [vdr] eepg plugin with UK freeview (not freesat!) EPG
I too have seen occasional EPG data on other channels become garbled. Is it possible that 'other transport stream' EIT data when received on the HD channel transport stream, is sometimes Huffman compressed? This of course is regardless whether the Eepg plugin is present or not. --- On Sat, 27/8/11, Laz l...@club-burniston.co.uk wrote: From: Laz l...@club-burniston.co.uk Subject: Re: [vdr] eepg plugin with UK freeview (not freesat!) EPG To: VDR Mailing List vdr@linuxtv.org Date: Saturday, 27 August, 2011, 10:46 On Saturday 27 August 2011 01:18:31 Tony Houghton wrote: On Fri, 26 Aug 2011 20:42:38 +0100 Laz l...@club-burniston.co.uk wrote: I thought it had been doing this scrambling when I tried it earlier in the week but have now proved it to myself. Time to start adding some more printfs... The first byte of encoded strings should be 0x1f, followed by 1 or 2 indicating which table should be used (one is optimised for titles, the other for descriptions). Normal strings either start with a printable character for the default character set or a code 0x20 indicating the character set. I use eepg too, but I haven't noticed it scrambling anything (this is probably the first time I've looked at QVC's schedule though ;)). Over the evening, it scrambled more and more channels! :-s Thanks for the pointer to 0x1f! Now I know where to look. (I assume that eepg only decodes EPG that comes in over the air and doesn't touch any EPG alread stored.) Laz ___ 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] FreeviewHD compressed EPG
In the absence of a modification to the Eepg plugin to decompress the FreeviewHD EPG, I have applied the original Freesat.diff to my installation of VDR 1.7.21 and have achieved some success accessing the FreeviewHD EPG. The patch is here: http://www.rst38.org.uk/vdr/freesat.diff The first hunk fails to apply but this is ok because that part of the patch is relevant to freesat only. The decompressed EPG has many 'holes' in it due to incomplete Huffman lookup tables in the freesat.diff. I did manage to port the Freesat lookup tables from the Eepg plugin to the freesat.diff and I can now receive what appears to be the complete FreeviewHD EPG :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eepg plugin with UK freeview (not freesat!) EPG
Slightly off topic but I recently uninstalled the EEPG plugin and reverted back to pure XMLTV data as I was finding it introduced too much instability into my VDR setup. With the plugin I would have problems with my DVB-S2 card causing VDR to restart with the 'broken stream' error code every week or so. Since removing the EEPG plugin I've returned to having flawless VDR uptime and stability again. On 24 October 2011 12:50, Stuart Morris stuart_mor...@talk21.com wrote: I too have seen occasional EPG data on other channels become garbled. Is it possible that 'other transport stream' EIT data when received on the HD channel transport stream, is sometimes Huffman compressed? This of course is regardless whether the Eepg plugin is present or not. --- On Sat, 27/8/11, Laz l...@club-burniston.co.uk wrote: From: Laz l...@club-burniston.co.uk Subject: Re: [vdr] eepg plugin with UK freeview (not freesat!) EPG To: VDR Mailing List vdr@linuxtv.org Date: Saturday, 27 August, 2011, 10:46 On Saturday 27 August 2011 01:18:31 Tony Houghton wrote: On Fri, 26 Aug 2011 20:42:38 +0100 Laz l...@club-burniston.co.uk wrote: I thought it had been doing this scrambling when I tried it earlier in the week but have now proved it to myself. Time to start adding some more printfs... The first byte of encoded strings should be 0x1f, followed by 1 or 2 indicating which table should be used (one is optimised for titles, the other for descriptions). Normal strings either start with a printable character for the default character set or a code 0x20 indicating the character set. I use eepg too, but I haven't noticed it scrambling anything (this is probably the first time I've looked at QVC's schedule though ;)). Over the evening, it scrambled more and more channels! :-s Thanks for the pointer to 0x1f! Now I know where to look. (I assume that eepg only decodes EPG that comes in over the air and doesn't touch any EPG alread stored.) Laz ___ 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
[vdr] Segfault in vdr-sxfe
Evening lads, In dmesg: vdr-sxfe[2926]: segfault at 1 ip 0001 sp b4a1918c error 14 in vdr-sxfe[8048000+2] Doing a quick gdb session on the coredump: Core was generated by `/usr/bin/vdr-sxfe --hud -f -v -l --syslog xvdr://127.0.0.1'. Program terminated with signal 11, Segmentation fault. #0 0x0001 in ?? () (gdb) bt #0 0x0001 in ?? () #1 0x0805c443 in ?? () #2 0xb727636d in ?? () from /usr/lib/libxine.so.2 #3 0xb7276908 in ?? () from /usr/lib/libxine.so.2 #4 0xb7596bc7 in ?? () from /usr/lib/nvidia-current/libGL.so.1 #5 0xb71a969e in clone () from /lib/libc.so.6 (gdb) My interpretation is that it is most likely an issue between lib-xine and the nvidia driver? I have a bunch of these segfaults, but only recently enabled core dumps. Have similar segfaults with vdr itself too, but I guess it is pointless to post those without a core-file? [190166.409612] vdr[16514]: segfault at b6359bcc ip 08139352 sp bfd73480 error 4 in vdr[8048000+14e000] [192021.947521] vdr[14006]: segfault at b63f9bcc ip 08139352 sp bff6a160 error 4 in vdr[8048000+14e000] -- Vidar Tyldum vi...@tyldum.com PGP: 0x3110AA98 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe and compositing
I'm having some problems with vdr-sxfe under GNOME3/mutter. If I start it with --fullscreen it doesn't go fullscreen properly; I can still see the gnome shell panel at the top of the screen and there's no vsync so I get tearing. If I toggle fullscreen off and on again by double-clicking it does cover up the panel correctly but I still get tearing. If I start it without --fullscreen and double click it works correctly without tearing. I would have thought it would be a good idea to have an output backend especially for compositors because AIUI compositing provides features like scaling and YUV-RGB conversion and it would probably be more efficient to work directly with the compositor instead of xv. Is there such a thing for xine? Or would it make sense to use opengl? I've just been watching a recording of Nasa's Greatest Missions from the Quest channel. It was quite jerky, but I think it may have been because the US source was badly converted to PAL; it was one big jerk every second and other programmes don't suffer from this, but I still think it's maybe more jerky than it was with GNOME 2. Could be my imagination. But after watching the NASA thing I noticed that vdr-sxfe had printed loads of copies of this message: [21326] [input_vdr] vdr_adjust_realtime_speed: assertion failed: this-is_trickspeed is true ! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR segfault with cable provider Unitymedia (DE)
vdr-1.7.21 segfault by cable provider unitymedia (DE) Hi, I have problems with the VDR because I get segfaults every ~5-10 minutes. Similar problems are also reported in the VDR-Portal -- www.vdr-portal.de/board60-linux/board14-betriebssystem/board69-c-t-vdr/p1025768-segfault-mit-vdr-1-7-21/?highlight=#post1025768 . The failure / segfault must have something to do with the EPG scan.. When I limit the channels.conf and set in the DVB menu -- Update Channels to Names and PIDs it works without segfaults. In case that the cable provider Unitymedia send wrong data, I assume the vdr should not make a segfault. I make some test with different (unpatched=vanilla VDR) VDR version, but all with the same result -- segfault (see attachment). So it seems that the cable provider send something what let the VDR crash :( . Do you have any idea or patch? Can I test something with special syslog information? Bye, Juergen VDR-1.7.21 SYSLOG: Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 215 from '480 - 18:45,;' to '484 - 23:00,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 218 from '480 - 19:30,;' to '484 - 23:30,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 222 from '463 - 18:45,;' to '483 - 22:45,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 221 from '463 - 18:00,;' to '493 - 22:30,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 219 from '487 - 18:30,;' to '463 - 23:00,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 216 from '465 - 18:30,;' to '477 - 22:45,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 217 from '437 - 18:15,;' to '464 - 22:30,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 220 from '447 - 18:30,;' to '475 - 22:45,;' Oct 25 00:02:49 HTCP vdr: [12852] changing name of channel 223 from '998 - 23:00,;undefined' to '400 - 23:30,;' Oct 25 00:02:49 HTCP vdr: [12852] linking channel 44 from none to 215 218 222 221 219 216 217 220 223 Oct 25 00:02:50 HTCP vdr: [12852] changing name of channel 32 from 'X-treme,;' to 'Sky Sport 1,Sport1;SKY' Oct 25 00:02:50 HTCP vdr: [12852] changing name of channel 33 from 'Golf,;' to 'Sky Sport 2,Sport2;SKY' Oct 25 00:02:50 HTCP vdr: [12852] changing name of channel 30 from '2. Liga,;' to 'Sky Bundesliga,Sky Buli;SKY' Oct 25 00:03:51 HTCP vdr: [12852] changing pids of channel 297 from 0+0=0:0:0:0 to 0+0=0:0:0:0 Oct 25 00:04:55 HTCP vdr: [12852] changing pids of channel 87 from 501+501=2:502=deu@3:0:504 to 601+601=2:602=deu@3:0:604 Oct 25 00:04:58 HTCP vdr: [12852] changing pids of channel 80 from 2801+2801=2:2802=deu@3,2803=mis@3:0:2904 to 2901+2901=2:2902=deu@3,2903=mis@3:0:2904 Oct 25 00:04:59 HTCP vdr: [12852] changing pids of channel 82 from 3001+3001=2:3002=deu@3,3003=mis@3:0:2904 to 2901+2901=2:2902=deu@3,2903=mis@3:0:2904 Oct 25 00:05:18 HTCP kernel: [27954.490184] section handler[12852]: segfault at 3010d ip 004f8fe9 sp 7fa93f7fc558 error 4 in vdr[40+15a000] Oct 25 00:05:18 HTCP init: vdr main process (12761) killed by SEGV signal Oct 25 00:05:18 HTCP init: vdr-frontend main process (12776) terminated with status 1 Oct 25 00:05:18 HTCP vdr-crash: vdr exit with signal SEGV . Restarting Oct 25 00:05:19 HTCP vdr: [13117] VDR version 1.7.21 started Oct 25 00:05:19 HTCP vdr: [13117] switched to user 'vdr' Oct 25 00:05:19 HTCP vdr: [13117] codeset is 'UTF-8' - known Oct 25 00:05:19 HTCP vdr: [13117] found 28 locales in /home/chuck/VDR/vdr-1.7.21/locale Oct 25 00:05:19 HTCP vdr: [13117] loading plugin: /home/chuck/VDR/vdr-1.7.21/PLUGINS/lib/libvdr-xine.so.1.7.21 Oct 25 00:05:19 HTCP vdr: [13117] loading /home/chuck/VDR/var/lib/vdr/setup.conf Core was generated by `/home/chuck/VDR/vdr-1.7.21/vdr --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00'. Program terminated with signal 11, Segmentation fault. #0 cHashBase::Get (this=0x39881c8, Id=1319817600) at tools.c:1992 1992 if (hob-id == Id) (gdb) bt #0 cHashBase::Get (this=0x39881c8, Id=1319817600) at tools.c:1992 #1 0x00482cbc in cEIT::cEIT (this=0x7fa93f7fcd10, Schedules=0x7634e0, Source=1124073472, Tid=81 'Q', Data=value optimized out, OnlyRunningStatus=false) at eit.c:68 #2 0x0048410b in cEitFilter::Process (this=0x7fa940088650, Pid=value optimized out, Tid=81 'Q', Data=0x7fa93f7fce40 Q\360\310Z?\341(\240, Length=value optimized out) at eit.c:382 #3 0x004d5e4c in cSectionHandler::Action (this=0x310de70) at sections.c:212 #4 0x004ecadc in cThread::StartThread (Thread=0x310de70) at thread.c:257 #5 0x7fa949cc9d8c in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x7fa94879404d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x in ?? () VDR-1.7.16 SYSLOG: Oct 25 01:05:01 HTCP vdr: [21320] changing pids of channel 158 from 0+0=0:4011=deu@4:0:0 to 0+0=0:4011=deu@3:0:0 Oct 25 01:05:02 HTCP vdr: [21320] changing pids of channel 159 from
