Re: [vdr] xine-lib and vaapi support

[Theunis Potgieter]

On 8 November 2010 17:02, Tony Houghton  wrote:
> 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 that does not contain the
>> correct info. xine-lib seems to handle this much better. Also
>> automatic cropping is a nice feature that works quite well in the
>> vdr-xineliboutput plugin (even with vdpau). Most people doesn't seem
>> to mind that the output is stretched or squeezed incorrectly, but I
>> do. I prefer it that a circle appears to be that and not in the
>> elliptical form.
>
> What??! You can tell mplayer the exact ratio of your monitor and the
> exact ratio of the video on the command line and it correctly calculates
> how to display it. vdr-sxfe and vdr-fbfe have an equivalent of
> -monitoraspect but xine-ui and gxine don't, or didn't last time I
> looked. Instead they query the display's dimensions from the X server,
> which often gives bogus information, or xine doesn't use the information
> correctly. For example, X thinks my Sony TV (1366x768 physically, but
> uses a 1360x768 native resolution, connected by HDMI), measures 16m x 9m
> (yes, metres!) so I override it with:

I was referring to the source and not to my output display.

>
> Section "Monitor"
>        Identifier      "32in TV"
>        #DisplaySize    708 398 # real size
>        DisplaySize     320 180 # lie to avoid tiny fonts
>        Option          "UseEdiDpi"     "false"
>        Option          "DPI"           "96 x 96"
>        Option          "DPMS"          "false"
> EndSection
>
> But when I tried xine it was OK windowed, while in full-screen mode it
> scaled and applied letterboxing as if for a 4:3 display for some reason
> :-(.
>
> With xine you can override the aspect ratio of the video stream too. It
> has the advantage over mplayer that you can do it on the fly, but the
> disadvantage that it only has a few presets with names that don't
> indicate what the aspect ratio actually is in numbers.
>
> --
> TH * http://www.realh.co.uk
>
> ___
> 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] Recordings Numbering

[Dominic Evans]

On 7 November 2010 15:05, Klaus Schmidinger  wrote:
>> It'd be preferable if recordings kept a unique number, that didn't
>> change when every time a recording gets deleted, or a new recording is
>> started.
>
> While this sounds feasible, it would also mean that the numbers
> would get larger and larger over time if VDR runs like 24/7.
> If this doesn't pose a problem to anybody, I could change this
> so that every recording an instance of VDR "sees" would get a
> unique number, by incrementing a static counter. These numbers would,
> of course, only be valid within one instance of VDR, and only as long
> as it actually runs. Once it restarts, the numbers would be reassigned
> starting at 1. The only question remaining would probably be what to
> do when the counter wraps over the integer boundary ;-)

This sounds like the behaviour I previously expected and I don't see
any problem with larger numbers.

Potentially the recordings and timers could all be renumbered to start
consecutively at zero on some regular schedule (e.g., daily), or via
some SVDRP call, (similar to what would happen in the event of a
restart) just as long as they don't change on every new timer or
recording.

As numbering sequentially would cause recordings to be numbered in
order of date/time, presumably the re-numbering that happened on
restart of VDR should also be changed to number them based on
date/time rather than alphabetical order?

Cheers,
Dom

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] UK users - multiple BBC One/Two/News in channels list

[Dominic Evans]

Hey Tony,

On 4 November 2010 12:59, Tony Houghton  wrote:
> I've written my own scanningtool, which handles Freesat LCNs too, which
> are supplied in the BAT instead of the NIT. This needs a bit of kludging
> because I don't understand how the regions are handled by STBs so I have
> to use manual overrides ("BBC 1 South" = 101 etc) and a bit of
> shuffling. Then I've got another script which combines my Freesat and
> Freeview listings, making sure the LCNs don't clash. It also merges the
> new data with an existing channels.conf so it can deal with channels
> like BBC THREE/FOUR time sharing with CBeebies/CBBC etc. Really VDR
> shouldn't scan and store PIDs, but get them when tuning.

Any chance you could put the source to this scanning tool on github or
something similar for others to play with?

Cheers,
Dom

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] UK users - multiple BBC One/Two/News in channels list

[Tony Houghton]

On 09/11/10 12:27, Dominic Evans wrote:

On 4 November 2010 12:59, Tony Houghton  wrote:

I've written my own scanningtool, which handles Freesat LCNs too, which
are supplied in the BAT instead of the NIT. This needs a bit of kludging
because I don't understand how the regions are handled by STBs so I have
to use manual overrides ("BBC 1 South" = 101 etc) and a bit of
shuffling. Then I've got another script which combines my Freesat and
Freeview listings, making sure the LCNs don't clash. It also merges the
new data with an existing channels.conf so it can deal with channels
like BBC THREE/FOUR time sharing with CBeebies/CBBC etc. Really VDR
shouldn't scan and store PIDs, but get them when tuning.


Any chance you could put the source to this scanning tool on github or
something similar for others to play with?


It's part of boxstard which is available by git from
. You'll
need scons and headers etc for libsqlite3 (the tool you need is a spin-
off from a bigger project) and glib to compile it. Then look at the scan
tool in the tools subdirectory (scan --help).

Is anyone interested in the other script I mentioned to merge Freeview
and Freesat channels files?


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] UK users - multiple BBC One/Two/News in channels list

[Dominic Evans]

> Is anyone interested in the other script I mentioned to merge Freeview
> and Freesat channels files?

Yes, that too please :-)

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Recordings Numbering

[Matthias Wächter]

Am 09.11.2010 13:19, schrieb Dominic Evans:
> Potentially the recordings and timers could all be renumbered to start
> consecutively at zero on some regular schedule (e.g., daily), or via
> some SVDRP call, (similar to what would happen in the event of a
> restart) just as long as they don't change on every new timer or
> recording.

You just re-introduce the old problem. Don't ever re-number. If you
don't renumber any SVDRP client can be safe in assuming for (nearly) any
time span to mean the same recording as the server when it updates a
recording's schedule.

Assume a whoppin' 100.000 recordings a day which is more than one per
second. If the recording ID is limited to 32 bits (not more, not less)
you can record for about 43.000 days or 117 years without an overflow.

Let's say you record 100 times that number of recordings, then you'd
overflow in 1.17 years. This _can_ be an issue for permanent (repeating)
recordings, so maybe one could reserve a part of the available space for
permanent recordings so that one never ever gets a collision, not even
in times of wrap-around.

> As numbering sequentially would cause recordings to be numbered in
> order of date/time, presumably the re-numbering that happened on
> restart of VDR should also be changed to number them based on
> date/time rather than alphabetical order?

To repeat myself: Don't ever re-number. Any UI tool should hide the
record ID as it is just a reference link between the applications UI and
VDR running in parallel. Make the ID unique and you will never again see
two clients in parallel deleting the wrong recordings because of
renumbering, or a single client deleting a recording while another
recording was finished, triggering renumbering as well.

- Matthias

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] UK users - multiple BBC One/Two/News in channels list

[Tony Houghton]

On 09/11/10 15:22, Dominic Evans wrote:

Is anyone interested in the other script I mentioned to merge Freeview
and Freesat channels files?


Yes, that too please :-)


I've uploaded it to . It's actually
a python script, but I changed it to .txt to make sure the server
doesn't get confused and try to run it. You'll probably need to change
the SCAN_BIN and OLD_CHANS variables near the top of the file, and the
scan command arguments in Scan2Vdr.__init__() on lines 129-134.

It can also be altered to read the new scan data from files instead of
running the scans itself. IIRC all you should need to do is remove the
references to dvbt_threads and dvbs_threads from Scan2Vdr.__init__() and
unquote and edit the lines beginning with fp.

It creates a new channels.conf in the current directory.

--
TH * http://www.realh.co.uk

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Recordings Numbering

[Olaf Titz]

> Potentially the recordings and timers could all be renumbered to start
> consecutively at zero on some regular schedule (e.g., daily), or via

Renumbering would defeat the purpose of keeping the numbers constant ;-)

With just 8 digits for the ID, you could do 1000 recordings a day and
still not overflow the number space in over 270 years. Or more
realistically: over a lifespan of 10 years, a VDR instance would reach
five-digit numbers only with at least three recordings daily, and
six digits with 27 recordings daily.

Olaf

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Recordings Numbering

[Marco Göbenich]

Hi!

On a customers system VDR did 223.402 rcecordings since 25.10.2005, 
maybe some more, that where not recorded into the database. And the 
system runs since October 2004.

Today VDR records 140 timers and round about 400 GB a day.

I would vote for all time unique id's for timers and recordings. This 
would make many things easier.


Regards

Marco


Am 09.11.2010 20:21, schrieb Olaf Titz:

Potentially the recordings and timers could all be renumbered to start
consecutively at zero on some regular schedule (e.g., daily), or via

Renumbering would defeat the purpose of keeping the numbers constant ;-)

With just 8 digits for the ID, you could do 1000 recordings a day and
still not overflow the number space in over 270 years. Or more
realistically: over a lifespan of 10 years, a VDR instance would reach
five-digit numbers only with at least three recordings daily, and
six digits with 27 recordings daily.

Olaf

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



--
Needful GbR  Rheinstraße 60a  Telefon +49 (0) 26 24 / 95 29 301
 56203 Hoehr-Grenzhausen  Telefax +49 (0) 26 24 / 95 29 303
 http://www.needful.deE-Mail  m...@needful.de


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Recordings Numbering

[Udo Richter]

Am 09.11.2010 16:35, schrieb Matthias Wächter:
> You just re-introduce the old problem. Don't ever re-number. If you
> don't renumber any SVDRP client can be safe in assuming for (nearly) any
> time span to mean the same recording as the server when it updates a
> recording's schedule.

In other words, store the unique ID in the info file permanently, right?
What happens if two VDR instances write to the same video directory?
What if you download a recording from a friend? In that case you might
have two recordings with the same ID. How should that be handled?

Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr