On 6 November 2010 14:14, Udo Richter wrote:
> Am 03.11.2010 10:06, schrieb Theunis Potgieter:
>> I'm considering to upgrade my current p3 system to a hdmi/optical
>> SPDIF and enough expansion slots to fill in dvb-s devices.
>
>> The unkown factor for me is, should I
>> consider a motherboard whe
Hello,
how about moving to mplayer instead of xine-lib, is not maintained very well
any more?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 8 November 2010 13:59, lucian orasanu wrote:
> Hello,
>
> how about moving to mplayer instead of xine-lib, is not maintained very well
> any more?
>
>
My personal experience with mplayer is that it lacks proper aspect
ratio detection or guessing based on source that does not contain the
correc
On 2010-11-08 at 12:54 +0200, Theunis Potgieter wrote:
> On 6 November 2010 14:14, Udo Richter wrote:
> > AMD also supports vaapi, but progress is very slow, and its still very
> > buggy. Also, its limited to closed source drivers.
>
> Sounds similar to what nvidia went through.
AMD's progress h
On 08/11/10 12:50, Theunis Potgieter wrote:
On 8 November 2010 13:59, lucian orasanu wrote:
how about moving to mplayer instead of xine-lib, is not maintained
very well any more?
My personal experience with mplayer is that it lacks proper aspect
ratio detection or guessing based on source th
> But even with such unique numbers, an SVDRP client that accesses
> recordings or timers would still need to know whether the VDR instance
> it is communicating with has been restarted since the last time it
> fetched the list of timers/recordings.
It should keep the SVDRP connection open, then i
> should start at 1 and count up as it already does. Also, instead of
> changing the current numbering system, could using a hash provide you
> with the same result you're looking for? I would think hashing the
> first X MB of a recording would suffice to create a unique identifier.
If you want
