vdr

vdr@linuxtv.org

2 participants
6731 discussions

vdr on AllWinner A10, possible or madness?
by cedric.dewijs＠telfort.nl 05 Dec '12

05 Dec '12

Hi All, I now have a standard PC running arch linux and VDR. This works ok, but it uses between 80-150W of power. Much heat and noise, and cost :-). Therefore I was looking for a more power-eficient system. Is it possible to run archlinux and vdr on a system like this? Mele A1000: http://www.elbay.net/nl/content/mele-a1000-allwinner-a10-cortex-a8 I'm wondering if the following works: -HD playback using close source mali driver -Driver for dib07000 based USB DVB receivers -ACPI wake-up and shutdown (does the RTC code work?) -Does VDR and the following plugins compile and run? vdr-addon-acpiwakeup 0.0.10-1 vdr-plugin-epgsearch-git 20120311-1 vdr-plugin-live-git 0.2.0.git-16 vdr-plugin-sc-hg 574-3 vdr-plugin-xineliboutput-git 20120911-1 oscam Best regards, Cedric

5 8

Ouya
by Tony Houghton 04 Dec '12

04 Dec '12

Reading the Allwinner A10 thread made me think. Surely Ouya has great potential as a cheap, low power media client.

1 0

Re: [vdr] Error reading channels.conf on sh4 platform (SOLVED)
by Martin 03 Dec '12

03 Dec '12

Problem solved. After reading on the mailing list I found a item about an other problem with uclibc. Used from the BSD patches the part about sscanf() now it is working. (http://svnweb.freebsd.org/ports/head/multimedia/vdr/files/patch-vdr-1.7.28_…) And an other cheap HD platform for VDR is here. (Motorola VIP19xx sold over here in Holland for 5 - 25 euro.) No frontend module yet but the VDR backend is running. Martin

1 0

Re: [vdr] Error reading channels.conf on sh4 platform
by Martin 03 Dec '12

03 Dec '12

Dec 3 23:24:21 192 vdr: [2462] loading /video/setup.conf Dec 3 23:24:21 192 vdr: [2462] loading /video/sources.conf Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 21 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 22 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 23 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 24 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 25 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 26 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 27 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 28 Dec 3 23:24:21 192 vdr: [2462] ERROR: error in /video/sources.conf, line 29 The first line in sources.conf with info gives an error. Target system : Linux version 2.6.23.17_stm23_0123 (dailybuild@invergordon) (gcc version 4.3.4 20091123 (STMicroelectronics/Linux Base) ) #1 PREEMPT Fri Jan 6 10:47:20 CET 2012 Crosscompiled on: Linux version 2.6.32-45-generic (buildd@batsu) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) ) #100-Ubuntu SMP Wed Nov 14 10:47:49 UTC 2012 With use of STlinux 2.3 for sh4-uclib. (STlinux 2.4 has a newer libuClibc so it didn't work)

2 1

Error reading channels.conf on sh4 platform
by Martin 03 Dec '12

03 Dec '12

Hi, I'm trying to get VDR working on my motorola Vip1900. VDR is running but it doesn't read the channels.conf Tried 1.7.29 & 1.7.27 both give the same problem. Tested with my own channels.conf and the channels.conf from the vdr-source. Any hints? /video # ls > channels.conf epg.data setup.conf themes > /video # vdr -L /vdr/lib -Pdummydevice -Pstreamdev-client > vdr: error while reading '/video/sources.conf' > vdr: error while reading '/video/channels.conf' syslog Dec 3 21:56:53 192 vdr: [1998] VDR version 1.7.27 started > Dec 3 21:56:53 192 vdr: [1998] codeset is 'ASCII' - unknown > Dec 3 21:56:53 192 vdr: [1998] ERROR (tools.c,1392): ./locale: No such > file or directory > Dec 3 21:56:53 192 vdr: [1998] no locale for language code 'deu,ger' > .... > Dec 3 21:56:53 192 vdr: [1998] loading plugin: > /vdr/lib/libvdr-dummydevice.so.1.7.27 > Dec 3 21:56:54 192 vdr: [1998] loading plugin: > /vdr/lib/libvdr-streamdev-client.so.1.7.27 > Dec 3 21:56:54 192 vdr: [1998] loading /video/setup.conf > Dec 3 21:56:54 192 vdr: [1998] loading /video/channels.conf > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 1 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 2 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 3 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 4 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 5 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 6 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 7 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 8 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 9 > Dec 3 21:56:54 192 vdr: [1998] ERROR: error in /video/channels.conf, line > 10

2 1

polarization character case in channels.conf
by Mike Hay 03 Dec '12

03 Dec '12

Hi list, I recently lost access to all vertically polarised channels and after quite a bit of floundering about I discovered the reason for this is due to the case of the polarisation character in channels.conf. According to the vdr changelog it has been possible to specify this in either upper or lower case since version 0.6 but it seems this is not correct - at least in 1.7.31. I generate my channels.conf with w_scan and it produces lower case "h" and "v" for polarisation. It seemed to work OK for the horizontal channels but not the vertical. Perhaps it works for horizontal because this is the default position... Anyway I have resolved my issue by manually changing the case of these characters in channels.conf but wondered if this is really a bug or just a misunderstanding on my part. Regards, Mike

4 8

get a segmentation fault when starting vdr (backtrace included)
by Dieter Bloms 02 Dec '12

02 Dec '12

Hello, I've compiled vdr on alpinelinux 2.5.0 and get a segfault during start of vdr. Even without plugins I get this segfault (I didn't apply any patch to vdr sources). Vdr was started with the command: /usr/local/bin/vdr --config=/etc/vdr --epgfile=/tmp/epg.data --grab=/dev/shm --log=3.1 --mute --no-kbd --user=root --video=/remote/vdr/ I've made a backtrace with gdb: --snip-- vdrservernew:/tmp# gdb --core core /usr/local/bin/vdr GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/bin/vdr...done. [New LWP 26493] [New LWP 26492] [New LWP 26494] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/local/bin/vdr --config=/etc/vdr --epgfile=/tmp/epg.data --grab=/dev/shm --'. Program terminated with signal 11, Segmentation fault. #0 skipspace (s=0x40800000 <Address 0x40800000 out of bounds>) at tools.h:196 196 if ((uchar)*s > ' ') // most strings don't have any leading space, so handle this case as fast as possible (gdb) bt #0 skipspace (s=0x40800000 <Address 0x40800000 out of bounds>) at tools.h:196 #1 isempty (s=0x40800000 <Address 0x40800000 out of bounds>) at tools.c:249 #2 0x00000000004a1eb9 in FromString (s=0x2e531d2 "1 01 deu 4:3", this=0x2e4aba0) at epg.c:36 #3 cComponents::SetComponent (this=<optimized out>, Index=0, s=s@entry=0x2e531d2 "1 01 deu 4:3") at epg.c:81 #4 0x00000000004a40f3 in cEvent::Parse (this=0x2e43360, s=<optimized out>) at epg.c:495 #5 0x00000000004e9ea6 in cRecordingInfo::Read (this=0x2e2d110, f=f@entry=0x2e2c330) at recording.c:468 #6 0x00000000004eb4e3 in cRecording::cRecording (this=0x2e2c650, FileName=0x2e4c15c "Sex_and_the_City_2/2012-11-19.20.10.27-0.rec") at recording.c:723 #7 0x00000000004eceb1 in cRecordings::ScanVideoDir (this=0x7fe7c0 <Recordings>, DirName=0x2e412b0 "/remote/vdr/Sex_and_the_City_2", Foreground=false, LinkLevel=0) at recording.c:1165 #8 0x00000000004ed32c in cRecordings::ScanVideoDir (this=0x7fe7c0 <Recordings>, DirName=0x2e25ff0 "/remote/vdr", Foreground=false, LinkLevel=0) at recording.c:1180 #9 0x000000000052694e in cThread::StartThread (Thread=0x7fe7e0 <Recordings+32>) at thread.c:262 #10 0x00006e6b7ce69406 in start_thread () from /lib/libpthread.so.0.9.32 #11 0x00006e6b7ce61885 in clone () from /lib/libpthread.so.0.9.32 #12 0x0000000000000000 in ?? () --snip-- does anybody see what is wrong here ? -- Regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field.

8 17

[PATCH] small typo in skin.h
by Lars Hanisch 01 Dec '12

01 Dec '12

Hi, Just a small typo, for the sake of complete- and correctness... :) Lars.

1 0

Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6
by N. D. 30 Nov '12

30 Nov '12

>-------- Оригинално писмо -------- >От: Newsy Paper newspaperman_germany(a)yahoo.com >Относно: Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6 >До: VDR Mailing List <vdr(a)linuxtv.org> >Изпратено на: Вторник, 2012, Ноември 27 22:38:10 EET > --- N. D. schrieb am Do, 22.11.2012: > > > Von: N. D. > > Betreff: Re: [vdr] Skystar USB HD + VDR + Astra 23.5E 11817 V / 8psk, fec=5/6 > > An: "Ales Jurik" > > CC: "VDR Mailing List" > > Datum: Donnerstag, 22. November, 2012 14:31 Uhr > > > > > > >-------- Оригинално писмо -------- > > > > >От: Ales Jurik ajurik(a)quick.cz > > > > >Относно: Re: [vdr] Skystar USB HD + VDR + Astra > > 23.5E 11817 V / 8psk,fec=5/6 > > > > >До: VDR Mailing List > > > > >Изпратено на: Сряда, 2012, Юни 13 > > 18:34:55 EEST > > > > > > > > > > > On 06/13/12 10:45, N. D. wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > Since recently I have been using Skystar USB HD > > with my vdr > > > > > > box. However I have some strange issues with > > 11817V on Astra 23.5E. > > > > > > Femon reports that there is a lock and sound comes > > but the image is > > > > > > completely garbled. I am starting to suspect that > > there might be > > > > > > something wrong with the driver, because I have no > > trouble with the > > > > > > other transpoders. Maybe it is the combination of > > fec=5/6 and 8psk on > > > > > > the said transponder that is the reason for this. > > Other transponders > > > > > > with fec=3/4 and 8psk are OK. The same setup with > > an HVR-4000 works > > > > > > fine. > > > > > > > > > > > > Kernel: 3.3.4 > > > > > > > > > > > > VDR: 1.7.27 > > > > > > > > > > > > Could someone who owns a Skystar USB HD and has > > access to Astra 23.5E > > > > > > share his experience? Is this a driver issue a > > problem with vdr or is my card faulty? > > > > > > > > > > > > If someone would be kind enough to test this with > > his/hers hardware, there is a FTA channel on the problematic > > transponder: > > > > > > > > > > > > > > > > > > > > > > > > Planeta > > HD;SatelliteBG:11817:VC56M5O35S1:S23.5E:27500:1001=27:1002=@3:0:0:5410:3:3206:0 > > > > > > > > > > > > > > > > > > > > > > > > Any help would be greatly > > appreciated. > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > few months ago on this transponder was nearly 30% of > > null PID packets > > > > > broadcasted, but now it seems to be much better (less > > than 1Mbps). Also > > > > > multiplexing of this transponder was not equal within > > time - there was > > > > > chunks of packets of PlanetHD multiplexed with chunks > > of other SD > > > > > channels mixed packets. Maybe the buffers for USB are > > not big enough to > > > > > memorize such chunks? But I didn't done measuring for > > some months, so > > > > > the situation may be different now. > > > > > > > > > > You can see bitrates of this transponder at > > > > > http://www.digitalbitrate.com/dtv.php?mux=11817&pid=5410&live=70&lang=en > > . > > > > > > > > > > The bitrate of this channel is nothing special, with > > maximum about 11 > > > > > Mbps, the peak of 20.2Mbps at 22.5. was maybe a joke. > > > > > > > > > > Regards, > > > > > > > > > > Ales > > > > Hi, > > > > Since 20 Nov transponders 12051V and 12207V on the same > > satellite Astra 3B were switched to fec=5/6 and they also > > became unwatchable. Before the change they were 8psk, > > fec=3/4. Now they are 8psk, fec=5/6. > > > > _______________________________________________ > have you tried this patch written by Old_Man? > > http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p9… > > kind regards > > Newsy > > _______________________________________________ I am running kernel 3.6.2 on that particular machine and as far as I can tell that patch is already included. I also tried reverting it but it didn't help. For me the telling difference can be seen here: http://www.digitalbitrate.com/dtv.php?liste=1&live=70&lang=en&mux=12207 Before the change to fec=5/6 the total bitrate of 12207V and 12051V was below 60Mbps. Now it is over 65Mbps. According to the spec for Technotrend S2-3200 (http://www.tt-downloads.de/update/engl/techspec_tt-budget_s2-3200_en.pdf) 60Mbps is the limit for DVB-S. For DVB-S2 it is stated that the card supports bitrates of up to 90Mbps. So my next guess is that the linux driver implementation somehow precludes the support of bitrates above 90Mbps for DVB-S2, which are technically possible nonetheless. After all I was able to accidentally get proper lock on these transponders a couple of times but it is very hard to reproduce.

1 0

ScaleVideo Discussion: API extension or custom service?
by Lucian Muresan 28 Nov '12

28 Nov '12

Hi there, let me start with the background of this, in the last few weeks, a very promising new true color skin raised some attention on the german speaking VDR-Portal, namely "nOpacity" ([1] and [2]). The layout of some of the screens quickly brought up the idea that it would be nice to have the video properly scaled to the available size (smaller than the actual screen), which I tried to already patch with some (but only some) success ([3]). The patch is based on an old hack, called "YaEPG patch", which introduces a member of type tArea in cOsd, which then can be filled with geometry information, whose "bpp" member is abused as a hint weather or not to scale by some skin or plugin which wants to scale down the video material, and you got it, it's as ugly as can be. The problems which we encountered where that the output plugin (in this case softhddevice) knows much more about the video material (like if it is for example 4:3 letterboxed, if the user selected some zooming, some cropping, and so on) than a skin or any other plugin can cope with, in order to get the video scaled right, and there are cases where the scaling is simply wrong. It is and should remain the job of the output plugin to do this right with all the information it has access to, other plugins should only have to ask them to "properly" scale inside an available rectangle, possibly with the hint to just scale (back) full-size of the output device (which could also be an X window). Now, my question, is this issue worth an API extension in cDevice, for example something like bool ScaleVideo(tArea availableRectangle); bool ScaleVideoFullScreen(); which could return true only if the output plugin is capable of doing this, or should plugin developers rather agree upon a custom service which output plugins may provide and skins or other plugins may ask for? Regards, Lucian [1]: http://www.vdr-portal.de/board1-news/board2-vdr-news/115810-announce-skin-n… [2]: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/11… [3]: http://www.vdr-portal.de/board1-news/board2-vdr-news/p1106087-announce-skin…

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr