vdr

vdr@linuxtv.org

2 participants
6731 discussions

Re: Re: [vdr] ERROR (dvbdevice.c,658): Ungültiger Dateideskriptor with mplayer and vs.h=240 when ask for get eVideoSystem (was [ANNOUNCE] VDR developer version 1.3.34)
by s.huelswitt＠gmx.de 06 Nov '05

06 Nov '05

On 05 Nov 2005 "Frank" <dac440(a)gmx.net> wrote: > Can you tell me, why request will 'only' fail, when vs.h = 240? > On vs.h = 480 or if mplayer playing PAL the file handles will > not be released? Naturally i have now take a look in mplayer-plugin, > but i have see only ePlayMode "pmExtern_THIS_SHOULD_BE_AVOIDED". > What is the difference? There is no difference. The file handles are released every time. If you look at the implementation of cDvbDevice::GetVideoSystem() you will see, that the return value vsPAL is the default. If the ioctl() fails, you get this value regardless of what actualy is played. > I want only get the rich eVideoSystem from vdr without a patch and > not implement all for myself. This is currently impossible. May be it could be a solution, to not only close the file handles on pmEXTERN but reopen them in read-only mode. I don't know if mplayer will work with that fine. And I don't know if Klaus is going to accept patches in this area. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

2 1

(small) patch for uclibc-compatibility wanted?
by Hans-Werner Hilse 05 Nov '05

05 Nov '05

Hi everybody, I'm a relatively new VDR user and very happy with it. As I like to fiddle with such things, I've tried to compile it against uclibc instead of glibc. This worked without problems, but it turned out to be slightly more complicated due to VDR's use of a glibc extension to the sscanf function ("%a[..."), which is defined in another way in C99. VDR uses this only when parsing config files. It was easy to implement a small dirty hack that works around this, but it would be easy to construct a clean patch, too. If there is demand for such a patch, please give me a short notice, I'll post it here, then. Of course this doesn't make much sense if VDR is focussing on glibc only - I can live fine with the hack... I'm currently happily running VDR (1.3.34) from a uclibc-based system and haven't noticed any problems yet. -hwh

3 4

mp3 plugin w/ alsa?
by Harald Milz 05 Nov '05

05 Nov '05

Hi, I moved to softdevice recently (having HD-TV in mind) and am not using the SPDIF out of my FF card any more. I'd rather use the ALSA SPDIF out like softdevice: -P softdevice -ao alsa:pcm=plug:spdif#ac3=plug:spdif# -vo dfb: Works like a charm. (Via VT8235 on an Asus A7V8X board w/ the coax breakout) Just MP3 gives me the bumps. I can either output via the FF card's SPDIF or via OSS which does not support SPDIF. I don't want to switch inputs on my DD receiver either. I also don't want to send analog data to the DD receiver which in turn re-samples the audio to digital. MP3 should really support ALSA. I patched mp3-0.9.something a while ago to write the decoded audio into an arbitrary executable via a pipe. This program can then simply "aplay -D plug:spdif" the audio stream. Works fine. This patch was never accepted by the mp3 developers, though, and no work for ALSA was being done. Has anybody been there, done that? We had that discussion 2 years ago already http://www.linuxtv.org/mailinglists/vdr/2003/11-2003/msg00792.html Duh. -- There was a young poet named Dan, Whose poetry never would scan. When told this was so, He said, "Yes, I know. It's because I try to put every possible syllable into that last line that I can."

1 0

vdr 1.3.35 & posix_fadvise
by s.huelswitt＠gmx.de 05 Nov '05

05 Nov '05

Hi, trying to compile vdr 1.3.35 on my SuSE 8.1 system, I get the following message: tools.c:872: warning: posix_fadvise is not implemented and will always fail The system is running kernel 2.4.32rc1, glibc 2.2.5, gcc 3.2 What are the min. requirements to make this work? Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

4 8

