vdr November 2014

vdr@linuxtv.org

7 participants
9 discussions

xmltv2vdr.pl
by Dominic Evans 14 Aug '15

14 Aug '15

I don't know if anyone else still uses the xmltv2vdr.pl perl script for piping XMLTV data into VDR's epg, but I've been keeping a version of it updated with some additional function here: https://github.com/oldmanuk/xmltv2vdr These are the changes since the last version (1.0.9) was released on the mailing list - Add support for XMLTV episode-num. Currently gets added as EPG entry 'sub-title', if no existing subtitle has been found, in the form sXXeXX (e.g., Bones~s01e01). - Change default SVDRP port number to 6419. - Better support for ATSC/PVRINPUT EPG sources. - Allow multiple channels to have the same XMLTV channel id, useful for multi input (e.g., DVB-T, DVB-S) systems where you want to feed VDR the same info. Previously only a 1:1 mapping was permitted. I've also received a pull request from someone who rewrote the whole script to be a lot more readable and to use full XML parsing (rather than just line-by-line scraping), but I still need to investigate what the performance penalty is before accepting that in.

6 10

VDR & Multiple frontends
by Eddi 25 Jul '15

25 Jul '15

Hi, I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use multiple frontend. So I get: /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/net1 The bus of the two frontend is shared, isn't possible to get access to both frontend simultaneously, so I get an -EBUSY error by trying accessing frontend1 if frontend0 is in use. VDR doesn't support yet the second frontend, and it try to get exclusive access on both frontend on start, so the second frontend is inusabile. Vdr should probe for multiple frontend at start, and access frontend only on channel change. Please can someone give me an help to wrote a patch for this issue? Best Regards, Eddi

4 21

Raspberry Pi, Streamdev + rpihddevice
by Norm Dressler 21 Dec '14

21 Dec '14

Hi all, I just set up a couple of RPI's with the configuration of a Raspberry Pi, rpihddevice and streamdev-client. Works great but a couple of questions. When I'm watching TV with one of the RPI's and want to move to the other RPI, I cannot change the channel from what the first RPI was viewing. I am not sure how to tell streamdev to stop streaming so that I can watch TV on the other RPI? I hope I've been clear with that - it does sound a bit confusing. I know there is a mainmenu entry that says suspend server, but it didn't seem to do anything, unless its done in the background. In relation to this, the RPI doesn't have a power switch so shutting it down is a pain because when you do the halt -p it doesn't actually power off and in order to restart it you must cycle the power to the unit. I'm interested to know what others have been able to accomplish with this configuration to make it work better for them. I've added a number of plugins to improve the viewing pleasure and everything has been fast and clear. In regards to the rpihddevice I am seeing some tearing or 'flutter' when there is high motion with 1080 HD. Its not so bad that it isn't usable - it most certainly works 99% of the time just fine. The one feature I miss with the rpihddevice that softhddevice had was the automatic zoom - hoping that gets added to the wish list at some point. Thanks Norm

5 9

dvbdevice.h
by Richard F 25 Nov '14

25 Nov '14

I need this patch to be able to compile VDR in current SLES11, even though I have all the dvb and dvb devel packages installed. #ifndef __DVBDEVICE_H #define __DVBDEVICE_H // FIXME: workaround for broken linux-dvb header files typedef unsigned char __u8; // RF and for kernel 3.12 typedef long long unsigned int __u64; typedef long long int __s64; Is there a header package missing on the system ? Thanks

1 0

Re: [vdr] Want to have Permashift in your own language?
by cedric.dewijs＠telfort.nl 24 Nov '14

24 Nov '14

>----Origineel Bericht---- >Van : eikesauer(a)t-online.de >Datum : 21/11/2014 19:56 >Aan : vdr(a)linuxtv.org >Onderwerp : [vdr] Want to have Permashift in your own language? > >Hello, > >I want to publish a maintenance release for Permashift >(http://ein-eike.de/vdr-plugin-permashift-english/) and >thought about including some translations. I've already >got German, English and Russian. >If you'd like your favorite language to be included, it's as >easy as translating the following 7 texts. For support of >SD TV displays it would be good to have every line except >the first two to be smaller than say 35 characters, if possible. > >Full line texts >* "Permashift out of memory!" >* "Press key to continue permanent timeshift" >Short texts >* "Auto-buffer live TV" >* "Enable plugin" >* "Memory buffer size" >* "Buffer saving blocks rewind" >(This means that pressing rewind results first in saving of the >whole buffer and rewinding has to wait for that time. To be >honest, I found that hard to express that short even in my >mother language...) >* "Maximum recording length (hours)" > >Ciao, > Eike >_______________________________________________ >vdr mailing list >vdr(a)linuxtv.org >http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > Hi Eike, Personally I don't mind setting the language of the software I run to English. I am however a native speaker in dutch, so I can provide a list of translations. If there are multiple translations possible, I give more than one option. All the different translations have slightly different meanings. "Permashift out of memory!" Permashift heeft geen geheugen meer! Geheugen van Permashift is vol! Permashift heeft geen ruimte meer! "Press key to continue permanent timeshift" Druk op toets voor uitgesteld kijken Druk op toets voor permanent uitgesteld kijken Druk op toets om uitgesteld kijken voort te zetten. "Auto-buffer live TV" directe TV met automatische buffer directe TV (auto-buffer) "Enable plugin" Toepassing activeren plugin activeren "Memory buffer size" Geheugengrootte buffer Buffer saving blocks rewind terugspoelen wacht op veiligstellen buffer terugspoelen wacht op opslaan buffer terugspoelen geblokkeerd, wacht op opslaan buffer "Maximum recording length (hours)" Maximale opnametijd (uren) Kind regards, Cedric

3 5

[Announce] Permashift 1.0 - permanent timeshift in RAM (AKA live buffer)
by Eike 22 Nov '14

22 Nov '14

Hello, Permashift has been largely rewritten and is now published in version 1.0. On popular demand, it does not do automatical disc recordings anymore, but records live TV to a RAM buffer which is used for rewinding or inclusion in recordings. Permashift needs a patch to the VDR (and is incompatible with the old patch!). Patch, plugin and more information are available on the homepage: http://ein-eike.de/vdr-plugin-permashift-english/ Ciao, Eike

3 4

netherlands digitenne: howto watch the "naughty" channel?
by cedric.dewijs＠telfort.nl 08 Nov '14

08 Nov '14

Hi All, I am almost certain this is not the correct mailinglist to ask this. Could you please tell me where I can post this question? The question itself: I have followed this guide to setup digitenne on debian. It works great, but I cannot figure out howto send my pincode to the smartcard. Without the pincode, the smartcard (read by oscam) refuses to create keys for the "naughty" channel. Where in my configuration can I start my search for the solution? https://wiki.debian.org/VDR Kind regards, Cedric

1 0

Re: [vdr] Kernels oops with PCTV nanostick 290e
by Richard F 08 Nov '14

08 Nov '14

Mikko - thanks. I built kernel 3.4, then moved onto 3.12 and both work well with this receiver. FYI I had some trouble getting the right tuning parameters for DVB-T2 with w_scan which I've used for a long time, and went back to dvbscan. I was getting the wrong SID I think - no EPG data received for some channels. The UK-Crystal palace initial tuning file is out of date, here is the one I made that worked for me, not sure all the other params, are right but the frequency list seems to be the important thing. The last 2 are DVB-T2. T 482000000 8MHz 2/3 NONE QAM64 2k 1/32 NONE # London. T 490000000 8MHz 2/3 NONE QAM64 2k 1/32 NONE # London. T 506000000 8MHz 3/4 NONE QAM64 2k 1/32 NONE # London. T 514000000 8MHz 3/4 NONE QAM64 2k 1/32 NONE # London. T 529833333 8MHz 3/4 NONE QAM64 2k 1/32 NONE # London. T 538000000 8MHz 3/4 NONE QAM64 2k 1/32 NONE # London. T 545833333 8MHz AUTO AUTO QAM256 AUTO AUTO AUTO # London. T 570000000 8MHz AUTO AUTO QAM256 AUTO AUTO AUTO # London. On 4/11/2014 11:00, vdr-request(a)linuxtv.org wrote: > There have been some fixes to the nanostick driver after 3.0. If you > are not sure that they have been backported to 3.0, try 3.3 or later. > > https://patchwork.linuxtv.org/patch/9139/

1 0

Kernels oops with PCTV nanostick 290e
by Richard F 03 Nov '14

03 Nov '14

Hi List, Moving from VDR 1.6 to 2.06 for HD (DVB-T2) and seeing regular kernel oops with the PCTV nanostick 290e when using DVB-T2. Unfortunately this seems to kill the receiver until a reboot. It happens while the system is idle. I wondered if anyone else has a similar experience, or is this a test-machine/configuration specific problem? The kernel is 3.0.76 (SLES 11 SP3) The oops always seems to happen after this log entry with the same diagnostics - below "ERROR: can't set filter (pid=18, tid=40, mask=C0): Cannot allocate memory" If using an identical configuration to my current 1.6 but without the HD stick I don't see the problem. I tried a couple of the latest kernel versions in the same series 3.0.101.. with the same result. I might see if I can build suitable later kernels too, not sure if that's helpful - does anyone know or confirm reliable operation on a alter kernel ? Is there a vdr, kernel or other tweak I need ? Oct 31 17:15:52 ha-server vdr: [5639] ERROR: can't set filter (pid=18, tid=40, mask=C0): Cannot allocate memory Oct 31 17:15:52 ha-server kernel: [20717.748177] The following is only an harmless informational message. Oct 31 17:15:52 ha-server kernel: [20717.748182] Unless you get a _continuous_flood_ of these messages it means Oct 31 17:15:52 ha-server kernel: [20717.748184] everything is working fine. Allocations from irqs cannot be Oct 31 17:15:52 ha-server kernel: [20717.748186] perfectly reliable and the kernel is designed to handle that. Oct 31 17:15:52 ha-server kernel: [20717.748190] section handler: page allocation failure: order:4, mode:0x80d4 Oct 31 17:15:52 ha-server kernel: [20717.748195] Pid: 5639, comm: section handler Tainted: GF U N 3.0.76-0.11-default-rf #1 Oct 31 17:15:52 ha-server kernel: [20717.748198] Call Trace: Oct 31 17:15:52 ha-server kernel: [20717.748214] [<ffffffff81004925>] dump_trace+0x75/0x310 Oct 31 17:15:52 ha-server kernel: [20717.748222] [<ffffffff8145411a>] dump_stack+0x69/0x6f Oct 31 17:15:52 ha-server kernel: [20717.748228] [<ffffffff810fe082>] warn_alloc_failed+0x102/0x1a0 Oct 31 17:15:52 ha-server kernel: [20717.748234] [<ffffffff810ffb61>] __alloc_pages_slowpath+0x541/0x7d0 Oct 31 17:15:52 ha-server kernel: [20717.748239] [<ffffffff810fffd9>] __alloc_pages_nodemask+0x1e9/0x200 Oct 31 17:15:52 ha-server kernel: [20717.748245] [<ffffffff81007255>] dma_generic_alloc_coherent+0xa5/0x160 Oct 31 17:15:52 ha-server kernel: [20717.748283] [<ffffffffa065adec>] em28xx_init_isoc+0x13c/0x3a0 [em28xx] Oct 31 17:15:52 ha-server kernel: [20717.748312] [<ffffffffa0598230>] start_feed+0xc0/0xd0 [em28xx_dvb] Oct 31 17:15:52 ha-server kernel: [20717.748328] [<ffffffffa0749f1f>] dmx_section_feed_start_filtering+0xdf/0x180 [dvb_core] Oct 31 17:15:52 ha-server kernel: [20717.748341] [<ffffffffa07483d0>] dvb_dmxdev_filter_start+0x210/0x3f0 [dvb_core] Oct 31 17:15:52 ha-server kernel: [20717.748353] [<ffffffffa074894b>] dvb_demux_do_ioctl+0x22b/0x530 [dvb_core] Oct 31 17:15:52 ha-server kernel: [20717.748364] [<ffffffffa0746240>] dvb_usercopy+0xb0/0x190 [dvb_core] Oct 31 17:15:52 ha-server kernel: [20717.748374] [<ffffffffa0747230>] dvb_demux_ioctl+0x10/0x20 [dvb_core] Oct 31 17:15:52 ha-server kernel: [20717.748381] [<ffffffff811666eb>] do_vfs_ioctl+0x8b/0x3b0 Oct 31 17:15:52 ha-server kernel: [20717.748387] [<ffffffff81166ab1>] sys_ioctl+0xa1/0xb0 Oct 31 17:15:52 ha-server kernel: [20717.748393] [<ffffffff8145ed12>] system_call_fastpath+0x16/0x1b Oct 31 17:15:52 ha-server kernel: [20717.748418] [<00007fd5116a70a7>] 0x7fd5116a70a6 Oct 31 17:15:52 ha-server kernel: [20717.748420] Mem-Info: Oct 31 17:15:52 ha-server kernel: [20717.748423] Node 0 DMA per-cpu: Oct 31 17:15:52 ha-server kernel: [20717.748426] CPU 0: hi: 0, btch: 1 usd: 0 Oct 31 17:15:52 ha-server kernel: [20717.748428] CPU 1: hi: 0, btch: 1 usd: 0 Oct 31 17:15:52 ha-server kernel: [20717.748430] Node 0 DMA32 per-cpu: Oct 31 17:15:52 ha-server kernel: [20717.748433] CPU 0: hi: 186, btch: 31 usd: 0 Oct 31 17:15:52 ha-server kernel: [20717.748436] CPU 1: hi: 186, btch: 31 usd: 72 Oct 31 17:15:52 ha-server kernel: [20717.748441] active_anon:190778 inactive_anon:87398 isolated_anon:0 Oct 31 17:15:52 ha-server kernel: [20717.748442] active_file:60518 inactive_file:60567 isolated_file:0 Oct 31 17:15:52 ha-server kernel: [20717.748444] unevictable:34 dirty:5497 writeback:0 unstable:0 Oct 31 17:15:52 ha-server kernel: [20717.748445] free:19433 slab_reclaimable:49608 slab_unreclaimable:12278 Oct 31 17:15:52 ha-server kernel: [20717.748446] mapped:32492 shmem:2489 pagetables:11435 bounce:0 Oct 31 17:15:52 ha-server kernel: [20717.748448] Node 0 DMA free:8372kB min:340kB low:424kB high:508kB active_anon:8kB inactive_anon:4092kB active_file:720kB inactive_file:864kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15688kB mlocked:0kB dirty:0kB writeback:0kB mapped:464kB shmem:0kB slab_reclaimable:440kB slab_unreclaimable:120kB kernel_stack:80kB pagetables:12kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Oct 31 17:15:52 ha-server kernel: [20717.748461] lowmem_reserve[]: 0 1995 1995 1995 Oct 31 17:15:52 ha-server kernel: [20717.748465] Node 0 DMA32 free:69360kB min:44712kB low:55888kB high:67068kB active_anon:763104kB inactive_anon:345500kB active_file:241352kB inactive_file:241404kB unevictable:136kB isolated(anon):0kB isolated(file):0kB present:2043100kB mlocked:136kB dirty:21988kB writeback:0kB mapped:129504kB shmem:9956kB slab_reclaimable:197992kB slab_unreclaimable:48992kB kernel_stack:3992kB pagetables:45728kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Oct 31 17:15:52 ha-server kernel: [20717.748478] lowmem_reserve[]: 0 0 0 0 Oct 31 17:15:52 ha-server kernel: [20717.748482] Node 0 DMA: 30*4kB 21*8kB 10*16kB 7*32kB 9*64kB 2*128kB 3*256kB 4*512kB 2*1024kB 1*2048kB 0*4096kB = 8416kB Oct 31 17:15:52 ha-server kernel: [20717.748493] Node 0 DMA32: 1848*4kB 5184*8kB 929*16kB 112*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 69360kB Oct 31 17:15:52 ha-server kernel: [20717.748503] 123706 total pagecache pages Oct 31 17:15:52 ha-server kernel: [20717.748505] 92 pages in swap cache Oct 31 17:15:52 ha-server kernel: [20717.748507] Swap cache stats: add 761, delete 669, find 0/0 Oct 31 17:15:52 ha-server kernel: [20717.748509] Free swap = 7274364kB Oct 31 17:15:52 ha-server kernel: [20717.748511] Total swap = 7277408kB Oct 31 17:15:52 ha-server kernel: [20717.757666] 521936 pages RAM Oct 31 17:15:52 ha-server kernel: [20717.757670] 10501 pages reserved Oct 31 17:15:52 ha-server kernel: [20717.757671] 484237 pages shared Oct 31 17:15:52 ha-server kernel: [20717.757673] 373339 pages non-shared Oct 31 17:15:52 ha-server kernel: [20717.757677] unable to allocate 48128 bytes for transfer buffer 1 Thanks!

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2014