Re: [vdr] xineliboutput letterbox & mplayer problems
On Tue, 2006-11-07 at 13:12 -0800, Simon Baxter wrote: > plus Udo's suggestion on the options hidden in plugin config works great! May I ask for the option ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr exit codes?
On Tue, 2006-11-07 at 15:44 +0330, JikJikMan wrote: > Hi all, > > Does VDR had exit codes? I mean, how could I find what is the cause of > VDR exit? > > For example, I want to know is the VDR exit for storage failure, driver > failure, timers.conf failure or any thing else. > > It is because I wrote a script for restarting my system when vdr exits, > but I want to prevent this for errors that are persistent, like hard > disk failure, or timers.conf file failure. This topic is quite well covered with man/info pafes + additional README. Anyway, it _could_ be useful to see if immediate exit code was caused by prim.dev or pluigin in case of fatal error ? (just thinking abt my init.d scripts - it is clearly different if net is down, ex, for full house elecrity net-halt+init? I never reload - maybe drivers for vdr restart are useful some users, for me UPS handles all minor problems (including "soft" powerdown), I'd think it might be just for 100% overkill to have any net-reboot - so ,it could be usefuyl to disable exit if currewnt ch is unencryptable ?) - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelib error??? video_out: throwing away image
On Sat, 2006-11-11 at 18:15 +0100, Ulf Elsner wrote: > Am Samstag, 11. November 2006 17:43 schrieb Simon Baxter: > > Hi. > > Hello, > > > I'm having intermittant problems when replaying vdr recordings with > > xineliboutput. Every few minutes I get an audio/video slip/break and > > stdout reports: > > > > video_out: throwing away image with pts 124350653 because it's too old > > (diff > > > > : 29229) > > > > Is this a xinelib message? I'm running a xine-lib taken from cvs on the > > 4th of June 2006 It is xine-lib message, for sure. Basically, with xineliboutput it indicaters your A/V sync is out of order... ? or you are really out of CPU power. In normal situations Y should never see this msg (unless for "frame sync", when switching channels etc. when switching channels etc. What kind of system you are using ? Does this msg appear only when switching channels or starting replay ? If yes, pse, post me (private mail ?) your complete logs + audio and video config with (maybe even complete system cfg). > Yes, it is. > This normally indicates that your system ist too slow for replaying videos. > It can be a misconfiguring of the used software, or too many task running > simultaneously or thelike. That's right. Typically running vdr nd vdr-sxfe iun same machine takes up to twice the CPU load compared to separate systems. PII 400 is just enough to decode + display mpeg2, but if Y have vdr running in same machine you should double each one. > I'm using vdr-xine for displaying and don't know about xineliboutput, so > maybe > someone else can give you hints how to optimize it. > > Maybe it helps: I noticed a higher cpu-usage when replaying with vdr via > vdr-xine as if replaying the files with xine directly. This was improved with > newer versions of vdr-xine - now I use a faster CPU, so it doesn't matter > anymore. > > I hope my answer helps you. > > bye, > > Ulf > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] Xineliboutput with DirectFB
On Wed, 2006-11-08 at 20:02 +0200, Jaakko Kyro wrote: > > This is how I run it: > > > > df_xine -a 5:4 -l 0 -s -f top vdr:/tmp/vdr-xine/stream#demux:mpeg_pes Yes. This clearly runs vdr-xine. > The problem is that the /tmp/vdr-xine/stream doesn't exist here. Actually, > this being a Gentoo system it should appear in > /tmp/vdr/xine/stream > but they don't. :( > I get no clue from the log output either. > And, this is still completely different application - just thinking about to the subjects of your messages. Please see the difference betweren vdr-xine and xineliboutput, those are _different_ _applications_. So, for your initial problem, please, try running vdr-vbfe first. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
> I'm afraid my knowledge here is too limited. > If somebody can come up with an idea of how additional timing information > should be inserted in the PES data, let's hear it. I'm quite sure this is not the point to work witht. > Generally I don't think that VDR should have to to anything regarding > A/V sync during replay. It simply feeds the data to the device as fast > as the device can take it, and syncing audio and video is the device's > job. Maybe mplayer just generates additional PES headers for this? xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LCD plugin
On Thu, 2006-11-02 at 22:14 +0100, Carsten Presser wrote: > Hi, > > why dont you take a look at the files bundeled with the plugin? > are you looking out for - a text or gfx display? well, spending much money for small lcd is not quite wice todasys(?) as you can get 640x480 touchscreen for ~40 euros. > 3.5" seems a little small for me. i dont think there are plenty of > displays in this size out there. > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelib error??? video_out: throwing away image
On Sat, 2006-11-11 at 08:43 -0800, Simon Baxter wrote: > Hi. > > I'm having intermittant problems when replaying vdr recordings with > xineliboutput. Every few minutes I get an audio/video slip/break and stdout > reports: > > video_out: throwing away image with pts 124350653 because it's too old (diff > : 29229) > > > Is this a xinelib message? I'm running a xine-lib taken from cvs on the 4th > of June 2006 Just a quick question: is your display refresh rate very near to 50 Hz? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Petri Hintukainen wrote: xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ? For the tero sample from this thread, I've demultiplexed it with projectx and re-muxed it to VDR, and it was playing fine. It must be on the PES layer. The only thing I've noticed was a slight +/-1 jitter in the PTS timecode of the audio track. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr Feature request
Hello Klaus, Some LNB's don't get a lock while switching to a special frequency. After a small change in the Frequency it works e. G. 12630->12629 ... Some receivers can set a frequency with a adjustable vallue in thei software. Is it posible to get such a feature in vdr? Perhaps in menu->settings->dvb?? MfG. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr Feature request
Halim Sahin wrote: Hello Klaus, Some LNB's don't get a lock while switching to a special frequency. After a small change in the Frequency it works e. G. 12630->12629 ... Such a small deviation shouldn't be much of a problem. Are you sure that's a probem with the LNB? Some receivers can set a frequency with a adjustable vallue in thei software. Is it posible to get such a feature in vdr? Perhaps in menu->settings->dvb?? Try "Setup/LNB/Low|High LNB frequency (MHz)". Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr Feature request
From: "Klaus Schmidinger" <[EMAIL PROTECTED]> To: Halim Sahin wrote: Hello Klaus, Some LNB's don't get a lock while switching to a special frequency. After a small change in the Frequency it works e. G. 12630->12629 ... Such a small deviation shouldn't be much of a problem. Are you sure that's a probem with the LNB? I have two LNB's connect to a FF Card. One LNB needs such a modifikation in the used frequencies. In some cases vdr switches to the unmodified one but its taking more time. Some receivers can set a frequency with a adjustable vallue in thei software. Is it posible to get such a feature in vdr? Perhaps in menu->settings->dvb?? Try "Setup/LNB/Low|High LNB frequency (MHz)". But this affekts all LNB'S in my setup? MfG. Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Segfault with xine-0.7.9
Hi, Gregoire Favre wrote: Any idea what I shall change ? Find the following two lines in xineLib.c #define ASSERT_PALETTE(x) //#define ASSERT_PALETTE(x) x and change them to //#define ASSERT_PALETTE(x) #define ASSERT_PALETTE(x) x Maybe a debug message appears before the segfault. Another idea is to use valgrind on vdr to see whether there are any memory corruptions in vdr-xine. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Segfault with xine-0.7.9
On Sun, Nov 12, 2006 at 01:50:51PM +0100, Reinhard Nissl wrote: > Hi, > > Gregoire Favre wrote: > > >Any idea what I shall change ? > > Find the following two lines in xineLib.c > > #define ASSERT_PALETTE(x) > //#define ASSERT_PALETTE(x) x > > and change them to > > //#define ASSERT_PALETTE(x) > #define ASSERT_PALETTE(x) x > > Maybe a debug message appears before the segfault. No, it's directly the "Segmentation fault (core dumped)" with your change it comes later on. And I think it's the same with your modification : Program terminated with signal 11, Segmentation fault. #0 0x2b9b73805a8a in PluginXine::cXinePalette::cEntry::getIndex (this=0x300f30) at xineLib.c:331 331 return m_index; (gdb) bt #0 0x2b9b73805a8a in PluginXine::cXinePalette::cEntry::getIndex (this=0x300f30) at xineLib.c:331 #1 0x2b9b7380427b in ScaleBitmapHQ (src=0x2bb3900 "°Ä\004", x0=25, y0=50, w=672, h=465, stride=672, ws=503, hs=426, x1=26, y1=40, w1=439, h1=341, transparentIndex=1, colors=0x24009b8, numColors=8, [EMAIL PROTECTED], [EMAIL PROTECTED], currentPaletteSize=16, currentPalette=0x23c35b0, xineLib=0x23bed78) at xineLib.c:1245 #2 0x2b9b73804aa8 in PluginXine::cXineLib::execFuncOsdDrawBitmap (this=0x23bed78, needsScaling=PluginXine::cXineLib::yes, videoWidth=503, videoHeight=426, xineOsd=0x24011d0, window=0, bitmap=0x24009b0, x=13, y=5, width=627, height=460, stride=672) at xineLib.c:1570 #3 0x2b9b73805666 in PluginXine::cXineLib::sendWindow (this=0x23bed78, xineOsd=0x24011d0, windowNum=0, bitmap=0x24009b0, videoLeft=20, videoTop=75, videoWidth=503, videoHeight=426, videoZoomX=108, videoZoomY=135, dontOptimize=false) at xineLib.c:1849 #4 0x2b9b73805818 in PluginXine::cXineLib::SendWindow (this=0x23bed78, xineOsd=0x24011d0, windowNum=0, bitmap=0x24009b0, videoLeft=0, videoTop=0, videoWidth=544, videoHeight=576, videoZoomX=108, videoZoomY=135, dontOptimize=false) at xineLib.c:1690 #5 0x2b9b73807191 in PluginXine::cXineOsd::Flush (this=0x24011d0) at xineOsd.c:356 #6 0x004da3ea in cSkinSTTNGDisplayMenu::Flush (this=0x2401100) at skinsttng.c:646 #7 0x004d130f in cSkins::Flush (this=0x74e580) at skins.c:356 #8 0x004837c6 in cInterface::GetKey (this=0x19c88d0, Wait=true) at interface.c:35 #9 0x004f747a in main (argc=17, argv=0x7fff392e0788) at vdr.c:866 Current language: auto; currently c++ > Another idea is to use valgrind on vdr to see whether there are any > memory corruptions in vdr-xine. I'll try to undestand how then... Thank, -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr Feature request
Halim Sahin wrote: From: "Klaus Schmidinger" <[EMAIL PROTECTED]> To: Halim Sahin wrote: Hello Klaus, Some LNB's don't get a lock while switching to a special frequency. After a small change in the Frequency it works e. G. 12630->12629 ... Such a small deviation shouldn't be much of a problem. Are you sure that's a probem with the LNB? I have two LNB's connect to a FF Card. One LNB needs such a modifikation in the used frequencies. In some cases vdr switches to the unmodified one but its taking more time. Some receivers can set a frequency with a adjustable vallue in thei software. Is it posible to get such a feature in vdr? Perhaps in menu->settings->dvb?? Try "Setup/LNB/Low|High LNB frequency (MHz)". But this affekts all LNB'S in my setup? If you want to address individual LNBs separately you can do so via the diseqc.conf file. Set "Setup/LNB/Use DiSEqC" to yes and make the appropriate entries in diseqc.conf. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr Feature request
> If you want to address individual LNBs separately you can do so > via the diseqc.conf file. Set "Setup/LNB/Use DiSEqC" to yes and > make the appropriate entries in diseqc.conf. > I will give it a try after reading the diseq.conf section in the manpage. Thanks Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelib error??? video_out: throwing away image
I'm having intermittant problems when replaying vdr recordings with xineliboutput. Every few minutes I get an audio/video slip/break and stdout reports: video_out: throwing away image with pts 124350653 because it's too old (diff : 29229) Is this a xinelib message? I'm running a xine-lib taken from cvs on the 4th of June 2006 Just a quick question: is your display refresh rate very near to 50 Hz? It's an NTSC TV: (II) VIA(0): TV (NTSC): Using hsync range of 31.40-56.70 kHz (II) VIA(0): TV (NTSC): Using vrefresh value of 59.94 Hz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Thanks for not giving up on this yet guys. Udo Richter wrote: Petri Hintukainen wrote: xine and/or mplayer just re-generates the pes layer. So, it have to be there ? xine has no problems with the provided samples, so I guess it must be in the PES layer re-muxing. Has anyone with the problem tried to replay with separate mpa+mpv -> pes streams ? For the tero sample from this thread, I've demultiplexed it with projectx and re-muxed it to VDR, and it was playing fine. It must be on the PES layer. The only thing I've noticed was a slight +/-1 jitter in the PTS timecode of the audio track. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: Udo Richter wrote: Tero Siironen wrote: Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X The only disturbance I've noticed is a slight jitter in the PTS values of the audio packets, they are sometimes off by +/- 1, thats 0.01ms. I don't know whether the driver ignores such slight offsets, but I guess it probably does, esp. since it seems to never sync anyway. So much for that theory. I've wrote an experimental patch to VDR to fix this specific stream, but playback is the same, even with the fixed PTS jitter. :( Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
First, I too want to express my gratitude & appreciation towards the people actively persuing a once & for all fix to this problem! So what about this... Copy the mplayer code that does the PES layer and slap it into vdr just to test if the problem persists? It seems that the majority opinion is this is in fact a vdr issue rather than a firmware issue but whats the opinion of the person who develops the firmware (if anyone knows)? On 11/12/06, Udo Richter <[EMAIL PROTECTED]> wrote: Udo Richter wrote:So much for that theory. I've wrote an experimental patch to VDR to fixthis specific stream, but playback is the same, even with the fixed PTSjitter. :(Cheers,Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
VDR User wrote: about this... Copy the mplayer code that does the PES layer and slap it into vdr just to test if the problem persists? I don't think that it is that easy. Its just educated guessing, but I assume that the mpeg data is going a long way through the mplayer core, through demultiplexers, resyncers, multiplexers, playback control and lots of more stuff. Thats probably several thousand lines of code that need to be reviewed, rewritten and integrated into VDR. Thats a huge task, and its probably easier to re-implement every step mplayer does in VDR from scratch. It seems that the majority opinion is this is in fact a vdr issue rather than a firmware issue Once again, I don't agree. VDR does almost nothing on playback. VDR recordings are streams of PES packets, and the DVB driver accepts PES packets for playback. The only thing VDR does is to drop video packets into the video interface and audio packets into the audio interface. (If there wouldn't be the need to separate video from audio, you could probably simply do cat 001.vdr > /dev/dvb/adaper0/video0 and it would play.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelib error??? video_out: RESOLVED
I'm having intermittant problems when replaying vdr recordings with xineliboutput. Every few minutes I get an audio/video slip/break and stdout reports: video_out: throwing away image with pts 124350653 because it's too old (diff : 29229) I've resolved this by using: -P"xineliboutput --primary --local=none --remote=37890" and xine "xvdr:tcp://127.0.0.1:37890#nocache;demux:mpeg_block" # for tcp rather than --local=sxfe seems to have fixed the slips etc now to get vdr-sxfe working on the remote machine... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
