vdr

vdr@linuxtv.org

6731 discussions

only single channel handled by CAM and no teletext on encrypted channels.
by Simon Siemonsma 22 Sep '08

22 Sep '08

System: Distribution: Gentoo (amd64) vdr version: 1.6.0_p2 single card Technotrend budget T1500 with CI cart. CAM: Conax cam by Smit. Output on OSD: 7 Setup -> 5 CAM -> 1 Conax Conditional Access -> 9 About Conax CA Number of sessions: 5 Output of cat /var/log/messages | grep vdr | grep CAM: [20686] CAM 1: assigned to device 1 [21000] CAM 1: module present [21000] CAM 1: module ready [21000] CAM 1: Conax Conditional Access, 01, CAFE, BABE [21000] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted To me this doesn't look correct. 5 sessions according to the CAM menu and only a single channel can be decripted. I saw something on the mailinglist dated april. However I didn't understand how it was solved. Probable because there was also another problem. Further I note that I don't have teletext on encripted channels. On FTA channels it works fine. Has anybody an idea what is going on and how I can solve it. Simon Siemonsma

2 2

Re: [vdr] vdr 1.7.0 + reelbox plugin problem - solved
by Josce 22 Sep '08

22 Sep '08

Well it turned out that for some reason Fedora 9 (kernel 2.6.25.14-108.fc9.i686) and VIA EX10000EG motherboard and Reelbox eHD combination doesn't work. I re-installed Fedora twice to make sure. (And still it might be that I overlooked something...) Then I installed an identical Fedora 9 on a different motherboard and it worked immidiately. Big thanks to Niels Wagenaar and Georg Acher for helping me out. Would never have gotten it to work without your help! Josce

1 0

OSD problem with xineliboutput 1.0.1 when playing videos using Media Player
by Pauli Borodulin 21 Sep '08

21 Sep '08

Hi! Here's my current setup: VDR 1.6.0-2, FFmpeg r15245, DirectFB 1.0.1, Xinelib 1.1.15, and Xineliboutput 1.0.1. I have a Matrox G550, so I'm running VDR using -P "xineliboutput --local=fbfe --video=DirectFB" to output the picture thru' tv-out. Everything works nicely except the OSD in Xineliboutput's Media player. When using hardware scaling for video (xineliboutput.Video.SwScale = 0), the OSD is correctly sized with any video, but looks a bit awful (hw scaling is not doing too good job). So I want to use software scaling instead. If I switch software scaling on during video playback, the OSD becomes nice looking, just like it is when watching/playing DVB stuff. BUT, if I later try playing any video with media player (the same as before or another), the OSD is really tiny in the top-left corner. The size of the OSD now seems to depend on the video resolution. If I go to Xineliboutput's settings, disable & enable sw scaling, the OSD is again shown correctly. So this seems to be some kind of problem with initializing the OSD during startup of video playback. Any hints? Br, -- Pauli Borodulin

1 0

Re: [vdr] vdr 1.7.0 + reelbox plugin problem
by Josce 20 Sep '08

20 Sep '08

>Have a look at the hdtsplay-demo in the hdshm3-folder. It is a simple demo >that plays back TS files over the DeCypher. If that works, your basic driver >setup (+ the HW) is OK, and something in the vdr (or the patches) itself >is wrong. Playing back a ts file with hdtsplay is actually even worse. I am using a patched hdshm.c file that I downloaded. The one in the reelbox SVN testing used 'pci_get_device_reverse', which I think has been removed from the newer kernels. I will SVN a completely fresh reelbox tommorrow and see if maybe I have made some mistakes when installing the drivers. Josce

1 0

Re: [vdr] vdr 1.7.0 + reelbox plugin problem
by Josce 20 Sep '08

20 Sep '08

>> I guess the correct term would be "artifacts"? >> I can see the video but here and there across the screen are small "boxes". >What is the CPU load during that time? The host CPU transfers the data into >the shared memory on the card, so anything below 80-90% load indicates >another problem. This is what puzzles me. The CPU load is only about 10% >Have a look at the hdtsplay-demo in the hdshm3-folder. It is a simple demo >that plays back TS files over the DeCypher. If that works, your basic driver >setup (+ the HW) is OK, and something in the vdr (or the patches) itself >is wrong. Thanks, I will try this. Josce

1 0

Re: [vdr] vdr 1.7.0 + reelbox plugin problem
by Josce 20 Sep '08

20 Sep '08

>There is a reset circuit on the that controls the complicated power >sequencing. It is possible that your BIOS is too fast and configures the PCI >space during this powerup sequence. At that time, the HDE is not properly >accessible. > >It is possible to shorten this sequence a bit, but for that you need to >exchange a SMD capacitor on the HDE board. OK, thanks. I have the "Quick Power On Self Test" enabled, so by disabling this I should have this problem fixed. Josce

1 0

Re: [vdr] vdr 1.7.0 + reelbox plugin problem
by Josce 20 Sep '08

20 Sep '08

Noticed some other thing. When I playback a recording that worked well with vdr 1.6.0 the subtitles come 6-7 seconds before they should. The audio and video are in sync. I also get, (which I don't know what they are): virtual void Reel::HdOsd::SetActive(bool) On=1 virtual void Reel::HdOsd::SetActive(bool) On=0 virtual void Reel::HdOsd::SetActive(bool) On=1 virtual void Reel::HdOsd::SetActive(bool) On=0 GET STC 0 virtual void Reel::HdOsd::SetActive(bool) On=1 GET STC 0 GET STC 0 GET STC 0 GET STC 0 GET STC 0 vdr-1.7.0 +vdr-1.6.0-truecolor-compile_fixes.diff +vdr-1.7.0-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff +vdr-1.7.0-multiproto-update.diff Reelbox plugin (SVN revision 8171) multiproto from http://mercurial.intuxication.org/hg/liplianindvb Josce

2 1

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr