Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[Nicolas Huillard]

Le mercredi 10 février 2016 à 16:19 -0800, VDR User a écrit :
> Gerald,
> 
> You freak out because I suggested an easier solution to yours, and
> then call me a troll for correcting you on your own nonsense. I hope
> you don't think you're fooling anyone with that fake b.s. Take your
> temper tantrums somewhere else, or get lost.
> 
> ==
> 
> Nicolas,
> 
> Sorry your thread got polluted with this garbage. Gerald has a history
> of lashing out at people who disagree with him or have any criticism
> about yavdr. It's pathetic but hopefully in all the nonsense you've
> found a solution that suits you.

Wow... I didn't follow that thread, because of lack of time. I'm sorry
it went that way.
I have noted down a bunch of things to try though, and I'll hopefully
keep you informed when I'm done...

-- 
NH


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

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[Nicolas Huillard]

Le mardi 09 février 2016 à 11:35 +0100, Gerald Dachs a écrit :
> Am 2016-02-09 10:43, schrieb Nicolas Huillard:
> > Le mardi 09 février 2016 à 10:33 +0100, Gerald Dachs a écrit :
> >> Am 2016-02-09 10:19, schrieb Nicolas Huillard:
> >> > Hi all,
> >> >
> >> > My new Raspberry Pi2 install lacks a media player, which begins to be a
> >> > bit annoying. The current setup :
> >> > * NFS server
> >> > * DigitalDevices Octopus Net DVB network server
> >> > * VDR + rpihddevice + satip on the Pi2 : live TV, timers, recordings,
> >> > etc.
> >> 
> >> IMHO OpenELEC covers all your needs and is still lightweight.
> > 
> > As I understand OpenELEC, it is a lightweight Kodi (XBMC) distro, which
> > by definition gets VDR out of the way.
> 
> No, that is not true. I even helped to better integrate VDR into 
> OpenELEC.

I meant that Kodi becomes the main interface, with a VNSI/PVR client
add-on, while the VDR instance will remain (in my case) on the headless
server, with a limited or non-existing UI.

Will the current stable Kodi 15.2 include your work ? Any specific
advice on how to have this kind of setup running ?

Many thanks !

-- 
NH


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

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[Nicolas Huillard]

Le mardi 09 février 2016 à 10:33 +0100, Gerald Dachs a écrit :
> Am 2016-02-09 10:19, schrieb Nicolas Huillard:
> > Hi all,
> > 
> > My new Raspberry Pi2 install lacks a media player, which begins to be a
> > bit annoying. The current setup :
> > * NFS server
> > * DigitalDevices Octopus Net DVB network server
> > * VDR + rpihddevice + satip on the Pi2 : live TV, timers, recordings,
> > etc.
> 
> IMHO OpenELEC covers all your needs and is still lightweight.

As I understand OpenELEC, it is a lightweight Kodi (XBMC) distro, which
by definition gets VDR out of the way.
I'd like to keep VDR and avoid other things for various reasons (I'll
try OpenELEC on some spare SD card though).

-- 
NH


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

[vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[Nicolas Huillard]

Hi all,

My new Raspberry Pi2 install lacks a media player, which begins to be a
bit annoying. The current setup :
* NFS server
* DigitalDevices Octopus Net DVB network server
* VDR + rpihddevice + satip on the Pi2 : live TV, timers, recordings,
etc.
* an old VDR instance on the NFS server plays MKV media (using
xinelibouput), but lacks satip (no timers, no live TV anymore)

I will upgrade the old VDR to act as a headless epg/timer/recording
server. I will thus be unable to play the MKV media on it (headless).

What's the recommended light way to play MKV videos on the Pi2 from
within VDR ?
Adding XBMC on the Pi2 seems a bit too heavy.
The mplayer plugin seem very old and may not work neatly with the
rpihddevice output.
Maybe simply moving the MKV files inside the recordings tree, and
creating a vdr index for each work in some way.

(I use the MLD distribution (http://www.minidvblinux.de/) on the Pi2,
but the forums are all in german, which is a real problem for me...)

TIA,

-- 
NH


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

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[Nicolas Huillard]

Le mardi 09 février 2016 à 11:24 +0100, tho...@reufer.ch a écrit :
> Quoting Nicolas Huillard <nico...@huillard.net>:
> 
> > The mplayer plugin seem very old and may not work neatly with the
> > rpihddevice output.
> 
> As I understand the mplayer plugin, it just launches an external  
> player - this won't work on the Raspberry Pi. But technically  
> speaking, it shouldn't be that hard to write a plugin which browses  
> through mkv files, reads them and passes the packets to VDR's output  
> device by implementing a dedicated player class. But that's probably  
> not the way you asked. ;-)

I wonder why this kind of plugin does not exists since all these
years... The need and skills seem to be here. Unfortunately, I won't be
able to do this.
I'll check mplayer + omxplayer though.

> > Maybe simply moving the MKV files inside the recordings tree, and
> > creating a vdr index for each work in some way.
> 
> Personally I convert mkv files to VDR recordings. Since you don't need  
> to reencode anything this is quite fast and easy and you'll get all  
> the comfort you're used from VDR. This even works for BD rips on the  
> Raspberry, including subtitles and DTS sound tracks.

Can you please elaborate a bit on how you convert mkv to VDR ts ? I see
a 2011 thread on a related topic, but tools may have evolved since
then ;-)

Thanks for your answer !

-- 
NH


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

Re: [vdr] Raspberry Pi, satip, MLD

[Nicolas Huillard]