Repeatable vdr 1.3.35 crash at end of recording
by Marko Mäkelä 05 Nov '05

05 Nov '05

At the end of a recording, vdr 1.3.35 (patched with slightly adapted DVBsubs.patch from subtitles-0.3.8 and my suspend patch) crashes repeatably as follows: #0 0x080f9fe4 in cUnbufferedFile::Seek (this=0x0, Offset=0, Whence=0) at tools.c:884 #1 0x080d268a in cFileName::SetOffset (this=0x8344018, Number=2, Offset=0) at recording.c:1345 #2 0x080d2903 in cFileName::NextFile (this=0x0) at recording.c:1358 #3 0x0809ca0c in cDvbPlayer::NextFile (this=0x8475238, FileNumber=0 '\0', FileOffset=-1) at dvbplayer.c:333 #4 0x0809dc6e in cDvbPlayer::Action (this=0x8475238) at dvbplayer.c:393 #5 0x080f43c2 in cThread::StartThread (Thread=0x8475244) at thread.c:234 #6 0xb7eedcfd in start_thread () from /lib/tls/libpthread.so.0 #7 0xb7d72f1e in clone () from /lib/tls/libc.so.6 This looks like new code in 1.3.35. BTW, is there a reason why VDR discards the currently displayed menu at the end of a recording? Marko

3 7

Re: [vdr] ERROR (dvbdevice.c,658): Ungültiger Dateideskriptor with mplayer and vs.h=240 when ask for get eVideoSystem (was [ANNOUNCE] VDR developer version 1.3.34)
by s.huelswitt＠gmx.de 05 Nov '05

05 Nov '05

On 05 Nov 2005 "Frank" <dac440(a)gmx.net> wrote: > looks like the filedescriptor "fd_video" will not be valid, but with vs.h = > 480 and if i ask the driver for myself it works. I guess it's because the MPlayer plugin uses playmode pmExtern_THIS_SHOULD_BE_AVOIDED (this means vdr has closed fd_video & fd_audio while the player is running). If you read the comments in device.h, I wouldn't blame Klaus for anything arising from this playmode. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

3 2

[Dxr3-devel] Re: ALSA works! :-)
by Sebastian Frei 05 Nov '05

05 Nov '05

Am Montag 29 August 2005 02:05 schrieb Nicolas Boullis: > Hi, > > Great news, I just figured out how to have my alsa support work with > xine. It previously did not work because period_bytes_max was too large. > > You can get the new version (that works fine for me) from CVS in the > EM8300-0-15-0-ALSA branch. All comments are welcome. > > You can find, attached to this message, a copy of (the relevant part of) > my .asoundrc file, that is required for applications that can't output > 16-bit big-endian data (most applications can't on little-endian > systems), and that enables software volume control. > > I just used it to play a video with xine, using the alsa interface, > outputing to the "em8300" device. Everything worked fine, except that > the channels are swapped (I should find out how to fix this...). > > > Cheers, > > Nicolas Hi yesterday I tried your patch and it works. At least with mplayer, I don't have other programs installed. But unfortunatly I can't start vdr with this cvs version. It complains about /dev/em8300_ma. S.

1 0

[ANNOUNCE] VDR developer version 1.3.34
by Klaus Schmidinger 04 Nov '05

04 Nov '05

VDR developer version 1.3.34 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.34.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.33-34.diff The changes since version 1.3.33: - Fixed a leftover 'summary.vdr' in vdr.5 (thanks to Peter Bieringer for reporting this one). - Fixed opening recording folders in case the last replayed recording no longer exists (reported by Udo Richter). - Fixed an unjustified "Error while accessing recording!" after deleting a recording from a subfolder. - Fixed handling the '.update' file in case the video directory is not at the default location (reported by Jon Burgess). - Fixed a crash in cConfig::Load() when compiling on the PPC (thanks to Sascha Volkenandt). - Fixed the FATALERRNO macro to check for a non-zero errno value (reported by Marco Schlüßler). - Added a check against MAXOSDAREAS in cOsd::CanHandleAreas() (reported by Udo Richter). - Fixed setting current menu item if the first one is non-selectable. - cOsdItem::cOsdItem() now has a 'Selectable' parameter. - Improved displaying 'sub-title' and 'bottom text' in the CAM menu. - Added status message "Resetting CAM..." for an immediate feedback when the CAM reset has been triggered. - The CAM menu now automatically updates itself in case of a progress display (as used, for instance, when updating the firmware via satellite). - Now skipping some funny characters sent by some CAMs at the beginning of strings. - The CAM menu is now completely closed when pressing the Menu key while inside a sub menu. - Reduced MAX_CONNECT_RETRIES in ci.c to 2 (waiting too long made the whole thing appear hanging). - Added status message "Opening CAM menu..." for an immediate feedback when the CAM menu has been requested. - Speeded up initial opening of the CAM menu. - Fixed handling of menus with no selectable items. - The character 0x8A in CAM menu strings is now mapped to a real newline. - The 'sub-title' and 'bottom text' in the CAM menu can now consist of several lines. - Improved the CAM enquiry menu. Have fun! Klaus

5 9

VDR crash freezing computer !
by michaelip＠free.fr 04 Nov '05

04 Nov '05

Hello. Often when starting my computer, vdr crashes without any specific reason and freezes the computer ! Nothing is possible/available on my comnputer ! I just have to reset it ! Looking at syslog files, I have a long list of kernel PREEMPT, the last one freezing the computer ! Most of this PREMPT finishes with the following line: Nov 3 07:18:39 localhost kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000020 The first PREMPT occurs after a problem on DXR3 card ! Nov 3 07:18:23 localhost vdr[3105]: dxr3: fatal: microcode upload failed: Timer expired Nov 3 07:18:23 localhost kernel: em8300: DICOM Update failed Nov 3 07:18:23 localhost kernel: em8300_video.c: Video Fifo timeout Nov 3 07:18:23 localhost vdr[2470]: dxr3: resuscitation: device failure or user initiated reset I have a long list of call traces... It seems that problems cames from a badly managed page fault ! I don't know what to do... Does anyone have a suggestion of what I could do in order to avoid this ? What could I look in the syslog also ? Many thanks for any help. Michael

3 6

RE: [vdr] mplayer w/ softdevice
by Vladimir Shved 04 Nov '05

04 Nov '05

> -----Original Message----- > From: vdr-bounces(a)linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf > Of Udo Richter > Sent: Friday, November 04, 2005 10:00 AM > To: VDR Mailing List > Subject: Re: [vdr] mplayer w/ softdevice > > Klaus Schmidinger wrote: > >> Thats a limitation of VDR's plugin system. A plugin cannot open a menu > >> from replay mode or other situations, the only way to open a plugin > >> menu is from the main menu. > > > > Since version 1.3.32 a plugin can have its main menu function > > called through cRemote::CallPlugin(). > > Yes, already realized that. So if you want to open a menu, you can trick > cRemote to send the plugin pseudo-key, let the main loop call the main > menu action, catch that, and initiate a custom menu instead of the > default menu. Talk about straight forward. ;) At least its more straight > forward than calling SVDRP. :D > > If some other plugin decides to do the same thing just a moment later, > the call is skipped, so maybe its a good idea to watch for a timeout > between CallPlugin() and MainMenuAction(). > > And of course there's that nasty problem of plugins loaded twice with > the same name, in which case the MainMenuAction of the first loaded > plugin will get all the calls. ;) I've looked through vdr-portal and found this thread w/ patch: return-patch.tgz - http://www.vdr-portal.de/board/thread.php?threadid=40892&sid=5dcd58226ce4dfa f1604598297e58db9 I did not test it yet, will do over weekend, I can't read German but it looks like work around for my issue. Thanks, --Vlad

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr