[vdr] [ANNOUNCE] VDR maintenance patch 1.4.3-3
VDR maintenance patch 1.4.3-3 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-3.diff This is a 'diff' against version 1.4.3-2 (which is the official version 1.4.3, patched with ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-1.diff and ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-2.diff). Small fixes to the officially released VDR versions will be first made available as "maintenance patches" in the Developer directory, so that they can be reviewed and tested before a new official release is published. So please apply the above patch and report whether it works (or if it causes any new problems). This version requires plugins to be recompiled. The changes since version 1.4.3-2: - Fixed setting audio track descriptions after a replay has been stopped (reported by Ulf Kiener, thanks to Marco Schlüßler for pointing out what caused the problem). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: > > On 21 Oct 2006, at 20:22, C.Y.M wrote: > >> >> Yes, it still happens on every firmware revision. But, I really dont >> think this >> is a firmware issue as much as it is a VDR one. There must be several >> ways to >> approach this problem but the best way would be an open source >> solution IMHO. If >> mplayer can successfully forward the video every time straight to the >> FF card >> w/o any transcoding, then why cant VDR do the same thing? Im sure >> someone can >> post links to problematic recordings if you need some to test with. > > Could anyone with this problem see if they have high cpu utilization in > the dvbplayer.c thread when the sync problems occur? > Are you thinking that mplayer might be dropping bad frames more efficiently than VDR? Is it possible that VDR is not dropping the bad frames properly, thus causing dvbplayer.c to struggle when processing/forwarding the video to the FF DVB card? This is the command used when playing back DVB compliant VDR recordings to a FF card with mplayer: mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FF card A/V sync suggestion
On 10/22/06, C.Y.M <[EMAIL PROTECTED]> wrote: Are you thinking that mplayer might be dropping bad frames more efficiently thanVDR? Is it possible that VDR is not dropping the bad frames properly, thus causing dvbplayer.c to struggle when processing/forwarding the video to the FFDVB card? This is the command used when playing back DVB compliant VDRrecordings to a FF card with mplayer:mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdrNotice that "-framedrop" is added to the command line. I wonder if that is thereason why mplayer is "immune" to the a/v desync problem.Best Regards.___ vdr mailing listvdr@linuxtv.orghttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Certainly I think the problem is that VDR is not properly doing sync, especially with DVB transmissions that are prone to error (e.g. DVB-T). I have tried virtually all of the hotplug firmwares and followed the DVB CVS driver for the last few months and it doesn't make any difference. I also use the cards digital output as well as the analogue out and it doesn't make any difference there is always sync problems, especially after a glitch in the stream. I think that VDR should regularly check and resync the audio to the video, if it doesn't already. If it does, then there is a problem in the process as it gets it wrong. Regards, Morfsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can xineliboutput and dxr3 coexist?
In <[EMAIL PROTECTED]>, Glyn Edwards wrote: > Streamdev isn't quite what I want since you need a whole vdr install on > the client as well. ISTR you can connect directly with MPlayer or Xine by streaming HTTP and part of the URL tells it which channel to select. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR deletes directories
hi klaus i run a plain-vanilla vdr (1.4.3) now and all those empty directories are gone. so it's definetly NO BUG in vdr. i assume it's bigpatch's fault. :( regards hannes Johannes Schoeller wrote: Matthias Fechner wrote: Hi, I have the problem that VDR deletes directories in my /video0 or /video1 ... which not belongs to VDR. I use vdrconvert to convert my VDR recordings to DVDs so I have a directory /video1/filme which VDR deletes and vdrconvert breaks. Is it possible to deny the delete of this directory? (vdr is running as root here) Best regards, Matthias i wish vdr would delete .del directories ;) here it doesn't clean up emtpy directories. never found out why. so i made a cronjob that does that for me ... regards hannes ___ 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
C.Y.M wrote: mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem. Definitely not just that. My playback issue already disappears when using the most simple command line: mplayer -vo mpegpes -ao mpegpes 001.vdr. And just for completeness: No serious CPU load when playing back with VDR or mplayer. 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
Morfsta wrote: Certainly I think the problem is that VDR is not properly doing sync, In a way, I agree. VDR does not sync at all. Never. Simplified, here's what the VDR playback really does: - Read data from file in frame-sized chunks into read buffers - If the DVB driver accepts data, read a frame from buffers - Filter the PES packets for current video and audio track - Write the packets into the DVB device. Thats all. VDR just delivers the data stream as fast as the DVB device accepts it. The DVB devices do all the syncing and timing. And thats why I think that this is a firmware issue, not a VDR issue, simply because VDR does almost nothing to the video. 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
In <[EMAIL PROTECTED]>, Udo Richter wrote: > Thats all. VDR just delivers the data stream as fast as the DVB device > accepts it. The DVB devices do all the syncing and timing. > > And thats why I think that this is a firmware issue, not a VDR issue, > simply because VDR does almost nothing to the video. But didn't the people experiencing the problem say it works OK with mplayer, but not VDR, everything else being equal? So perhaps the problem is that VDR isn't doing anything whereas mplayer can detect potential problems and alter the stream somehow? I would suspect that the problem streams have the packets interleaved with quite a lot of delay between the video and audio. Normally a decoder should be able to correct that by reading PTS etc, but perhaps if VDR just feeds the stream as it encounters it to the DVB card it overwhelms its buffers whereas mplayer does its own buffering beforehand and presents packets to the decoder with the audio packets much closer to the video packets with the same PTS. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 21.10.2006 15.58, "Oliver Endriss" <[EMAIL PROTECTED]> wrote: > Udo Richter wrote: >> Tero Siironen wrote: >>> However, like Pasi Juppo told earlier in other thread, in last weeks episode >>> of Lost there was many fadeout-fadeins between scenes and a/v desync >>> happened on every one of these. >> >> I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade >> into black, the data stream seems to get stuck, frames get delayed, and >> as consequence A/V desyncs and playback gets jerky, with lots of audio >> and video frame drops. This can be fixed by pausing and jumping a few >> frames backwards. >> >> My theory is that since audio is typically 600ms ahead of video, maybe >> the audio buffers run over. Strange thing is why this happens >> reproducible on blackness. Maybe due to extremely low bit rate in this >> situation, more frames get packed into one data block, causing data flow >> to be disturbed beyond some limit. It cant be too high data rate, ATV+ >> has just 2mbit avg, 4mbit max data rate. > > Does it also occur with the latest test firmware? > http://www.suse.de/~werner/test_av-f22623.tar.bz2 > > If yes, please provide short sample clips. > Please verify that the clips are not damaged, i.e. they play fine with > mplayer or xine. > > Oliver 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 -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can xineliboutput and dxr3 coexist?
> ISTR you can connect directly with MPlayer or Xine by streaming HTTP and > part of the URL tells it which channel to select. True, but as far as I'm aware, you can't access recordings and FFwd and Rwd etc... Thanks for the pointer though Glyn > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Adding my 2 cents, in the hope that others more knowledgable may be able to reproduce the problem. Using a Nexus S 2.1 with the latest beta firmware, I find I lose audio sync when doing multiple "yellow button skips" to jump through commercial breaks, where there is a 30-50% chance the audio will be out after this. Doing a "green button skip" backwards almost always corrects it. Regards, Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
The way I understand it, the shows are sent as mpeg2, VDR decodes to raw data and stores as xxx.vdr files? which then need a special player that dosn't seem to work correctly to play these now much larger files which eat up a lot more space. So why not store them as mpeg files? A more common format which seems to have more options to play back and which work better? What format do DVD's use? What do you gain by converting to xxx.vdr aside from not needing to decode on playback? Which would be an advantage if the system worked and it didn't requre more complexities to convert back to mpeg for recording to a dvd. Also mpeg is a lossy compression, so data is lost converting back and forth. - Original Message - From: "C.Y.M" <[EMAIL PROTECTED]> To: "VDR Mailing List" Sent: Friday, October 20, 2006 5:14 PM Subject: Re: [vdr] FF card A/V sync suggestion > Juri Haberland wrote: > > Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > >> C.Y.M wrote: > >>> Since it has been several years now and I have never been able to solve the a/v > >>> desync issues with my Nexus-S FF card when playing back recordings... > >> I'm replaying many recordings (actually most of what I watch > >> are recordings ;-) and don't even remember when was the last > >> time I had an A/V desync. > > ___ 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: > C.Y.M wrote: >> mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc >> -quiet 001.vdr >> >> Notice that "-framedrop" is added to the command line. I wonder if >> that is the >> reason why mplayer is "immune" to the a/v desync problem. > > Definitely not just that. My playback issue already disappears when > using the most simple command line: mplayer -vo mpegpes -ao mpegpes > 001.vdr. > > And just for completeness: No serious CPU load when playing back with > VDR or mplayer. > Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end. Thanks everyone for chiming in on this one. I really hope that this time we can stop passing the buck and just git'r done. :) Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 22 Oct 2006, at 22:56, C.Y.M wrote: Torgeir Veimo wrote: On 22 Oct 2006, at 22:33, C.Y.M wrote: And just for completeness: No serious CPU load when playing back with VDR or mplayer. Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end. The reason i mentioned the dvbplayer.c thread, is that this problem was mitigated by using different code to feed the softdevice mpeg2 decoder; using softplay to playback recordings provided dropout free playback. I'm not sure if softplay works with FF cards, but you might get the source at softdevice.berlios.de to give it a try. I use xine with my FF card and it works flawlessly and fixes all my problems, but since I never had trouble with the FF card when just watching live TV, I thought it was such a waste of CPU to have to use software decoding for everything. I only have problems when playing back recordings with the FF card. I wasn't talking about using different decoding software, I was talking about trying some other piece of code thant dvbplayer.c to read the recording from disk and feeding the hardware decoder. The softplay plugin is such a different playback mechanism (but I can't guarrantee that it works with an FF card). My thesis is that there are issues with dvbplayer.c, which only show under certain circumstances. One such ciscumstance is using a budget card with softdevice playback of recordings, and a powerfull cpu. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Hi, Timothy D. Lenz wrote: The way I understand it, the shows are sent as mpeg2, VDR decodes to raw data and stores as xxx.vdr files Now vdr file are raw data sent by the card : ie mpeg2. Have you an idea of the size of uncompressed video ? Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] desperated with vdr-burn
Hi and thanks for your answer. I'm using debian etch and always compile vdr and plugins myself. I see e-tobi is sarge. I will look for a etch e-tobi repository but... is there any problem in compile vdr myself and install vdr plugins packages? Thanks. Tobias Grimm escribió: Leo Márquez wrote: Finally I'm desperated with vdr-burn. Few days ago I exposed my problem but seems that I'm the one person that experience it. At least one person at the German vdrportal.de seems to have the same problem (but no solution yet): http://www.vdr-portal.de/board/thread.php?postid=529179#post529179 If you're using Debian, please try the burn package from here: deb-src http://e-tobi.net/vdr-experimental sarge vdr It works fine with Sarge. It would help much, if you could provide a core dump or backtrace. Tobias PS: A Debian ProjectX package is available here: deb-src http://e-tobi.net/vdr-experimental sarge base PPS: the burn plugin has it's own bug tracker: http://vdr-developer.org/mantisbt/main_page.php ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr __ Información de NOD32, revisión 1.1823 (20061022) __ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] desperated with vdr-burn
Hi, Finally I'm desperated with vdr-burn. Few days ago I exposed my problem but seems that I'm the one person that experience it. The problem is boost related: terminate called after throwing an instance of 'boost::io::too_many_args' what(): boost::too_many_args: format-string refered to less arguments than were passed Avortat I have tried the libboost debian package and the boost-for-burn that readme says. Is there any boost expert that can explain my problem? I can't believe that anyone known this problem. I have recompiled vdr and plugins many times. I'm desperated with this problem amb my hard disk is full. my vdr is 1.4.3 burn is cvs (I have tried it with pre-20 and pre-21 versions) Thanks for your help. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] desperated with vdr-burn
Leo Márquez wrote: > Finally I'm desperated with vdr-burn. Few days ago I exposed my > problem but seems that I'm the one person that experience it. At least one person at the German vdrportal.de seems to have the same problem (but no solution yet): http://www.vdr-portal.de/board/thread.php?postid=529179#post529179 If you're using Debian, please try the burn package from here: deb-src http://e-tobi.net/vdr-experimental sarge vdr It works fine with Sarge. It would help much, if you could provide a core dump or backtrace. Tobias PS: A Debian ProjectX package is available here: deb-src http://e-tobi.net/vdr-experimental sarge base PPS: the burn plugin has it's own bug tracker: http://vdr-developer.org/mantisbt/main_page.php ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 22 Oct 2006, at 22:33, C.Y.M wrote: And just for completeness: No serious CPU load when playing back with VDR or mplayer. Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end. The reason i mentioned the dvbplayer.c thread, is that this problem was mitigated by using different code to feed the softdevice mpeg2 decoder; using softplay to playback recordings provided dropout free playback. I'm not sure if softplay works with FF cards, but you might get the source at softdevice.berlios.de to give it a try. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: > > On 22 Oct 2006, at 22:33, C.Y.M wrote: > >>> >>> And just for completeness: No serious CPU load when playing back with >>> VDR or mplayer. >>> >> >> Yes, if the extra CPU load by mplayer is not even noticeable when >> playing back >> VDR recordings, and it is not prone to any type or desync, then I vote >> we all >> try to figure out what mplayer is doing and repeat it. Whats a few >> extra CPU >> cycles if it becomes much much more stable in the end. > > The reason i mentioned the dvbplayer.c thread, is that this problem was > mitigated by using different code to feed the softdevice mpeg2 decoder; > using softplay to playback recordings provided dropout free playback. > I'm not sure if softplay works with FF cards, but you might get the > source at softdevice.berlios.de to give it a try. > I use xine with my FF card and it works flawlessly and fixes all my problems, but since I never had trouble with the FF card when just watching live TV, I thought it was such a waste of CPU to have to use software decoding for everything. I only have problems when playing back recordings with the FF card. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
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 I've checked your recording. Lost "The other 48 days" - surely one of the worst episodes for me too, because the fade-to-black on every day break. Your recording however runs relatively fine on my FF (r1.6 firmware f22623) card. There's noticeable audio stuttering after the fade-to-black scenes, but audio desync is only small, though noticeable. Demultiplexing with ProjectX throws 11649 of errors like this: !> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / true / false) pos is changing, the rest seems always the same. I then re-muxed the elementary streams and converted them back to VDR, and the resulting video played fine again. So this issue seems to be some problem on the PES packaging layer. In contrast, my recording issue cannot be fixed by re-muxing, and has more noticeable audio desync, its probably a totally different issue. The dev's already have a sample file. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] desperated with vdr-burn
Leo Márquez wrote: > I'm using debian etch and always compile vdr and plugins myself. > I see e-tobi is sarge. I also have binaries for Sid so all source packages should compile on Etch as well. > is there any problem in compile vdr myself and install vdr plugins > packages? Probably not - but would have been easier to track down the problem, if we were using exactly the same sources. Tobias ___ 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: > 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 > > I've checked your recording. Lost "The other 48 days" - surely one of > the worst episodes for me too, because the fade-to-black on every day > break. > > Your recording however runs relatively fine on my FF (r1.6 firmware > f22623) card. There's noticeable audio stuttering after the > fade-to-black scenes, but audio desync is only small, though noticeable. > > Demultiplexing with ProjectX throws 11649 of errors like this: > > !> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / > true / false) > !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / > true / false) > > pos is changing, the rest seems always the same. > > I then re-muxed the elementary streams and converted them back to VDR, > and the resulting video played fine again. So this issue seems to be > some problem on the PES packaging layer. > > In contrast, my recording issue cannot be fixed by re-muxing, and has > more noticeable audio desync, its probably a totally different issue. > The dev's already have a sample file. > It is postulated that vdr takes whatever it gets and shoves it into the playback buffers of the a/v decoder in whatever order it is in. In live TV this is rate-limited meaning the clocking source is the network and the network transmits at whatever rate it needs to and the decoder decodes it. So, let us say that time is "x". If video is transmitted faster than rate "x", and audio also is transmitted faster than time "x", then we get a xrun. I think that's understood. But, if video is transmitted faster, then slower, then faster, then slower etc, but drifts around time "x", and is not sent to the decoder at any other speed than "x", then the decoder gets a constant smooth stream. Because if it takes x+3 ms to play something, the input stream on livetv won't overfill its buffer because the next run will be x-3 ms and so the extra time is made up. This is very easily seen with variable framerates and bitrates. Audio also might be doing the same thing, where it send at spurts rather than a steady stream. Now if audio and video are both spurting along, where do you find a common time? IRL, time is constant. But on playback if vdr doesn't clock its data, then desync is quite possible. For example, if there's nothing to "change" for a few video frames, because they're using "stack" compression they won't send an empty frame. So, consider this blackout time in "Lost". The theory is that problems are occurring because they're not sending empty null frames. Also, if they're clocking on video, not audio. You will get your sync problems because you're missing bits. Does VDR store the pcr pid in the recordings? Is the pcr used during playback to clock the data? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can xineliboutput and dxr3 coexist?
In <[EMAIL PROTECTED]>, Glyn Edwards wrote: > > ISTR you can connect directly with MPlayer or Xine by streaming HTTP and > > part of the URL tells it which channel to select. > True, but as far as I'm aware, you can't access recordings and FFwd and > Rwd etc... Both the above players can play vdr files. I mount my recordings directory over NFS. You can jump forwards and backwards, so not being able to ffwd or rew isn't too much of a problem. However, if you try to seek with the arrow keys in xine it always jumps to the beginning. The progress bar still works properly though; you can drag it. Seeking with the arrow or PgUp/Dn keys in MPlayer works, but the amount it jumps each time is a bit hit & miss. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
