vdr September 2008

vdr@linuxtv.org

88 participants
88 discussions

Re: [vdr] Still can't do multiproto :(
by Niels Wagenaar 20 Sep '08

20 Sep '08

Op Vr, 19 september, 2008 21:21, schreef Josce: > > -- SNIP -- > I can't understand why compiler.h is not found, since I have no problems > finding it :) > Getting tired and frustrated, better give this some rest ... > Edit Make.config and change/edit the DVBDIR variable. I guess you don't have it pointed to you multiprot location. In your case you should have it set at: DVBDIR = /usr/local/src/multiproto_plus/linux (change /usr/local/src to your location) > Josce > Regards, Niels Wagenaar

3 6

vdr 1.7.0 + reelbox plugin problem
by Josce 20 Sep '08

20 Sep '08

I have also noted that sometimes when I boot my pc the eHD card gets an IRQ 255. [josce@video tv]#lcpci -v 03:0f.0 Multimedia controller: Micronas USA, Inc. Unknown device 8100 Subsystem: Micronas USA, Inc. Unknown device 8100 Flags: medium devsel, IRQ 255 Memory at dfc00000 (32-bit, non-prefetchable) [disabled] [size=4K] Memory at 20000000 (32-bit, non-prefetchable) [disabled] [size=128M] Capabilities: [40] Power Management version 2 When this happens I can't start the card: [josce@video tv]# modprobe hdshm [josce@video tv]# /usr/local/src/eHD/hdboot -i /usr/local/src/eHD/linux.bin Decypher PCI BAR1: 20000000 Warm Reset Timeout: U-Boot not ready for PCI boot [josce@video tv]# Could my card be defect? Josce

2 1

[ANNOUNCE] VDR developer version 1.7.1
by Klaus Schmidinger 20 Sep '08

20 Sep '08

VDR developer version 1.7.1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. There appears to be a problem with replaying the payload from TS packets on Full-Featured DVB cards. On some channels this works rather fine (with only very small glitches from time to time), while on other channels there are heavy glitches and sometimes even the audio goes mute. My initial approach to replaying TS on FF cards was to simply strip the TS header and send the payload to the usual PlayVideo() and PlayAudio() functions, since the driver itself examines the data and assembles the 2KB PES packets it sends to the hardware. Since the FF cards can replay the TS data as it comes in from the transponder, my assumption was that the same should be possible in Transfer Mode. But maybe there is something wrong with this assumption? Could this be a driver problem? I don't think that simply "throwing memory" at the problem is the solution. Any thoughts? The changes since version 1.7.0: - Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard Nissl). VDR now uses the driver from http://jusst.de/hg/multiproto_plus. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Removed obsolete $(NCURSESLIB) from the Makefile. - Implemented handling the standard component descriptor for AC3 (stream=4), as it will soon be used by the German ARD channels (thanks to Michael Pennewiß for advance information about this change). The previously used "Premiere pseudo standard" (stream=2, type=5) still works, but has apparently been wrongfully used by broadcasters from the beginning. - Added missing description of the 'S' channel parameter to vdr.5 (reported by Reinhard Nissl). - The SVDRP signon message now indicates the character encoding in use, as in "220 video SVDRP VideoDiskRecorder 1.7.1; Fri May 2 16:17:10 2008; ISO-8859-1". This may be useful for instance for external tools that provide EPG data, so that they can correctly encode the strings. - No longer calling FcFini() to avoid problems with older (broken) versions of fontconfig (suggested by Edgar Toernig). - Removed the compile time option VFAT to allow users of precompiled binary distributions to have full control over whether or not to use the --vfat option at runtime (suggested by Michael Nork). - First step towards switching to TS (Transport Stream) as recording format: + The new function cDevice::PlayTs() is used to play TS packets. + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio() are used to play video and audio TS packets, respectively. + The new function cAudio::PlayTs() is used to play audio TS packets. + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that precedes the TS data in Transfer Mode. + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data in a TS in order to find out which streams it contains. + The new class cTsToPes is used to convert TS packets to a PES packet. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). + Live subtitle display no longer uses a ring buffer and separate thread. + cPesAssembler has been removed. Old VDR recordings only contain complete PES packets. + Since a TS needs to have a PAT/PMT, which requires the video stream type to be explicitly given, the format of the VPID field in the channels.conf file and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream type now follows the VPID and optional PPID, separated by an '=' sign. - Updated the sources.conf file (thanks to Oleg Roitburd). - Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander Rieger). - Fixed a problem with calling isyslog() from within the SignalHandler() (thanks to Udo Richter). - Replaced the Finnish language code "smi" with "suo" (thanks to Rolf Ahrenberg). - Fixed wrong value for TableIdBAT in libsi/si.h (thanks to Winfried Köhler). - Errors in config files no longer keep VDR from starting. - Removed unneeded include files <linux/dvb/dmx.h> und <time.h> from remux.h (reported by Tobias Grimm). Have fun! Klaus

7 14

liplianindvb, szap2, szap-s2 hg repositories avialable on http://mercurial.intuxication.org/hg/
by Igor M. Liplianin 20 Sep '08

20 Sep '08

liplianindvb, szap2, szap-s2 hg repositories avialable on http://mercurial.intuxication.org/hg/liplianindvb http://mercurial.intuxication.org/hg/szap2 http://mercurial.intuxication.org/hg/szap-s2 Igor M. Liplianin

1 0

vdr on PS3
by Clemens Kirchgatterer 20 Sep '08

20 Sep '08

i can see many of us are seeking for the right hardware for vdr, so i am. i want to start some discussion about the upcoming Sony PS3 as an vdr client on steroids. as it will support linux out of the box, it seams logical to, at least, think about it. i came to the following pro/contra list: pro: it supports HD (and Blue-Ray), is small and living room ready, comes with linux, has powerful CPU, you get a gameconsole for free ;-) contra: gets hot, likly DRM locked in some regards, it's a sony the last point may be even not so bad, as sony loses money on each selled device. so what do others think about this idea? anything i have not thought about that makes it even impossible to run vdr (or some other softdevice client) on the PS3? best regards ... clemens

9 16

Xineliboutput CVS and AVC (h264)
by Todd Luliak 20 Sep '08

20 Sep '08

I've got my box setup running Debian Etch 2.6.24-rc4, vdr 1.6.2 with Reinhard's patches, the latest xine-lib compiled with the latest external ffmpeg, and vdr-xine. With that configuration I can watch SD and HD in mpeg2 and mpeg4/h264 to 1080p resolutions. I installed the latest CVS of xineliboutput, installed and configured xcompmgr, and gave the gorgeous HUD OSD a spin. Very, very nice. I was, however, a bit disappointed to tune to an h264 channel only to see: "video_decoder: no plugin available to handle 'Advanced Video Coding (H264)'" Is this something I did wrong or is it just the state of affairs with the current xineliboutput? Does xineliboutput use the decoders and plugins as compiled from xine-lib and therefore use external ffmpeg if xine-lib was so configured? If so, what am I missing? Thanks! Todd

1 0

VDR not starting if a plugin fails to start?
by Petri Helin 19 Sep '08

19 Sep '08

Hi, I have been running VDR as a daemon started via init script for some years now. I am currently using version 1.6.0-2. The problem is, that every now and then VDR doesn't start when I boot the server. The culprit seems to be lcdproc plugins, which for some reason cannot always connect to the LCDd daemon. In VDR's log it shows up like this: OK: Sep 18 16:31:49 vdrkone2 vdr: [4890] starting plugin: lcdproc Sep 18 16:31:49 vdrkone2 vdr: connection to LCDd at localhost:13666 established. Sep 18 16:31:49 vdrkone2 vdr: LCD output thread started (pid=4890), display size: 2x16 NOT OK: Sep 18 19:05:45 vdrkone2 vdr: [4876] starting plugin: lcdproc Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: femon Sep 18 19:05:45 vdrkone2 vdr: [4876] stopping plugin: burn Now, the question is, does this really cause VDR to shut down? And if so, should VDR behave in some other way in such a case? Or is it just lcdproc plugin that causes such a behaviour? Is it possible for VDR to retry starting plugin which failed to start? -Petri

7 12

Still can't do multiproto :(
by Josce 19 Sep '08

19 Sep '08

I can't believe this, everyone else seems to get multiproto working, but I can't. :( >cd multiproto_folder >cd linux/include/linux >ln -s /usr/src/linux-headers-`uname -r`/include/linux/compiler.h ./And so I did: ls -l multiproto_plus/linux/include/linux/ lrwxrwxrwx 1 root root 62 2008-09-19 21:11 compiler.h -> /usr/src/kernels/2.6.26.3-29.fc9.i686/include/linux/compiler.h drwxr-xr-x 2 root root 4096 2008-09-19 20:35 dvb -rw-r--r-- 1 root root 7816 2008-09-19 20:35 i2c-id.h -rw-r--r-- 1 root root 1230 2008-09-19 20:35 ivtvfb.h -rw-r--r-- 1 root root 2646 2008-09-19 20:35 ivtv.h -rw-r--r-- 1 root root 2544 2008-09-19 20:35 meye.h -rw-r--r-- 1 root root 1853 2008-09-19 20:35 video_decoder.h -rw-r--r-- 1 root root 53190 2008-09-19 20:35 videodev2.h -rw-r--r-- 1 root root 10596 2008-09-19 20:35 videodev.h -rw-r--r-- 1 root root 4249 2008-09-19 20:35 videotext.h [root@video linux]# uname -r 2.6.26.3-29.fc9.i686 Every time I try to compile vdr, it stops with In file included from dvbdevice.c:17: /usr/include/linux/dvb/video.h:27:28: error: linux/compiler.h: No such file or directory make: *** [dvbdevice.o] Error 1 I have tried both copying and linking compiler.h to linux/include/linux/ I have tried both multiproto and multiproto_plus (hg cloned them today) I have tried both vdr 1.7.0 and 1.7.1 When I look at /usr/include/linux/dvb/video.h: -- cut -- #ifndef _DVBVIDEO_H_ #define _DVBVIDEO_H_ #include <linux/compiler.h> -- cut -- I can't understand why compiler.h is not found, since I have no problems finding it :) Getting tired and frustrated, better give this some rest ... Josce _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=…

1 0

Getting old dvb_ttpci running with new driver and VDR1.7.1
by Matthias Fechner 19 Sep '08

19 Sep '08

Hi Community, I tried these days to migrate to the new driver structure and VDR 1.7 (to later get the HVR4000 running). The driver I used is: http://liplianindvb.sourceforge.net/cgi-bin/hgwebdir.cgi/liplianindvb/ To compile the driver I copied compiler.h from the kernel source to the driver and compiled it (I think was necessary to compile VDR against the driver). When compiling VDR I changed the path for the DVB driver to the dir where I compiled the new driver (in Make.config). But if I start VDR 1.7.1 I only get a black screen (OSD is working fine) and a message that it cannot tune to channel. Switch back to VDR 1.6 and the old driver solved the problem. Was anyone successfull to get that driver with VDR 1.7.1 with the old TT card (Rev 1.3) running? Bye, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook

3 3

Re: [vdr] reelbox plugin - help compiling
by Niels Wagenaar 19 Sep '08

19 Sep '08

-----Original message----- From: Josce <josce39(a)hotmail.com> Sent: Fri 19-09-2008 13:36 To: n.wagenaar(a)xs4all.nl; Subject: RE: [vdr] reelbox plugin - help compiling > > Did you try: > > > > hg pull http://arvdr-dev.free-x.de:8080/testdvb/ > > hg pull http://jusst.de/hg/multiproto/ > > hg pull http://jusst.de/hg/multiproto_plus/ > > Tried http://jusst.de/hg/multiproto_plus/ and managed to get it without > problems. > Compiling it as I type this and so far no problems :) > Be sure to do this also: cd multiproto_folder cd linux/include/linux ln -s /usr/src/linux-headers-`uname -r`/include/linux/compiler.h ./ Change multiproto_folder to your folder wich contains multiproto (ie: multiproto_plus). You need this before you can compile VDR 1.7.0. And concerning the eHD/reelbox plugin. Best thing is, to setup the plugin through VDR (Menu -> Setup -> Plugins -> Reelbox). I do this to, and I never had any problems what so ever. Regards, Niels Wagenaar > > Is there any sort of documentation about reelbox-plugin? > > I have all these "reelbox.xxx" settings in my setup.conf > > and haven't got a clue what they are. > > > > Josce > > > > > > Explore the seven wonders of the world Learn more!

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr September 2008