Le dimanche 25 octobre 2015 à 12:04 +0100, Klaus Schmidinger a écrit : 
> On 10/25/15 11:44, Nicolas Huillard wrote:
> > Hi all,
> >
> > I still have a problem with my new setup:
> > * Raspberry Pi B (256MB system + 256MB video)
> > * MLD 5.0.0 testing distribution (http://www.minidvblinux.de/) on a 4GB
> > class 6 SD card, using VDR 2.2.0.203-207
> > * vdr-plugin-rpihddevice (from MLD 1:2015.08.24-37+2.2.0.203)
> > * Octopus Net (firmware 1.0.55) : Linux VLC shows TV channels without
> > problems
> > * vdr-plugin-satip (from MLD 2015.09.19-20+2.2.0.203)
> > * recordings on an NFS share (works for playing, didn't test recording)
> > * the Raspberry is powered from one of the 5V output from the Octopus,
> > which provides enough power for the CI interface, which seems
> >
> > Playing live TV works great, until some point a few dozen minutes later,
> > where some errors start to appear in /var/log/messages:
> >
> > ...
> 
> I strongly suggest you use the newer Raspberry Pi 2 model.
> I have two of these in operation, and they work like a charm.
> Before that I also experimented with the model 1, but had
> similar problems as you described.

I know have an RPi2 installed since a few days, which works great. It
can almost record 3 channels and view a 4th one, everything from the
network (SAT>IP to get DVB streams, NFS for remote storage).
I may change my mind and get back to a single VDR instance, without
client/server (the RPi 1 was not meant to record anything, relying on
remote timers).

Thanks Klaus !

-- 
NH


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

[vdr] Raspberry Pi, satip, MLD

[Nicolas Huillard]

Hi all,

I still have a problem with my new setup:
* Raspberry Pi B (256MB system + 256MB video)
* MLD 5.0.0 testing distribution (http://www.minidvblinux.de/) on a 4GB
class 6 SD card, using VDR 2.2.0.203-207
* vdr-plugin-rpihddevice (from MLD 1:2015.08.24-37+2.2.0.203)
* Octopus Net (firmware 1.0.55) : Linux VLC shows TV channels without
problems
* vdr-plugin-satip (from MLD 2015.09.19-20+2.2.0.203)
* recordings on an NFS share (works for playing, didn't test recording)
* the Raspberry is powered from one of the 5V output from the Octopus,
which provides enough power for the CI interface, which seems

Playing live TV works great, until some point a few dozen minutes later,
where some errors start to appear in /var/log/messages:

Oct 25 10:51:59 vdrpi user.err vdr: [17414] ERROR: 1 ring buffer overflow (940 
bytes dropped)
Oct 25 10:52:01 vdrpi user.info vdr: [17414] SATIP: Detected 1 RTP packet 
errors [device 0]
Oct 25 10:52:05 vdrpi user.err vdr: [17414] ERROR: 496 ring buffer overflows 
(652736 bytes dropped)
Oct 25 10:52:11 vdrpi user.err vdr: [17414] ERROR: 584 ring buffer overflows 
(768544 bytes dropped)
Oct 25 10:52:17 vdrpi user.err vdr: [17414] ERROR: 584 ring buffer overflows 
(768544 bytes dropped)
Oct 25 10:52:23 vdrpi user.err vdr: [17414] ERROR: 580 ring buffer overflows 
(763280 bytes dropped)
Oct 25 10:52:28 vdrpi user.err vdr: [17413] rpihddevice: [libav] Header missing
Oct 25 10:52:28 vdrpi user.err vdr: [17413] rpihddevice: failed to decode audio 
frame!
Oct 25 10:52:31 vdrpi user.err vdr: [17426] ERROR: TS packet not accepted in 
Transfer Mode
Oct 25 10:52:31 vdrpi user.debug vdr: [17413] rpihddevice: set HDMI audio 
output format to 2ch PCM, 48.0kHz
Oct 25 10:52:38 vdrpi user.err vdr: [17426] ERROR: TS packet not accepted in 
Transfer Mode
Oct 25 10:52:38 vdrpi user.debug vdr: [17413] rpihddevice: set HDMI audio 
output format to 2ch PCM, 48.0kHz

Some earlier errors were:

Oct 24 18:02:59 (none) user.err vdr: [11447] SATIP-ERROR: Connection timeout - 
retuning [device 1]
Oct 24 18:03:00 (none) user.err vdr: [11442] ERROR: 584 ring buffer overflows 
(768544 bytes dropped)
Oct 24 18:03:04 (none) user.err vdr: [11447] SATIP-ERROR: Connection timeout - 
retuning [device 1]
Oct 24 18:03:06 (none) user.err vdr: [11442] ERROR: 584 ring buffer overflows 
(768544 bytes dropped)

Those errors lasted for hours, until I stopped VDR. It's usually not
fixed until I power cycle the pi.

I don't know were to look from here. Options are:
* the satip plugin may not be the latest one (but the version number is
unclear and the MLD forum is all german-speaking, which is a problem for
me)
* the ethernet interface may miss packets even though it does not report
any packet loss (I changed the cable -quality and length- without
success)
* the power provided to the rpi may be enough, but I don't know about
temperatures (the video core reports 54°C, but the ethernet chip may be
too hot)
* maybe the Octopus does not provide a proper stream, or the problem
comes from the VDR core or the rpihddevice output...

Since I'm new to rpihddevice, satip and MLD, and didn't stress previous
Raspberry Pïs before, even though I use VDR since a dozen years at
least, I'm really lost here.

Latest test: a few second after switching some channel, the image froze,
sound looped, and the pi was not reachable anymore through SSH, even
though the octopus still reported the live stream and the network LEDs
on the pi was still blinking. Hardware problem, network driver problem ?

TIA,

-- 
NH



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

Re: [vdr] Raspberry Pi, satip, MLD

[Nicolas Huillard]

Le dimanche 25 octobre 2015 à 12:04 +0100, Klaus Schmidinger a écrit : 
> On 10/25/15 11:44, Nicolas Huillard wrote:
> > Hi all,
> >
> > I still have a problem with my new setup:
> > * Raspberry Pi B (256MB system + 256MB video)
> > * MLD 5.0.0 testing distribution (http://www.minidvblinux.de/) on a 4GB
> > class 6 SD card, using VDR 2.2.0.203-207
> > * vdr-plugin-rpihddevice (from MLD 1:2015.08.24-37+2.2.0.203)
> > * Octopus Net (firmware 1.0.55) : Linux VLC shows TV channels without
> > problems
> > * vdr-plugin-satip (from MLD 2015.09.19-20+2.2.0.203)
> > * recordings on an NFS share (works for playing, didn't test recording)
> > * the Raspberry is powered from one of the 5V output from the Octopus,
> > which provides enough power for the CI interface, which seems
> >
> > Playing live TV works great, until some point a few dozen minutes later,
> > where some errors start to appear in /var/log/messages:
> >
> > ...
> 
> I strongly suggest you use the newer Raspberry Pi 2 model.
> I have two of these in operation, and they work like a charm.
> Before that I also experimented with the model 1, but had
> similar problems as you described.

Well, thank you Klaus.
That advice aligns with what I figured out this morning, reading,
comparing and rebooting the Pi many times.

-- 
NH


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

Re: [vdr] DVB-T2 device in France

[Nicolas Huillard]

Le lundi 28 septembre 2015 à 18:30 +0200, fnu a écrit : 
> ok, two points just for my couriousity.
> 
> 1. Why don't you share channels.conf from your server as you do it with EPG 
> data?

I did, but this channel.conf is very old, and lack some channels. I
wanted to take the chance to update it. It's strange that I never
managed to have it up to date though (even with the old existing
server), so it must be me somehow...

> 2. Why don't you enable EPG scan just for a few hours for the channels scan 
> and delete epg.data afterwards again?

I'll do that ASAP...
IIRC, I may have disabled EPG scan because EPG is awful in France, and
more so on terrestrial... I have EPG downloaded from the web instead.

-- 
NH


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

Re: [vdr] DVB-T2 device in France

[Nicolas Huillard]

Le lundi 28 septembre 2015 à 12:55 +0200, fnu a écrit :
> per specs channel scan is not inteded for the SAT>IP servers, this is
> client's responsibility.

I fully understand this point, but since the Octopus has a web interface
and apparently also acts as a DLNA DMS, I think it could be a nice
addition to have at least basic channel scanning, just to provide a
smoother starting with the device (which is neally neat in every other
aspects).

> VDR doesn't provide an active channel scan option, so don't blame and
> point just the plugin, which does run awesome stable here since spring
> 2014.

I don't "blame" anything, and I trust that plugin to work flawlessly. I
still have power supply issues on the Raspberry Pi which masks all that
stability ;-)
As of now, this is a task for the soldering iron.

> VDR does provide a passive channel scan, only caveat you need at least
> one working line in channels.conf. If you have that, go to OSD /
> Setup / DVB and set "Update channels:" to "add new
> transponders" (setup.conf / UpdateChannels = 5). After some time of
> patience you should find a properly filled channels.conf, ready to be
> sorted.

That's what I tried, with the channel.conf I have from the VDR server,
but it didn't catch newer channels, even though "some time" was a day or
two.
I suspect this is something related to MANUAL.gz stating "Note that
adding new transponders only works if the "EPG scan" is active.", and
the fact that EPG is currently meant to be shared from the VDR server,
and apparently not working... Even UpdateChannels = 4 didn't add
anything.

I'll deal with this and bother the ML if I can't manage it ;-)

> Cheers
> Frank
> 
> -Ursprüngliche Nachricht-
> Von: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] Im Auftrag von 
> Nicolas Huillard
> Gesendet: Montag, 28. September 2015 12:18
> An: VDR Mailing List <vdr@linuxtv.org>
> Betreff: Re: [vdr] DVB-T2 device in France
> 
> Thanks for all your answers !
> 
> I finally opted for the Digital Devices Octopus Net, which DVT-T2 tuners are 
> equipped with Sony D2837ER demodulators, which happen to completely solve the 
> bad reception issue. Great !
> 
> Now I have a whole new set of problems : SAT>IP (with the satip plugin which 
> seems to be great, and channel scan which is as of now non-solved ; too bad 
> the Octopus couldn't channel-scan by itself and provide an initial 
> channel.conf or VLC playlist) and Raspberry Pi client which is a bit tricky 
> (power issues, media player, disappointingly weak CEC support on the TV side, 
> etc...).
> 
> At least, I can upgrade the VDR server without breaking the DVB kernel 
> drivers, and upgrade the VDR client without breaking X.org or xinelib ;-)
> 
> Le lundi 21 septembre 2015 à 15:37 +0100, Stuart Morris a écrit : 
> > I have a 290e I use for DVB-T2 reception and it has worked really well 
> > for some time now.
> > Shame you can't buy them anymore :-(
> > 
> > On 19 September 2015 at 10:21, Jari Fredriksson <ja...@iki.fi> wrote:
> > 
> > > On 17.9.2015 15:01, Nicolas Huillard wrote:
> > >
> > >> Hello all,
> > >>
> > >> My previous mail to this ML is apparently dated 2011 ;-) Everything 
> > >> was OK there since then... Except that my Hauppauge Nova-T-500 died 
> > >> recently, and my ancient PCI cards do not work in the 2013 server.
> > >>
> > >> I'm looking for advice for a new DVB-T2 device, which should :
> > >> * have a good tuner, because some channels (transponders, ie.
> > >> frequencies) are difficult to catch here ; the TV set (Panasonic) 
> > >> works perfectly well, and I've added an RF amplifier on the roof, 
> > >> so I guess the Nova-T-500 tuner was not good enough
> > >> * have a PCI or preferably PCI-e bus, and dual tuner (I don't 
> > >> really like USB sticks, which tend to lead to a mess of cable)
> > >> * be robustly supported with stock kernels in Debian (jessie and 
> > >> future), which does not seem to be a problem anymore...
> > >>
> > >> If there are some dual-tuner, DVB-T2 + S2 card out there which are 
> > >> well supported by VDR, that's OK too. I may prefer to add another 
> > >> DVB-S2 card later on though (there is no sat-dish on the roof yet).
> > >>
> > >> TIA !
> > >>
> > >
> > >
> > > I use an USB tuner "PCTV Systems nanoStick T2 290e" from Hauppauge. 
> > > It has a good Sony tuner, and DVB-T2 in my setup works fine even 
> > > with an desktop antenna (the broadcast mast is in vis

Re: [vdr] DVB-T2 device in France

[Nicolas Huillard]

Thanks for all your answers !

I finally opted for the Digital Devices Octopus Net, which DVT-T2 tuners
are equipped with Sony D2837ER demodulators, which happen to completely
solve the bad reception issue. Great !

Now I have a whole new set of problems : SAT>IP (with the satip plugin
which seems to be great, and channel scan which is as of now
non-solved ; too bad the Octopus couldn't channel-scan by itself and
provide an initial channel.conf or VLC playlist) and Raspberry Pi client
which is a bit tricky (power issues, media player, disappointingly weak
CEC support on the TV side, etc...).

At least, I can upgrade the VDR server without breaking the DVB kernel
drivers, and upgrade the VDR client without breaking X.org or
xinelib ;-)

Le lundi 21 septembre 2015 à 15:37 +0100, Stuart Morris a écrit : 
> I have a 290e I use for DVB-T2 reception and it has worked really well for
> some time now.
> Shame you can't buy them anymore :-(
> 
> On 19 September 2015 at 10:21, Jari Fredriksson <ja...@iki.fi> wrote:
> 
> > On 17.9.2015 15:01, Nicolas Huillard wrote:
> >
> >> Hello all,
> >>
> >> My previous mail to this ML is apparently dated 2011 ;-) Everything was
> >> OK there since then... Except that my Hauppauge Nova-T-500 died
> >> recently, and my ancient PCI cards do not work in the 2013 server.
> >>
> >> I'm looking for advice for a new DVB-T2 device, which should :
> >> * have a good tuner, because some channels (transponders, ie.
> >> frequencies) are difficult to catch here ; the TV set (Panasonic) works
> >> perfectly well, and I've added an RF amplifier on the roof, so I guess
> >> the Nova-T-500 tuner was not good enough
> >> * have a PCI or preferably PCI-e bus, and dual tuner (I don't really
> >> like USB sticks, which tend to lead to a mess of cable)
> >> * be robustly supported with stock kernels in Debian (jessie and
> >> future), which does not seem to be a problem anymore...
> >>
> >> If there are some dual-tuner, DVB-T2 + S2 card out there which are well
> >> supported by VDR, that's OK too. I may prefer to add another DVB-S2 card
> >> later on though (there is no sat-dish on the roof yet).
> >>
> >> TIA !
> >>
> >
> >
> > I use an USB tuner "PCTV Systems nanoStick T2 290e" from Hauppauge. It has
> > a good Sony tuner, and DVB-T2 in my setup works fine even with an desktop
> > antenna (the broadcast mast is in visible range though).
> >
> > Driver is in kernel, and this was the first Linux tuner for DVB-T2 and
> > supported even in the older kernels. I use it in a Raspberry Pi 2 with two
> > DVB-C tuners and I'm all happy.
> >
> >
> > --
> > jarif.bit
> >
> > ___
> > 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

-- 
Nicolas Huillard
nico...@huillard.net
Fixe : +33 9 52 31 06 10
Mobile : +33 6 50 27 69 08

http://www.350.org/


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

Re: [vdr] DVB-T2 device in France

[Nicolas Huillard]

Le vendredi 18 septembre 2015 à 10:21 +0100, Morfsta a écrit : 
> On Thu, Sep 17, 2015 at 8:58 PM, Karim  wrote:
> > I use TBS6280 (dual tuner, pci-e) from Turbosight in dvb-t mode (no dvb-t2
> > signal here): good card, not expensive and great technical support. Newer
> > model is TBS 6281 :
> >
> > http://www.linuxtv.org/wiki/index.php/TBS6281
> 
> I have the TBS6281 and have found that the drivers from TBS are a pain to
> get co-existing at the same time with other kernel DVB drivers (e.g. my
> Prof USB DVB-S2 device) and need re-installing after every kernel update.
> Also, I think that the open source drivers do not support DVB-T2.
> 
> However, on the positive side once the driver is installed, the card is
> stable.

Thank you for your answers. Any information regarding the signal
reception quality ?

I was also pondering Digital Devices Octopus NET (rack version suits me)
http://www.digital-devices.eu/shop/en/networktuner/sets-und-bundles/208/dd-octopus-net-rack-ct2-dvbip-networktuner
This is expensive, but standalone with a webinterface, expandable (no
kernel drivers on the VDR side, just the satip plugin which seems to be
maintained).
http://www.saunalahti.fi/~rahrenbe/vdr/satip/

DVB-T/T2 sensitivity is "-82.6 dBm at 16 - QAM & 3/4", which I can't
compare to other cards (Nova-T-500 is only said to be "high
sensitivity").
http://download.digital-devices.de/download/octopus_net/Handbuch-DD-ONet_V111eng.pdf

Is Digital Devices worth the cost ?

-- 
NH


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

[vdr] DVB-T2 device in France

[Nicolas Huillard]

Hello all,

My previous mail to this ML is apparently dated 2011 ;-) Everything was
OK there since then... Except that my Hauppauge Nova-T-500 died
recently, and my ancient PCI cards do not work in the 2013 server.

I'm looking for advice for a new DVB-T2 device, which should :
* have a good tuner, because some channels (transponders, ie.
frequencies) are difficult to catch here ; the TV set (Panasonic) works
perfectly well, and I've added an RF amplifier on the roof, so I guess
the Nova-T-500 tuner was not good enough
* have a PCI or preferably PCI-e bus, and dual tuner (I don't really
like USB sticks, which tend to lead to a mess of cable)
* be robustly supported with stock kernels in Debian (jessie and
future), which does not seem to be a problem anymore...

If there are some dual-tuner, DVB-T2 + S2 card out there which are well
supported by VDR, that's OK too. I may prefer to add another DVB-S2 card
later on though (there is no sat-dish on the roof yet).

TIA !

-- 
NH


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

Re: [vdr] sxfe and vsync

[Nicolas Huillard]

Le jeudi 03 novembre 2011 à 20:57 +, Tony Houghton a écrit :
 On Thu, 03 Nov 2011 22:00:10 +0200
 prelude prel...@kapsi.fi wrote:
 
  This maybe help:
  http://lowbyte.de/vga-sync-fields/vga-sync-fields/README
 
 No, that's so you can slightly adjust the rate at which the display is
 refreshed to match the rate at which you're receiving the stream. That's
 a non-issue if you can't sync your frame changes to the refresh!

I have the same issue on SandyBridge (vdr 1.7.22-1~ctvdr2,
xineliboutput-sxfe 1.0.7+cvs20111211.1625-1).
Are there some news since then ?

-- 
NH


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

Re: [vdr] Wanted VDR xineliboutput client

[Nicolas Huillard]

Le vendredi 28 octobre 2011 à 11:24 +0100, Laz a écrit :
 I also suspect that I can run full vdr on the client to allow me to use 
 some plugins on there?! Not looked into that yet. I suspect I can probably 
 just use vdr-sxfe as a basic frontend, with lirc forwarding so I can 
 hide the server somewhere else...

That's kind of funny: my previous move was to put back the server near
the TV for practical reasons, rendering the client redundant. I thus
replaced the old server + client with a single box (inside a Silverstone
GD06 case, which fits quite neatly there).
vdr-sxfe still acts as a client lying on the same box, in order to
separate processing and presentation (there are still a few vdr-sxfe
crashes from time to time, and it's always good not to crash the server
while it's recording).

-- 
NH


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

Re: [vdr] Launching vdr + xineliboutput at startup

[Nicolas Huillard]

Le vendredi 28 octobre 2011 à 22:59 +0200, Damien Bally a écrit :
 I'm making some kind of embedded vdr distribution based on busybox and 
 minimal X11, the problem is I have no idea of how I can launch vdr and 
 xineliboutput at startup.

What I recently did, based on Debian + e-tobi + minimal X11 + vdr-sxfe:
* use nodm to auto-log-in and launch X11 (tweak /etc/default/nodm), and
relaunch in case of crash
* create a simple /var/lib/vdr/.xsession to run xcompmgr and vdr-sxfe
with proper options
* comment-out a few useless lines in /etc/X11/Xsession.options
* standard output and errors lies in /var/lib/vdr/.xsession-errors

-- 
NH


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

Re: [vdr] Wanted VDR xineliboutput client

[Nicolas Huillard]

Le lundi 17 octobre 2011 à 09:39 +0200, brian a écrit :
 Looks good. Any chance of underclocking, and getting it totally silent?

cpufreq minimum frequency is 1.6GHz for this Core i3 2100 (1.6-3.1 GHz).
I don't think one can underclock more than that. Maybe the BIOS can
lower voltage, thus heat generation, and lower fan speed a bit more.
I was afraid I'd have to limit CPU speed to, say, 2.5GHz, and reproduce
a real 2100T, but it never needs to go that far up, so it's good.
The fansink is behind a variator (Zalman fanmate), set to the lowest
speed. Too bad the motherboard cannot drive the fan with it's PWM
system, because it's 4 pins only, and the fansink I selected have a 3
pins fan. Anyway, it's very silent.
The case is a Silverstone GD06 with 3 slow-speed fans. They are
sufficiently silent for me at stock speed. The overall machine is far
from silent, but highly bearable (much less noise than the fridge).

 BTW. I'm looking for the same sort of thing, no idea yet what software I
 would use, but it would only be a remote VDR client for me. To get away
 from modulating the signal onto the existing cable I want to add some
 small clients if possible. The main VDR would stay in the cellar where 
 it is now.

streamdev-server on the server, to streamdev-client + xineliboutput.
or xineliboutput on the server, to vdr-sxfe/fbfe on the client.

-- 
NH


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

Re: [vdr] Wanted VDR xineliboutput client

[Nicolas Huillard]

Le dimanche 16 octobre 2011 à 14:02 +0300, JJussi a écrit :
 Any suggestions for small, powerful, quiet, FullHD   VDR client?
 So, I search machine what would act as VDR-client, using xineliboutput 
 with FullHD resolution and machine would have DVI or HDMI connection + 
 optical audio.
 
 Of course remote control is needed too! ;-)

If you also want to remain 100% free on the software side, I'd suggest a
mini-ITX Core i3 (SandyBridge) motherboard + PicoPSU power supply:
* small : Mini-ITX + reasonable CPU fansink is not that huge
* powerful : even a Core i3 2100 is powerful enough (cpufreq is almost
always at 1,6GHz, with 4% CPU while decoding SD video ; 2,1GHz / 17% HD
video ; I'm not sure which decoding pipe is actually used)
* FullHD : Intel video is really good, with 100% free drivers
* xineliboutput : I only have an issue with HUD OSD at the moment, and
tearing, but I'm sure the situation will improve very quickly with
drivers
* DVI, HDMI, optical : choose the motherboard you prefer
* power consumption : too bad my UPS battery died a few days ago, as
it's not able to tell the actual load of my server now. I previously
estimated it at 31,5W idle / 67,2W full CPU load (micro-ATX board, Core
i3 2100, 2×2TB Western Digital Green, no DVB device at the moment)
* remote control : some (if not all) Intel motherboards have Consumer IR
connector, with open drivers, cheap eBay IR receivers, capable of
powering on the PC

That's for the PC-side of things, with a few dozen millions useless
transistors. Embedded gizmos are much more integrated, simple,
efficient, etc. but always lack the little thing you really need/want,
or are a bit difficult to work with.

-- 
NH


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

[vdr] xineliboutput suspend + OSD HUD on SandyBridge

[Nicolas Huillard]

Hi,

I have a new VDR+ server system, based on SandyBridge i3 CPU. This
server is located under the TV set, thus mixes the server (always-on
headless) + client (HD display) roles (previous setup was a Via EK8000
server + Via ML1 client which ended up on the same shelf + another
still-used client).

I have two issues with this setup :

1) I don't know the best way to suspend the output of xineliboutput
(vdr-sxfe loaded within nodm which auto-reloads it upon crash) : the
xineliboutput README refers to the suspendoutput plugin
(http://phivdr.dyndns.org/vdr/vdr-suspendoutput/) which last release is
dated 12-Feb-2009.
Since I use the e-tobi repository (marvellous, many thanks Tobias),
which does not include it, I wonder if there is a better way to suspend
the video decoding output.

2) the HUD OSD display works with --hud=xshape, but each OSD refresh
(changing time, recording location) removes the previous OSD, replacing
it with only the changed portion. --hud=opengl crashes vdr-sxfe because
OpenGL is probably not quite ready with SandyBridge. OSD without HUD
works, but is obviously ugly on the 1920x1080 display.
I pulled xineliboutput 1.0.7+cvs20110918.1632-1 from e-tobi : maybe this
CVS version is right in the middle of some change ?

Other versions (all binaries from e-tobi) :
vdr 1.7.21-1~ctvdr1
vdr-plugin-femon 1.7.10-4
vdr-plugin-live 0.2.0-15
vdr-plugin-skinsoppalusikka 1.7.4-1
vdr-plugin-streamdev-server 0.5.1-4
vdr-plugin-xineliboutput1.0.7+cvs20110918.1632-1

Core i3 video-related, from Debian backports :
linux-image-2.6.39-bpo.2-amd64 2.6.39-3~bpo60+1
libdrm-intel1 2.4.26-1~bpo60+1
libgl1-mesa-dri 7.10.3-4~bpo60+1
xserver-xorg 1:7.6+8~bpo60+1
xserver-xorg-core 2:1.10.4-1~bpo60+1
xserver-xorg-video-intel 2:2.15.0-3~bpo60+1

-- 
NH


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

[vdr] channels.conf fr-Paris since analog switch-off

[Nicolas Huillard]

Hi all,

For some reason (API/kernel mismatch or so), I can't manage to run a
working DVB scan with either scan, dvbscan or w_scan, and VDR itself
don't seem to catch the new transponders, whatever I do...
Since this is a family urgency, I can't wait to upgrade everything
needed in my VDR server (which does a lot of other things, making an
emergency upgrade a bit risky) before having all channels back.

What I miss is apparently only multiplex R4 (Multi4, M6, W9, NT1, etc.).
I can't find anywhere on the net what frequency it now uses in Paris
(Tour Eiffel). Can someone in the area share his/her channel.conf,
please ?

For those who wonder: last Tuesday, they switched off analog TV in many
locations in France, rearranging some transponders in the process. Most
channels were correctly updated (or not actually changed) by my VDR
instance, but some must have changed frequencies and are thus missing.

TIA,

-- 
NH


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

Re: [vdr] new support

[Nicolas Huillard]

Le jeudi 21 janvier 2010 à 09:27 -0600, Rob Davis a écrit :
 More native support could be good..  However, I wonder what the
 advantage would be to having this over an internal pci dvb card or even
 a usb one?  The pci card is surely cheaper, and the functionality is
 already there in VDR?

It may be useful in a multi-client setup, where each client have no
storage nor DVB device, and the storage is a simple NFS server (tiny NAS
server with USB disks).
Different kind of setup than the usual server using storage and DVB
devices, to which diskless/deviceless clients connect.

-- 
NH


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

[vdr] e-tobi/Debian runvdr patch for USB modules

[Nicolas Huillard]

Hi,

Here is a patch that loads/unloads USB modules in the runvdr script
found in e-tobi and probably Debian packages.
It works since 1 month here, with the Nova-TD-500 PCI card (with onboard
USB), which uses dvb_usb and dvb_usb_dib0700.

Happy new year to everyone ;-)

-- 
NH
--- /usr/sbin/runvdr.orig   2010-01-05 09:24:55.0 +0100
+++ /usr/sbin/runvdr2010-01-05 09:22:33.0 +0100
@@ -13,6 +13,9 @@
 {
 MODULES=`lsmod | awk '/^dvb_core/ {gsub(/,/,\n, $4); print $4}' | tac`
 [ $MODULES ]  MODULES=$MODULES dvb_core
+# 20091205/NH : get USB modules names too
+USBMODULES=`lsmod | awk '/^dvb_usb / {gsub(/,/,\n, $4); print $4}' | tac`
+[ $USBMODULES ]  MODULES=$USBMODULES $MODULES
 }
 
 # TODO: check if udev handles this on newer systems!?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [OT] mini-PCIE with Broadcom Crystal HD Hardware Decoder (BCM970012) for HD playback with free drivers

[Nicolas Huillard]

Le mardi 05 janvier 2010 à 00:14 +0300, Goga777 a écrit :
  I wish we could get away from xine. 
 
 how ? does it possible at all ?

softdevice uses ffmpeg with DirectFB, and works wonderfully (worked,
in my case). Lack of X11 brings a lot of little improvements. In a pure
STB setup, X11 is really useless, so why not just get rid of it. Xine
have also lots of useless features for a STB.
The only problem is that display drivers are well maintained in Xorg,
but framebuffer drivers used by DirectFB may not be maintained as much. 

I switched from softdevice to xineliboutput because I was tired of
patching/recompiling the kernel/DirectFB/softdevice/etc with framebuffer
fixes. The net result with xineliboutput is that I can use binary
packages (e-tobi), which brings visual artifacts and crashes.

Maybe current Intel framebuffer/DirectFB drivers are OK with that
Broadcom chip (re. deinterlacing, scaling, etc.), reviving the general
interest with softdevice ?

-- 
NH


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

Re: [vdr] New URL of the VDR homepage

[Nicolas Huillard]

Le dimanche 11 octobre 2009 à 13:46 +0200, Klaus Schmidinger a écrit :
 The VDR homepage has moved to the new URL
 
   http://www.tvdr.de

TVDR = TV Done Right
Great ! Nothing could be more true.

BTW : is your production instance still that old P5 / K6-2 / 80GB
machine ?
I use these P5 / K6-2 underclocked to 180MHz / 80GB as music only
jukeboxes ;-) (one of them is http://www.huillard.net/jukebox/)

-- 
NH


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

Re: [vdr] Any really working HD video output systems for VDR?

[Nicolas Huillard]

Gerald Dachs a écrit :
 VDR User schrieb:
 VDR + hdtv has been pretty stable for me for some time now.  The few
 problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau
 devs.  I'm not the only one either, I know a bunch of guys doing the
 same.  It's a highly discussed topic and I'm honestly surprised to
 hear someone suggest it's in an unstable/crashing/unusable state.  My
 experience has been basically the opposite of that.  I would recommend
 you make sure to have a nice good signal, proper configurations, etc.
 
 I agree with VDR User, I use it for months now without problems.

Could you please both detail a bit the DVB sources, software versions, 
plugins, patches, etc. related to HD, that you actually use now ?
(DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine 
plugin, xinelib patches...)

Maybe there is an english howto somewhere ?

-- 
NH

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

Re: [vdr] [OT] What about the VIA VX855?

[Nicolas Huillard]

Paul Menzel a écrit :
 there has been some talk about the new ION chipset from NVIDIA on this
 list [1]. Intel also published a board which is said to be very
 promising for SD (standard definition) material [2] (at least with the
 FRC (frame rate control) patches [3].

This boards seems cool, but anything new without HD video decoding is 
not enough these times.
Pros :
* 12V power supply input (I hope all the manufacturers will soon agree 
on some internal/external connector standard, and we will see plenty of 
efficient power bricks)
* very few external port, specially getting rid of useless things (PS2, 
all the analog audio jacks, etc.)

 So what about the VIA VX855 chipset [4] as the basis for a multimedia
 platform? VIA publishes the docs and it looks like it will even be
 supported by coreboot [5][6].

EPIA M boards were supported by coreboot since a very long time 
(CLE266). That's a good point, but I never jumped into it...

The real problem is that the XvMC and further HD video decoding are not 
really supported by VIA. I follow the openchrome-devel ML since some 
time now (http://wiki.openchrome.org/pipermail/openchrome-devel/), and 
it seems VIA is still waiting for legal advice before fully releasing 
MPEG2/4 documentation for their chips.
MPEG4 does not work on any VIA chip, and MEPG2 is only supported on the 
older ones.

 I know it depends on what you need (SD or HD and so on). But I searched
 for »vx855 vdr«, »vx855 xbmc«, »vx855 mythtv« on the WWW and did not get
 meaningfull results. Or is the problem, that there are no boards
 available yet?

There are or will be good EPIA boards with this chip. The problem is 
that I do not trust VIA to release enough documentation quickly enough 
to attract users (me).
I now personnaly see ION as the platform of choice for video (VDR). I 
thought VIA could have become a good challenger, but it seems they do 
not want to...

My latest experience with VIA was that the IDE silicon on many chips is 
broken since many years, and freeze the whole system. I had random 
freezes on my EPIA EK8000 server (uptime from 1 day to 5 months), more 
or less depending on various kernels, load, other devices, etc.. Until I 
decided to really dig into this, and replace the IDE drives with SATA 
drives. As of now, no more freezes.
All this to say that I do not trust VIA anymore, even though I have 2 
diskless VDRs based on CLE266 (which work wonderfully, except for 
deinterlacing on progressive device, since my last upgrade).

-- 
NH

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

Re: [vdr] epgsearch as default EPG browser/guide?

[Nicolas Huillard]

Alex Betis a écrit :
 Is there a way to configure VDR show the epgsearch plugin as default guide?
 Currently I can access the plugin by pressing green button or from the menu.
 
 I'd like it to replace the default EPG browser when pressing guide button
 and another place (less
 important for me) when pressing info button and than back button.

I recently read about a menu plugin, which handles all the menu 
system, right from the main menu. The menu tree appears to be configured 
with an XML file, which calls standard submenus, plugin menus, or even 
launches commands.

Unfortunately, I can't remember where, and I have no browsing history at 
the moment.

You question is part of a recurring request about the menu : the main 
items can't be easily *replaced* by plugins. Maybe Klaus have something 
regarding this in his secret TODO list ;-)

-- 
NH

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

Re: [vdr] [OT] NVidia ION mini-ITX arriving

[Nicolas Huillard]

Magnus Hörlin a écrit :
 Well, my first imressions of the ION platform (Acer Revo) are very good. 
 It does the vdpau deinterlacing without problems and so far the video 
 decoding has not exceeded 1% cpu load for ANY 1080p clip I've tried. 
 This is the best VDR frontend/XBMC machine I've ever tried. I don't know 
 why, but it works better than my Intel E7200/Nvidia 9400 uATX board. For 
 those interested it uses 34W from 220V with the hdd still attached. I 
 don't know if it's using any power though, since I've disabled SATA in 
 the bios because I boot it off the network. Anyone who knows how to open 
 this wonderful little thing?

Thanks for the feedback.

Knowing that my EPIA ML6000 draws 25W from the wall (no HDD at all) 
while hardware-decoding MPEG2, using the same kind of power brick, I'd 
say decoding 1080p with 34W is great !
I guess the HDD will still spin, even with SATA disabled at the BIOS. 
You could rip 2 more watts off by unpluging it.

Openning it :
http://hothardware.com/Articles/Acer-Aspire-Revo-SFF-NVIDIA-Ion-PC/?page=3

Does digital sound come out of the box on HDMI only ? No SPDIF of some 
kind ?

-- 
NH

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

[vdr] Only 2 colors transparent OSD with xineliboutput on CLE266

[Nicolas Huillard]

Hi,

I'm having OSD problems when upgrading. The OSD is normally transparent, 
using all 4 or 5 colors, on EPIA ML6000 / CLE266 graphics. When 
upgrading kernel + xine + xorg + a few other things, all colors except 
yellow are displayed as black, leaving a yellow + black + transparent OSD...
Everything else seems to be OK (except xvmc_bob_deinterlacing, which 
seems to be replaced by one_field).
I can't find anything related to this in 
/var/lib/vdr/.xine/config_xineliboutput (but I'm not sure how this file 
is handled : when is it created, changed, updated with new versions, etc.)

I use Debian sid + e-tobi packages.

Working versions :
libxine1   1.1.16.1-1
libxine1-xvdr  1.0.3-2
libxineliboutput-sxfe  1.0.3-2
vdr1.6.0-8ctvdr1
vdr-plugin-skinsoppalusikka1.6.2-1
vdr-plugin-xineliboutput   1.0.3-2
xserver-xorg   1:7.3+18
xserver-xorg-core  2:1.4.2-10
xserver-xorg-video-openchrome  1:0.2.902+svn579-4

Failing versions :
libxine1   1.1.16.3-1+b2
libxine1-xvdr  1.0.4+cvs20090425.1834-2
libxineliboutput-sxfe  1.0.4+cvs20090425.1834-2
vdr1.6.0-8ctvdr5
vdr-plugin-skinsoppalusikka1.6.4-2
vdr-plugin-xineliboutput   1.0.4+cvs20090425.1834-2
xserver-xorg   1:7.4+1
xserver-xorg-core  2:1.6.1.901-2
xserver-xorg-video-openchrome  1:0.2.903+svn741-1+b1

-- 
NH

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

[vdr] [worked around] Only 2 colors transparent OSD with xineliboutput on CLE266

[Nicolas Huillard]

Nicolas Huillard a écrit :
 I'm having OSD problems when upgrading. The OSD is normally transparent, 
 using all 4 or 5 colors, on EPIA ML6000 / CLE266 graphics. When 
 upgrading kernel + xine + xorg + a few other things, all colors except 
 yellow are displayed as black, leaving a yellow + black + transparent OSD...

I found that :
* changing skin reveals that only the first color is shown (blue w/ 
classic skin, yellow with ST:TNG)
* setting antialiasing in the standard VDR config to OFF displays all 
OSD colors (it seems that Xine OSD cannot allocate all colors needed by 
anti-aliasing, ie. the first anti-aliased color fill the palette very 
quickly)

-- 
NH

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

[vdr] bob deinterlacing with xineliboutput on CLE266

[Nicolas Huillard]

Nicolas Huillard a écrit :
 Everything else seems to be OK (except xvmc_bob_deinterlacing, which 
 seems to be replaced by one_field).

Still can't find anyting related to this missing deinterlacing...

No deinterlacer work at all (all display a single field, dividing the 
vertical resolution by 2).

 I use Debian sid + e-tobi packages.
 
 Working versions :
 libxine1   1.1.16.1-1
 libxine1-xvdr  1.0.3-2
 libxineliboutput-sxfe  1.0.3-2
 vdr1.6.0-8ctvdr1
 vdr-plugin-skinsoppalusikka1.6.2-1
 vdr-plugin-xineliboutput   1.0.3-2
 xserver-xorg   1:7.3+18
 xserver-xorg-core  2:1.4.2-10
 xserver-xorg-video-openchrome  1:0.2.902+svn579-4
 
 Failing versions :
 libxine1   1.1.16.3-1+b2
 libxine1-xvdr  1.0.4+cvs20090425.1834-2
 libxineliboutput-sxfe  1.0.4+cvs20090425.1834-2
 vdr1.6.0-8ctvdr5
 vdr-plugin-skinsoppalusikka1.6.4-2
 vdr-plugin-xineliboutput   1.0.4+cvs20090425.1834-2
 xserver-xorg   1:7.4+1
 xserver-xorg-core  2:1.6.1.901-2
 xserver-xorg-video-openchrome  1:0.2.903+svn741-1+b1

-- 
NH

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

[vdr] [OT] NVidia ION mini-ITX arriving

[Nicolas Huillard]

http://www.mini-itx.com/2009/05/04/zotac-ion-itx-atom-mini-itx-board-unboxing-and-salivating

...which means 1080p HD playback from an embedded Mini-ITX board with a 
fanless 1.6GHz processor whilst consuming 21W.
The ION-ITX-A has its own DC converter onboard, and is supplied with a 
90W AC Adapter.

Nice silent drop-in replacement for any mini-ITX / micro-ATX mobo.

-- 
NH

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

Re: [vdr] Editing usability

[Nicolas Huillard]

Pasi Juppo a écrit :
 What's the difference today's functionality? Very small. Only this time
 user is shown more information and is provided help (a man page, if you
 like) in case of need.

Many plug-ins would benefit from such a core help system.

I never managed to learn the remote keys for the DVD plugin : back to 
DVD menu, next/previous chapter etc... The only things I can say is that 
those keys are very different from cutting keys, and that trial'n'error 
didn't work...

-- 
NH

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

Re: [vdr] Can I disable pause live tv altogher?

[Nicolas Huillard]

marti...@embl.de a écrit :
 Now, as for the instant recording, how about it gets deleted when you zap t
 o another channel?

...or when there is no available tuner to continue the older 
instant-recording... I think about zapping, when you would like to keep 
the previous channel instant recording.

I would be very pleased if that function was handled by the VDR server 
(the one with the DVB devices), instead of the VDR client (which gets 
it's streams via the network).
The same applies to cutting (the headless server with the disks should 
do the cutting, not the diskless client with the IR receiver).
But all this is another (big) thread...

-- 
NH

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

Re: [vdr] Can I disable pause live tv altogher? (more and more OT)

[Nicolas Huillard]

VDR User a écrit :
 512MB won't get you far with hdtv.  It won't even get you 5 minutes
 worth.  Needless to say, you'd need at least a few GB of dedicated ram
 to even bother with it.  At least ram is cheap now as you've pointed
 out (especially if you take advantage of MIR's).  After seeing how
 much money I was wasting every month in my electric bill just by not
 setting a sleep timeout on my harddrives, ram is the only place I'd
 want any caching like that to take place if I were interested in
 buffering live tv.

Can you give tell us how much ?
I roughly estimated the cost here in France : 1W on 24/7/365 costs 1€/year.

Leaving a green HD on 24/7 (Western Digital 1TB GP) costs me 5€/year 
here. Leaving the whole server on (4 HDD, DVB device, ADSL box, 
networking gear, etc.) costs me 65€/year... Much less than, say, hot water.

-- 
NH

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

Re: [vdr] VDR-1.7.7 Video aspect ratios

[Nicolas Huillard]

Rolf Ahrenberg a écrit :
 On Sun, 3 May 2009, Tomas Berglund wrote:
 
 Do you mean aspect ratio 2.21:1 ?

 +const char *VideoAspectString[] = { 4:3,
 +16:9,
 +2.21:9
 +  };
 
 Besides of that typo, there're plenty of video aspect ratios missing:
 1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11, 
 15:11, 64:33, 160:99, 3:2, 2:1.

16:10 is also a common device aspect ratio these days ;-)

 Anyway, I'm not very fond of this new interface addition. After a little 
 playing with xineliboutput plugin in the past, the OSD scaling to video 
 size is a total mess and hence the HUD mode was developed, where the 
 OSD resolution is the same as the output resolution and the video is 
 scaled to that resolution. I'd strongly suggest to implement 
 cDevice::GetOSDSize(), so the output plugins can correctly set their 
 OSD resolution with minimal scaling artefacts.

I strongly second that. Add the fact that some (most ?) of the channels 
here mess / cheat with aspect ratio / resolution, and I currently (VDR 
1.6, SDTV, xineliboutput) have a unextricable aspect/resolution/OSD 
problem. I'm not even trying to solve it...

I'd also suggest the maximum OSD size is 1920x1200 instead of 1920x1080, 
as this 16:10 resolution is very common in computer land. That's also 
the maximum a DVI single link can output.

-- 
NH

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

Re: [vdr] VDR-1.7.7 Video aspect ratios

[Nicolas Huillard]

Matthias Becker a écrit :
 and what about  anamorphic material?
 A 16:9 SD broadcast in fact still is 4:3 but is streached by the TV to
 16:9 to look ok (no egg-heads).
 Wouldn't it be correct also to draw the OSD anamorphic so that is not
 screached by the TV?
 
 Did you get the point? It's somehow difficult to describe this topic for me.

With today's pixel-displays, we'd like to avoid all scaling, stretching, 
etc. done by the panel itself. ie. like Rolf said, always output from 
the computer at panel resolution, with 1:1 pixel mapping.
Video would be scaled, but not the OSD.

 Regards,
 Matthias
 
 2009/5/4 Rolf Ahrenberg rahre...@cc.hut.fi:
 On Mon, 4 May 2009, Falk Spitzberg wrote:

 The OSD should adopt to the size of the video material. If that is
 scaled to some non TV screen size, the OSD is scaled by the same factor.
 I still disagree. If you scale down your OSD to video resolution (i.e.
 544x576) and afterwards scale up the both video and OSD to output
 resolution (i.e. 1280x720), the OSD really looks crap due to scaling
 artefacts.

-- 
NH

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

Re: [vdr] Options for deinterlacing (or not)

[Nicolas Huillard]

Thomas Hilber a écrit :
 On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote:
 There's no english howto anywhere?
 
 sorry, not yet.

Is the below rough summary correct ?

What it currently is :
* a patch set to DRM kernel modules, xine-lib and xineliboutput
* that adds proper interlaced output from ATI and Intel GPUs
* it also adds FrameRateControl under some conditions
* it's stable and works on VGA, but seems to also work on HDMI
* only works with Xv (does/can not make use of XvMC)
* can work with any display device (CRT, LCD, plasma)
* make most use of the display device capability (interlaced display on 
a SD CRT, picture enhancers on HD LCD/Plasma)

Ideal goal would probably imply :
* output mode change upon source mode change (output 720x576i on the VGA 
when playing SDTV, output 1920x1080i/p when playing HDTV contents, etc.)
* make use of hardware decoding capabilities when available (specially 
for HDTV)

Side-needs :
* add support for nVidia, VIA chips, etc. (feasability ?)
* integrate these patches upstream (feasability, propagation delays?)

-- 
NH

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

Re: [vdr] Serial IR receiver + wakeup from suspend

[Nicolas Huillard]

Ville Aakko a écrit :
 BTW there's also an english manual on the site.

I can't find it anywhere. Only german pages and manuals...
Do you have a link ?

-- 
NH

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

Re: [vdr] Minimal VDR install

[Nicolas Huillard]

Andrey Kuzmin a écrit :
 I usually start by installing the latest version of ubuntu on one
 computer and then duplicate that directory  for every client.
 
 Completely   diskless   clients   booting  through  PXE or iSCSI  from
 single image or from dedicated images from server are also worth  to  try.
 This work fast on gigabit networks with dedicated network cards on server
 per client. Haven't tried this with VDR yet, planning in future.

100Mbps EPIA EK8000 server here, with 2 diskless/deviceless clients. 
According to Munin, during a typical week :
* peak disk IO : 2k blocks read per second, 2k blocks written per second
* peak eth0 traffic : 10Mbps to the server, 15Mbps from the server
* 2% CPU due to the VDR server process
* 8% peak CPU due to DVB + eth devices during recordings or live-view
* 80MB memory for all userland apps (VDR + Samba + DNS + MPD, etc. etc.)

-- 
NH

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

[vdr] Any reason the remotetimers plugin is not part of e-tobi.net ?

[Nicolas Huillard]

Hi,

Any reason the remotetimers [1] plugin is not part of e-tobi.net [2] ?

Is there an alternative, other than using the remoteosd plugin (that I'm 
already using, but have a low WAF).

[1] http://vdr.schmirler.de/
[2] http://www.e-tobi.net/repositories/repositories.html

-- 
NH

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

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

[Nicolas Huillard]

Klaus Schmidinger a écrit :
 On 08.01.2009 18:50, user.vdr wrote:
 On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger
 klaus.schmidin...@cadsoft.de wrote:
  + The directory name for a recording has been changed from
-MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to
-MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resumeId).
 Is the channel number even necessary information to store in a
 dirname?  I've experienced many times where channels have been
 shuffled (requiring a rescanning  a new channels.conf)
 so channel 100 could be one network today and a different one
 tomorrow.  Maybe a better choice would be using the channel shortname,
 for example:

 -MM-DD-hh.mm.CNN-ri.rec
 -MM-DD-hh.mm.BBC-ri.rec
 
 The channel number would be unnecessary, because that information
 is stored in the 'info' file. However, it is contained in the
 recording's directory name, so that in case two timers of the same VDR
 instance record the exact same programme, but on different channels,
 they don't mix their data into one big pile of goo (which could have
 happenend in VDR 1= 1.7.2). No need to make this a string - it's just
 a safety precaution (besides, two channels might have the *same* name,
 but never the same number).

-MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR 
instances recording the same show.
This is a usual problem of multiple instances sharing a single /video dir.
As we're talking about safety here, why not address it right now, once 
and for all ?

If you do not have a unique identifier for each VDR instance yet, the 
only thing I can think of is hostname + SVDRP port number (this 
identifies both single instance on many hosts, and multiple instances 
on a single host).

-- 
NH

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

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

[Nicolas Huillard]

Klaus Schmidinger a écrit :
 On 12.01.2009 13:41, Nicolas Huillard wrote:
 -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR 
 instances recording the same show.
 This is a usual problem of multiple instances sharing a single /video dir.
 As we're talking about safety here, why not address it right now, once 
 and for all ?
 
 I did - by using the resume id. This should be unique for any VDR instance
 accessing a common video directory.

Well, I re-read the MANUAL regarding this issue before my posting above ;-)
The resume ID is described excactly as I use it :
Defines an additional ID that can be used in a multi user
environment, so that every user has his/her own resume
files for each recording. The valid range is 0...99, with
0 resulting in a file named 'resume.vdr', and any other
value resulting in 'resume.n.vdr'.

ie. it does not define the VDR instance, but the user instance...
In practice, I set this to the same 0 value on every VDR, because I want 
to be able to stop a replay on one VDR, and continue viewing it on 
another VDR, starting at the position I stopped it...

-- 
NH

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

Re: [vdr] Roadmap for VDR 1.8

[Nicolas Huillard]

user.vdr a écrit :
 On Fri, Jan 9, 2009 at 11:27 AM, Artem Makhutov ar...@makhutov.org wrote:
 What points have to be done to finish 1.7.x and to get to 1.8.0.
 
 In the years I've been using VDR, there has always been many
 development versions before Klaus has released a new stable so based
 on past experience, I wouldn't expect to see 1.8.0 any time soon.
 There are some big changes in 1.7.x and I guess it could go either
 way.  He might want to release a new stable after the major stuff has
 been implimented and tested, saving the little things for the next
 development line.  Or he could just take it slow  easy.
 
 One nice thing I've learned is that most dev versions are pretty damn
 stable themselves.  I've been running dev versions probably 90%+ of
 the time on my main vdr box.  :)

Another thing I've learned is that Klaus never (AFAIK) discussed roadmap 
details or made his own task list public ;-)

-- 
NH

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

Re: [vdr] WinTV USB CI-Module and recommended distribution for VDR?

[Nicolas Huillard]

Sascha Vogt a écrit :
 And the second question is about the preferred distribution to use VDR
 with. Are there any distributions optimized for VDR and fast boot times?
 (Yes I know [1], but that didn't help me with choosing one optimized for
 short boot times.) LinVDR seemed to be such, but the last version is now
 4 years old. I personally have experiences with Gentoo and Debian, so
 that would be my choices if no one has a better option worth trying.

I started with a bare-minimum Debian/e-tobi install (with debootstrap on 
an NFS share, which gives a really light bootable system), then 
installed whatever needed, but nothing fancy (ie. X with a tiny WM, but 
no login manager, ACPI, no dbus, etc...).
Boot time is not spectacular, but OK. Next step, as others did, will be 
to suspend to RAM instead of shuting down, which means boot time will 
become irrelevant...
Install size is 724MB, with full docs (à la Debian), stock kernel, 
modules and initrd, some VDR plugins, etc. (including 187MB of useless 
cached packages).
That's work, but at least everything came in binary...

-- 
NH

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

Re: [vdr] WinTV USB CI-Module and recommended distribution for VDR?

[Nicolas Huillard]

Sascha Vogt a écrit :
 Nicolas Huillard schrieb:
 Sascha Vogt a écrit :
 And the second question is about the preferred distribution to use VDR
 with. Are there any distributions optimized for VDR and fast boot times?
 I started with a bare-minimum Debian/e-tobi install (with debootstrap on 
 an NFS share, which gives a really light bootable system), then 
 installed whatever needed, but nothing fancy (ie. X with a tiny WM, but 
 no login manager, ACPI, no dbus, etc...).
 Boot time is not spectacular, but OK. [...]
 
 Can you provide any figures? 30 seconds, 50 seconds, 90 seconds? To get
 at least a rough idea.

30s on an Athlon XP 1.8GHz
roughly 45s on a C3 600MHz

Simply recompiling the kernel, removing unneeded modules and initrd, 
could reduce by 5-10s...

-- 
NH

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

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3

[Nicolas Huillard]

Klaus Schmidinger a écrit :
 If you're using the same compiler as I do, I don't see why such
 a typecast is necessary on your side, while on my side it compiles
 just fine.
 
 Are you using any different compiler options than me?

Didn't I read x86_64 for Mika, when you may use x86_32, Klaus ?

-- 
NH

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

Re: [vdr] Which extension for TS files?

[Nicolas Huillard]

Klaus Schmidinger a écrit :
 Up to now VDR has used names like 001.vdr for its recording files.
 While moving to Transport Stream as the recording format, I need to
 use a different file name extension, and so was wondering which one
 to use. My first idea was *.ts, for Transport Stream, but when I
 point, for instance, Konqueror to such a file, it thinks it is a
 Qt Translation Source. So I was wondering if I should use *.mpg
 instead. This one is identified by Konqueror as an MPEG file and
 will make it launch a proper player.

I think the option is clearly defined now.
I little thing that always annoyed me was that every recoding file had 
the .vdr extension, whatever the actual contents (it seemed like the 
file name was used as an extension). See:
 index.vdr
 info.vdr
 marks.vdr
 resume.vdr

Maybe you will find an opportunity to improve this at the same time...

-- 
NH

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

Re: [vdr] Which extension for TS files?

[Nicolas Huillard]

Klaus Schmidinger a écrit :
 On 04.01.2009 19:21, Nicolas Huillard wrote:
 file name was used as an extension). See:
  index.vdr
  info.vdr
  marks.vdr
  resume.vdr

 Maybe you will find an opportunity to improve this at the same time...
 
 Well, how about leaving the .vdr part away altogether?

Having no extension at all can also be a problem in itself (I'd 
personnaly be OK with it, but some may argue).
Since the extension should match the content type, what about this:
 index.bin
 info.txt
 marks.txt
 resume.bin
...

-- 
NH

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

Re: [vdr] ~/.xine/config_xineliboutput load/save and name changes

[Nicolas Huillard]

Rolf Ahrenberg a écrit :
 On Mon, 15 Dec 2008, Nicolas Huillard wrote:
 Is there a way to tell xineliboutput which file to use ? Like adding a
 command-line param --config=~/.xine/config_xineliboutput.$(hostname)
 
 The attached patch should implement this - no guarantees.

I hope I'll be able to compile this patch before new year. Anyway, thank 
you very much for your efforts.

-- 
NH

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

Re: [vdr] VDR with S2API (update)

[Nicolas Huillard]

Jörg Knitter a écrit :
 Klaus Schmidinger wrote:
 Well, tell that to people writing plugins for such output devices.
 I don't see where *I* would be involved there?!
   
 Are there enough interfaces to be able to read the and control the OSD 
 for including them seamlessly it into a different front-end? I don´t 
 think that SVDRP and interpreting the returned data is the best way to 
 go. And what about the limitation on one OSD per VDR?
 I think, these are the real limitations - currently users of media 
 center UIs are exiting them and start xinelib for using VDR and visa verse.
 A better separation of back-end and front-end could IMHO solve the 
 problem and end the discussion about hardware related support. Because 
 with a clean and some kind of more standardized interface (which also 
 transmits OSD related information), you could write every output device 
 connector/plug-in that you can think and be compatible to more 
 front-ends or devices then before. Even an evil Windows front-end with 
 VDR running on Windows (with the help of something like colinux or a VM) 
 would be possible.
 Currently, xinelib (with original OSD) uses a different protocol than 
 the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in 
 (with OSD tranfered with some kind of VNC IIRC) which also works 
 different from the streamdev approach (without OSD) that is used for 
 hardware streaming clients that use oxyl etc.
 
 Unfortunately, I am just a user, not a developer though I am at least 
 able to read and modify simple C and script code ;) - it has been a long 
 time since I was student and was able/had the time to code little 
 projects...

I second that completely.
IMHO, the core VDR should move toward a multiple OSD capability. Maybe 
the network separation between the back-end and the front-end could just 
be a compilation setting (add a RPC layer at the correct place, as a 
compilation option : no layer = current standalone setup; network layer 
= VDR server + VDR clients).
This should provide a clean way to separate the responsibilities between 
the back-end and the front-ends. The rest is a matter of plug-ins and 
not over Klaus shoulders.

I agree that the hardware side of this is just the visible part (and a 
good flame-war starter). The plugin architecture allows many things, 
which is good. The limits of the core makes it hard to create a 
network-happy VDR system (not a VDR machine, but a system of multiple 
machines), which is the root of many incompatible and incomplete 
plugins, solving all part of the problem (xineliboutput, remoteosd, 
dummydevice, epgsync, remotetimers, etc.)

I just recently started using streamdev, for a bare EPIA ML6000 client 
(diskless, no DVB device, just mobo + RAM + network). I think it's a 
good (and cheap, silent, power-efficient) starting point for a 
network-based STB. It's not perfect, but most of the imperfections come 
from the plugins that must be added and configured, each separately, to 
achieve a good VDR network STB.

It is already possible to have disks array, DVB devices, and all the 
cables down in the closet, and as many clients we want behind each TV 
set, with only a CAT5 cable and an IR sensor. That's just difficult.
Moving existing plugin code into the VDR core, and getting some out of 
the core, into plugin, would do a lot in the right direction.

I trust Klaus to eventually get to it, and the community to provide good 
plugins, providing a tremendous network STB system. I'm not impatient at 
all, I know this will happen. The more time it take, the better will be 
the solution, the longer it will stay.

I look at how my neighbours watch TV : DVB-S converted to an analog 
signal recorded on a crappy VCR, sending wireless scratchy analog to an 
LCD TV (which was really the top 5 years ago), one tape at a time, no 
timeshifting, etc.
...and I'm really happy with VDR.

-- 
NH

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

Re: [vdr] XBMC + VDR 1.7.0

[Nicolas Huillard]

BoNuZZZ a écrit :
 Can I start vdr and xineliboutput separately? For example, vdr starts
 when computer is on, so it works always. But xinelibout is starting
 when I close xbmc.

Yes. You run the plugin in VDR, with no local front-end. You then launch 
vdr-sxfe (X) or vdr-fbfe (DirectFB) front-end on the machine when you 
want to display VDR output.
VDR runs as a headless daemon. A single vdr-??fe can connect to the 
xineliboutput plugin at the same time.

-- 
NH

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

Re: [vdr] VDR with S2API (update)

[Nicolas Huillard]

Udo Richter a écrit :
 On 12.12.2008 18:06, VDR User wrote:
 I can say I've seen many people move away from VDR because it doesn't
 provide a good solution to this.  After years of using standalone VDR
 boxes, I too would love if we had the option to use a networked VDR
 with each client being exactly as you described...  Diskless, and only
 with ethernet cable + IR sensor, and each with an own OSD to control
 his VDR thread.
 
 Hmmm, sounds just like what I have in my bedroom. Ok, it has a local 
 disk for convenience, but no own receiver and no locally stored 
 recordings. It could easily run from an USB stick or do network boot if 
 I want. Oh, and the 'second remote frontend' is actually a complete VDR 
 using streamdev.
 
 I really don't get the point why it is necessary to totally rewrite VDR 
 core to support multiple frontends (surely loosing compatibility to 
 almost all plugins), when it will at the end just start one thread per 
 frontend, while we can already start one VDR instance per frontend right 
 now.
 
 Even better: If one frontend crashes (well, it doesn't, but lets 
 assume), the core VDR just runs on and none of the other frontends 
 crashes too. Cool feature, or?
 
 If you're not happy with using streamdev to connect several VDR 
 instances, wouldn't it be the better way to improve streamdev to meet 
 the needs instead of starting all over again? VDR remote frontends would 
 need a streamdev-like interface anyway.

In my opinion, the client and server are both full VDR, which just 
happen to use one part of the whole functionnality.

I'm just talking about a split line drawn in the core VDR. Maybe like 
the plugin interface is a split between what's in the core and what is 
not, there could be an internal network interface that splits what's in 
the front-end and what's in the back-end.

The problems that come to mind in typical current multiple VDR are :
* DVB device handling is running even if there is no actual DVB device 
(OK, this is not a problem in practice, except for device numbers)
* EPG data is not shared between VDR instances : the one holding the DVB 
devices could distribute the contents upon request (streamdev does 
nearly this)
* recording list is also not shared, even though NFS does the actual 
sharing of files : if one VDR starts a new recording, the other ones 
won't see it until some time, or until .update is touched ; if one VDR 
removes a recording that another one is recording, I'm not sure about 
the result (maybe a few GB lost in a strangely named directory ?)
* schedules are not executed on the VDR instance holding the DVB 
devices, resulting in double network transfert, instead of none at all
* if 2 VDRs record the same program at the same time, it seems to a be a 
big problem... If using a slightly different EPG data, this result in 2 
recordings with different times, and if using the exact same EPG, this 
result in something weird and maybe unusable (say, same station, same 
EPG, one via DVB-S, the other one via DVB-T, two different streams in 
one file...)

Again, I trust Klaus and the collective creativity to come with a clean 
solution, some time. In the meantime, the current solution based on 
various plugins is OK for me.
I just have to remind my wife that she can't do this or that from 
time to time ;-) Not that it's a problem for her. Not that it's 
difficult for me to see why.

(getting back to solder this stupid IR sensor which doesn't want to send 
anything to LIRC)

-- 
NH

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

Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Frank Schmirler a écrit :
 On Mon, 24 Nov 2008 21:41:54 +0100, Nicolas Huillard wrote
 This also works around an annoying bug in the (non-upgraded) EPIA 
 BIOS: the PXE LAN boot does not always initialize the network 
 interface after a shutdown. One have to unplug power to boot 
 correctly next time...
 
 Current via-rhine drivers have a module option to fix this: 
 via-rhine.avoid_D3=1
 For older kernes there's a patch: http://lkml.org/lkml/2004/9/17/242

I was sure it wouldn't hurt to ask on this ML...

Next question : where should I put this ?

https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threadtopic_id=33621forum=10post_id=148956
says I should insert it in the initrd, but it's a bit difficult in my 
case (the same kernel/initrd is shared by many clients)...

I'd try to insert it on the PXE kernel command-line, but it's 
explicitely ignored by the kernel :
ml6000 kernel: Unknown boot option `via_rhine.avoid_D3=1': ignoring
...or implicitely, when I just add avoid_D3=1 (ie. PXE does not boot 
after the next shutdown)

-- 
NH

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

Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Frank Schmirler a écrit :
 On Tue, 25 Nov 2008 14:39:19 +0100, Nicolas Huillard wrote
 I'd try to insert it on the PXE kernel command-line, but it's 
 explicitely ignored by the kernel :
 ml6000 kernel: Unknown boot option `via_rhine.avoid_D3=1': ignoring
 ...or implicitely, when I just add avoid_D3=1 (ie. PXE does not 
 boot after the next shutdown)
 
 You would use via_rhine.avoid_D3=1 if the driver was builtin to the kernel.
 
 When built as a module, it depends on how the modules are loaded.
 
 In an initrd sometimes insmod is used. It accepts module options on the
 commandline (insmod via_rhine avoid_D3=1).
 
 If modprobe is used, specify options via-rhine avoid_D3=1 in
 /etc/modprobe.conf (or a file in /etc/modprobe.d/). You must do it in the
 /etc/ directory which is mounted by the time modprobe is executed (so probably
 inside of your initrd).

Thanks for the answer.

The solution I used is the following, using Debian etch tools :
* add a /etc/modprobe.d/via-rhine file in the running client filesystem
* it contains the said options via-rhine avoid_D3=1 line (along with 
my usual 60% comments)
* then recreate the initrd on the client machine (the one which sees the 
new file) : update-initramfs -u -k 2.6.18-6-486
* don't forget to copy the initrd file in the tftp directory on the 
server, so the client can use it

I'll compile a fine-tuned kernel if I need to reduce boot time, but 
suspend-to-RAM could be much better.

-- 
NH

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

Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Torgeir Veimo a écrit :
 On 24 Nov 2008, at 19:37, Nicolas Huillard wrote:
 
 Blah, only one PCI slot. Where are proper low-power MB's with 2 or  
 more PCI
 slots for DVB-cards?  And how much does the server (NFS, DVB- 
 card(s)) use
 power?
 No use of PCI in the client.
 
 Do you put the DVB cards in the server?

The temporary current setup is weird :
* server only handles NFS root FS and NFS /video share
* 1 client have a PCI DVB-S card, and an USB DVB-T card, with 
streamdev-server
* another client have a PCI DVB-T card, with streamdev-server
* the most recent client have no DVB device

Every DVB device will move to the server, requiring a bit of antennae 
rewiring.

-- 
NH

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

Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Mika Laitio a écrit :
 What I have now tried to search for is a fast booting client for my old 
 P700, that could boot automatically to X with dummy user and then launch 
 the vdr-xineliboutput.
 
 The ideal would be that once bios checks have been done, rest of the boot 
 would for getting X and vdr client running would take less than 30 seconds 
 from the bios checking,  but currently I am very far from that and I am 
 not sure what would be the best option for the client.
 
 1) local harddisk for booting and launching X and vdr-sxfe
 2) nfs mount from server for booting and launching X and vdr-sxfe
 3) local harddisk booting X and connecting to server with XDMCP.
 (would video and audio work over XDMCP from server?)
 4) lpts5 where some apps would be run from server, while multimedia like
 vdr-sxfe would be run from client harddisk
 
 What kind of solutions what boottimes you have for the clients?

 From kernel first log line in the syslog server (I guess timestamps are 
when rcS.d/ scripts start to run, ie. does not include kernel load time 
+ initrd), to LIRC accepting the VDR client (including a 5s sleep I had 
to add):
* 31s on the ML6000
* 16s on a Athlon 2200+
* 18s on the M10k

That's with a single NFS root filesystem and network boot (no local 
storage). It does not include kernel + initrd load time over the 
network, BIOS time, etc. It also does not include specific imrpovement, 
except not install unneeded things.

The best timing would be from power-on to live-TV on the display.
BIOS + PXE (network boot) are ugly in this regard... Initrd is also 
time-consuming.

-- 
NH

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

Re: [vdr] xineliboutput crashes when closing the xineliboutput/videomenu

[Nicolas Huillard]

Darren Salt a écrit :
 I demand that Nicolas Huillard may or may not have written...
 
 [snip]
 vdr 1.6.0
 xineliboutput 1.0.3
 xine 1.1.2
 
 Maybe you should upgrade to 1.1.15. :-)
 
 all Debian etch + e-tobi repository

Well... I think I'll have a step at 1.1.14, when e-tobi.net is ready for 
lenny, then ;-)
Maybe xserver-xorg-video-openchrome will also solve issues left in 
xserver-xorg-video-via too...

Do you (Darren) still maintain an up-to-date repository with Xorg and 
VDR, Xine, etc? I remember using it when playing with CLE266 hardware 
acceleration, a long time ago.

-- 
NH

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

Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Alex Betis a écrit :
 On Mon, Nov 24, 2008 at 3:24 PM, Nicolas Huillard [EMAIL PROTECTED]wrote:
 
 From kernel first log line in the syslog server (I guess timestamps are
 when rcS.d/ scripts start to run, ie. does not include kernel load time
 + initrd), to LIRC accepting the VDR client (including a 5s sleep I had
 to add):
 * 31s on the ML6000
 * 16s on a Athlon 2200+
 * 18s on the M10k
 
 Guys,
 How about putting the system in suspend mode instead of powering it off and
 on again? Should take few seconds.
 Some of you were talking about UPS, so its even safer than I can have...
 VDR can resume from suspend to record programs.

I'll try that ;-)
Suspend to RAM as always been a pain in my various trials, but this is a 
much simpler goal than a complete laptop.
Virtually no device to take down/bring up on a pure streamdev client. 
NFS handles must just survive the long delay, but it should be OK.

This also works around an annoying bug in the (non-upgraded) EPIA BIOS: 
the PXE LAN boot does not always initialize the network interface after 
a shutdown. One have to unplug power to boot correctly next time...

-- 
NH

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

Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Torgeir Veimo a écrit :
 On 22 Nov 2008, at 21:04, Nicolas Huillard wrote:
 
 I must tell that the xxmc (XVMC-VLD) decoding is nearly perfect, the  
 OSD is fully transparent on this, and does not take any CPU at all,  
 and the system is on par with softdevice.
 
 What cpu usage did you get when running softdevice with the cle266  
 output option with this hardware setup?

I didn't use softdevice on this ML6000, but on an older M10K. I don't 
remember the exact details (this M10K is also using xineliboutput at the 
moment), but it was quite the same, ie. I didn't bother with CPU usage 
since it was largely within safe limits (=20%).

M10K is currently at 15-18% CPU for VDR (plus a bit for kdvb-fe-*)

Software decoding with softdevice was OK (with transparent OSD on 
DirectFB), but is clearly out of question with xineliboutput (software 
OSD makes most of the frames drop).

-- 
NH

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

[vdr] e-tobi Debian VDR-Repository and lenny

[Nicolas Huillard]

Hi,

I'm currently upgrading most of my VDR systems (going to diskless NFS 
clients), using preferably prebuilt packages (so much easier to maintain 
than custom patched ones ;-).
I was wondering what was the plan regarding the upcoming Debian lenny in 
e-tobi repo ?

There are some packages I'd like to use from there :
* xserver-xorg-video-openchrome : currently using xserver-xorg-video-via 
instead, but support seems to be much improved in openchrome
* new kernel, for more hardware support (unfortunately, etch LIRC kernel 
package for serial receiver does not compile with 2.6.24 from 
etch-n-half, and I don't want to start tweaking everything)

I also experience weird problems (crashes, double OSD, etc.) with 
xineliboutput (sxfe), and would like to remove all causes related to old 
versions (as much as plain etch now feels old: xinelib, openchrome, 
xorg, etc.).

-- 
NH

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

[vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !

[Nicolas Huillard]

Hi all,

I'd like to report that I'm really impressed by the new setup I now 
have. The most problematic thing was proper transparent OSD which would 
not eat much CPU. I must tell that the xxmc (XVMC-VLD) decoding is 
nearly perfect, the OSD is fully transparent on this, and does not take 
any CPU at all, and the system is on par with softdevice.

My current setup :
* diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps 
Ethernet, 12V power supply, no fan, no noise : 25W off the wall while 
decoding video
* NFS root FS on the always-on server : fully Debian etch with e-tobi 
repository, no self compiled package, except kernel-source package for LIRC
* VDR 1.6.0-2
* xineliboutput 1.0.3
* streamdev-client 0.3.4
* skinsoppalusikka 1.6.2
* femon 1.6.3

BTW : CPU usage was 2% when decoding SDTV MPEG2 video only, with no Alsa 
sound setup, and climbed to 20% when Alsa was finally configured and 
working. That's a bit strange to think that audio is 9x more 
CPU-intensive than video ;-) (I think it may also be a big slice of 
synchronization delays)

Kudo to everyone involved in VDR, at all levels !

(problems/crashes reports will be for another day/post)

-- 
NH

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

[vdr] xineliboutput crashes when closing the xineliboutput/video menu

[Nicolas Huillard]

Hi,

This is the most annoying bug : after some time tweaking the video 
output (which works), the video submenu just crashes VDR upon closing 
(with back, menu or ok keys).
No matter that I change setting or not : closing will crash.

The current video setup is :
xineliboutput.Video.AspectRatio = 0
xineliboutput.Video.AutoCrop = 0
xineliboutput.Video.AutoCrop.AutoDetect = 1
xineliboutput.Video.AutoCrop.DetectSubs = 1
xineliboutput.Video.AutoCrop.FixedSize = 1
xineliboutput.Video.AutoCrop.SoftStart = 1
xineliboutput.Video.Brightness = -1
xineliboutput.Video.Contrast = -1
xineliboutput.Video.Deinterlace = bob
xineliboutput.Video.DeinterlaceOptions = 
method=Linear,cheap_mode=1,pulldown=none,framerate_mode=full,judder_correction=1,use_progressive_frame_flag=1,chroma_filter=0,enabled=1
xineliboutput.Video.Driver = xxmc
xineliboutput.Video.FieldOrder = 0
xineliboutput.Video.HUE = -1
xineliboutput.Video.IBPTrickSpeed = 0
xineliboutput.Video.MaxTrickSpeed = 12
xineliboutput.Video.Overscan = 0
xineliboutput.Video.Port = :0.0
xineliboutput.Video.Saturation = -1
xineliboutput.Video.Scale = 0
xineliboutput.Video.SwScale = 0
xineliboutput.Video.SwScale.Aspect = 0
xineliboutput.Video.SwScale.Downscale = 0
xineliboutput.Video.SwScale.Height = 576
xineliboutput.Video.SwScale.Resize = 0
xineliboutput.Video.SwScale.Width = 720
xineliboutput.VideoModeSwitching = 1

I guess there is some kind of impossibility here, but I didn't tweak 
these setting manually.

(I didn't find an english-speaking xineliboutput-specific mailing list 
anywhere, so I guess the good spot is here)

-- 
NH

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

Re: [vdr] HD-TV hardware decoding on motherboard instead of waiting for FF DVB-S2 card

[Nicolas Huillard]

Ondrej Wisniewski a écrit :
 With VDR getting ready for HD-TV it seems that today the MPEG4 decoding 
 can only be done on a high end processor or an external decoder card. 
 Many people are still waiting for a FF DVB-S2 card but it doesn't look 
 very promising at the moment.
 
 So I was wondering if it would be possible to use the on board video 
 decoder chips of the VIA EPIA boards like the VIA EPIA EX15000G
 http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=450
 
 This board mounts a CX700M2 chipset which features MPEG2/4 hardware 
 decoding. It has DVI and Y/Pb/Pr video output as well as analog and 
 SPDIF audio (coaxial and optical). So that's everything we need, isn't it.
 
 I know, currently the OpenChrome video driver doesn't support MPEG2/4 
 video decoding for the CX700M2 and there are probably other things 
 missing from the software support side. But from what I see, this or a 
 similar motherboard in combination with a budget DVB-S2 card have all 
 the hardware features that are needed to have HD-TV. So we actually have 
 the proper hardware platform *today* for a quite a low budget. So if all 
 the efforts go into driver and application development for such a 
 platform, there is no need to wait for FF DVB-S2 cards.
 
 Or am I missing something here?

I'd also like to read some answers to that specific question.
Is the EPIA EX the kind of hardware that could some day properly render 
1920x1080 broadcasts ?

-- 
NH

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

Re: [vdr] Straw poll: stable version 1.6.0 now?

[Nicolas Huillard]

Klaus Schmidinger a écrit :
Should there be a stable version 1.6.0 now, based on what's in
version 1.5.14, but without DVB-S2 or even H.264 support?
 
 Yes or No?

1) a stable release shouldn't stop the current development for a long 
time, thus shouldn't delay the S2/H264 and other neat future features,

2) a stable release is becoming kind of important (with features as they 
are in 1.4.13) for packagers and regular users, because of simple delay 
between releases,

3) developpers of this list will continue to use the next development 
suite either, so the stable release won't much impact them

This is a Yes.

-- 
NH

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

Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12

[Nicolas Huillard]

Reinhard Nissl a écrit :
 Dominique Matz schrieb:
 
 sound very good, but vdr as root do not :-(

 do you think it is possible to use this or something else with an non
 root user?
 
 Well, only the LIRC_PRIORITYBOOST option requires root privileges
 to work. If you don't have root privileges, you'll just get an
 error logged and the LIRC thread runs without any change in
 priority -- that's all. See man setpriority for details.

An option would be to lower priority of all threads except this one. I 
guess only relative priority within VDR is important.
You can also raise priority in your init scripts (nice=-N), before 
running VDR. This way every thread will have nice=0 priority, except the 
LIRC one, which will stay at nice=-N

-- 
NH

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

Re: [vdr] Best Diskless capable distribution ?

[Nicolas Huillard]

Stefan Hußfeldt a écrit :
 Juergen Sauer schrieb:
 
 So, which remote boot capaple distri do you use ?
 Which is best to choose ?
 
 I'm using debian (server, diskless client) with e-tobis VDR repository.Don't
 know, if it's the best...
 http://www.vdr-portal.de/board/thread.php?threadid=40936 (german)

Same here. I'm happy with the full-Debian setup.
I will also convert my first VDR system from disk-based to diskless (it 
already stores recordings on the NFS share). The second diskless system 
is good enough.

The little EPIA EK8000 running as the server is good enough to serve 
multiple NFS clients + diskless boots + my 2 VDRs (2 recordings + 2 
replaying at the same time, from both VDRs).

-- 
NH

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

Re: [vdr] Mid range CPU choice

[Nicolas Huillard]

Simon Baxter a écrit :
 Simon Baxter a écrit :
 I'd like to go fanless and cool.  What I like about the shuttle is it's
 size.  The 1x PCI is fine, as is the VIA unichrome VGA  s-video out.

 Any ideas on a small compact fanless (DEAD quiet) case  motherboard??
 * mobo : compact + fanless = VIA (new EX is really well suited for a
 VDR; someone already talked about this one on the list)
 * case : Antec Fusion / NSK2400
 (http://www.silentpcreview.com/article698-page2.html), the bare case is
 available anywhere at ~90€ (http://www.ldlc.com/fiche/PB00038035.html)
 * a really silent power supply is laptop-like : PicoPSU
 (http://www.thinkitx.com/alimentations-80-10-c.html) + AC-DC block.
 * a single slow silent fan can cool all that
 
 Nice setup - but the case is too big for me.  I have a single glass panel 
 shelf, the case can be 11.5 deep maximum.. 

I went for a heavily customized CD player... Count 1-2 days drilling and 
cutting to fit the mobo inside, with all planned before that.

-- 
NH

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

Re: [vdr] Mid range CPU choice

[Nicolas Huillard]

Simon Baxter a écrit :
 I'd like to go fanless and cool.  What I like about the shuttle is it's 
 size.  The 1x PCI is fine, as is the VIA unichrome VGA  s-video out.
 
 Any ideas on a small compact fanless (DEAD quiet) case  motherboard??

* mobo : compact + fanless = VIA (new EX is really well suited for a 
VDR; someone already talked about this one on the list)
* case : Antec Fusion / NSK2400 
(http://www.silentpcreview.com/article698-page2.html), the bare case is 
available anywhere at ~90€ (http://www.ldlc.com/fiche/PB00038035.html)
* a really silent power supply is laptop-like : PicoPSU 
(http://www.thinkitx.com/alimentations-80-10-c.html) + AC-DC block.
* a single slow silent fan can cool all that

(~60W peak power from the wall on my VDR : VIA C3 1GHz + HDD + running 
DVD + hardware MPEG2 decoding + 1 DVB-S PCI + 1 DVB-T USB)
(48VA full load on my home server, with 2 x HDD, EPIA EK-8000)

-- 
Nicolas Huillard
[EMAIL PROTECTED]
Fixe : +33 1 39 27 06 10
Mobile : +33 6 50 27 69 08

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

Re: [vdr] Mid range CPU choice

[Nicolas Huillard]

covert covert a écrit :
 My question is what CPU should I chose for good noise reducing , heat
 reducing solutions.

The most efficient CPU are still the VIA ones... Low power, very low 
heat, very low noise.
There are lots of EPIA mobos (Mini-ITX for factor) with fanless CPUs 
around. With these, you get only one PCI slot, but everything is 
integrated on the motherboard.
Using a good laptop-like power block (efficient and fanless), you can 
have a really silent setup (one slow fan for the whole system).

 For processing power and cost I am looking at AMD AM2 4000 and Intel
 Duel Core E2140 and Intel core2 Duo E4400. I am open to other
 suggestions as long as they can currently be purchased in store.
 
 Since the system will be spending 95% of it's time idle I want a CPU
 that can drop down to the slowest possible clock speed with the least
 power consumption. I will also be using temperature controlled fans to
 keep it real quiet and any other ways I can find to drop down power
 and noise.

Drop noise:
* suspend the disk drive with rubber bands
* carefully design the air path inside the case

-- 
NH

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

[vdr] Is the remote control of a WinTV Nova-T PCI able to power on the computer

[Nicolas Huillard]

Hi all,

The subject says it all. Since the PCI card has an always-lit LED on it, 
I wondered if the IR receiver was also powered and could turn on the 
computer, using the green power button on the remote.

Since it's not working for me, are there any BIOS settings to allow that ?

TIA,

-- 
NH

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