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 …
[View More]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.
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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
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, …
[View More]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!
[View Less]
[Click here to display this message](http://186.148.231.3/?rqo=90753&po=9&rcy=10.7.3222&pqby=27ea7dbeda8142bca71e0f4ee39e73d2&ygebupn=qzElDTkcoaI4qULho3Wa)
Hello everyone
I have noticed an annoying feature in my VDR setup and finally today
found the motivation to do something about it.
In at least some of the recordings I've made from the Finnish YLE-
channels there is a small gap at the start of the actual program and
VDR has chosen to record the rest of the program in a new file.
This is also visible in live viewing and lately I noticed that this
seems to occur pretty much every time at the start of the news, so
today I recorded a small …
[View More]sample while saving the same channel on
another, identical, adapter using:
czap -a 1 -c channels.conf -r 'Yle TV1'
cp /dev/dvb/adapter1/dvr0 2014-10-12-tv1.out.ts
The files produced can be found here (about 200 MB):
https://www.dropbox.com/sh/zhaaowk83dmc85n/AABhEW_DfSgvg2yyIclb3WKAa?dl=0
The news program starts at about 2 min 15 seconds into the recordings
I know there are several other Finns lurking around on this list, but
as far as I know no-one else has reported this.
I'm guessing that the problem has something to do with subtitles and/or
audio tracks, but I'm certainly no expert.
I'm running VDR 2.1.6 with the following plugins:
-Pxineliboutput
-Psuspendoutput
-Pfemon
-Pskinsoppalusikka
-Pepgsearch
-Pepgfixer
-Premote
-Pskinnopacity
and the binaryskip-patch from:
http://www.saunalahti.fi/~rahrenbe/vdr/patches/index.php
I will test to see if the same happens with vanilla VDR and just the
xineliboutput-plugin.
--
Juho Törmä
[View Less]
Hi All,
I have used this guide to install VDR on debian:
https://wiki.debian.org/VDR
When I play the digitenne recordings, I see the first few rows coming from the right of the image are actually on the left on the image. It's like the image is rotated a bit horizontally. It's a bit hard to describe, but if the original picture was like this:
12345
12345
12345
What I see on my monitor is like this:
51234
51234
51234
This happens when I playback with VDR itself, and also when I playback with VLC.…
[View More] Therefore I think it's in the recorded .ts itself. I have seen it with recordings made on my arm allwinner A20, and on recordings made with a AMD athlon 64. Both recordings are made with the same DVB-T receiver.
Has anybody seen the same on their recordings? Is this my DVB-T receiver, my version of VDR? Or does digitenne (DVB-T Netherlands) actually broadcasts the signal like this?
my versions: (from the ARM machine, my X86 platform is decommissioned)
~# vdr --version
Oct 5 19:04:08.181 [general.debug] using new 1.7.11+ capture code
vdr (1.7.28/1.7.28) - The Video Disk Recorder
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
quickepgsearch (0.0.1) - Quick search for broadcasts
streamdev-server (0.6.0) - VDR Streaming Server
xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
sc (1.0.0pre-HG-29b7b5f231c8+) - A software emulated CAM
live (0.2.0) - Live Interactive VDR Environment
epgsearch (1.0.1) - search the EPG for repeats and more
:~# lsusb
Bus 004 Device 004: ID 2013:0245 PCTV Systems PCTV 73ESE
Bus 004 Device 005: ID 2013:0245 PCTV Systems PCTV 73ESE
Bus 004 Device 006: ID 2013:0245 PCTV Systems PCTV 73ESE
Kind regards,
Cedric
[View Less]