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
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] 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 vdr@linuxtv.org 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
[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] 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] 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] 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
