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
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 op
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 t
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
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 o
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 disap
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
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
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
> 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
>
_
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 w
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
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
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
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
__
__ 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
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
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?posti
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 t
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
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
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 w
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
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
24 matches
Mail list logo
