On 13/12/2010 08:21, Eric Valette wrote:
On 12/12/2010 23:44, Klaus Schmidinger wrote:
I always find it amusing how people consider the GUI so important.
Come on! It's a *video recorder* for cryin' out loud! It's main
purpose is to record and replay tv broadcasts.
I know its the main purpose but do not forget that in order to record,
you need to correctly tune the adapter. So its also a DVB tuner. Once
tuned, you can direct the stream on disk but also elsewhere. That's the
primary purpose of the streamdev extension.
I rarly see VDR used standalone...
Now that the coffee has done its desired effect on my brain, I think
this discussion deserves a bit more object oriented style high level
analysis.
What is recording? for me its TUNING the adapter, AT A GIVEN TIME, and
REDIRECTING the adapter stream to a media..
Regarding TUNING: The initial generation of the channel.conf file is not
part of VDR itself. VDR helps reanalysing the channel.conf by tuning and
analysing the stream to find the apid, vpid, teletex, ... Why is the
initial tuning handled externaly and then finalysed? Its a primary
function right? I do not care if w-scan is extended for correct HDTV/S2
generation of if its incorporated. But VDR is not self sufficient for
that function.
AT A GIVEN TIME: then comes the questions of
1) how do you know there is something you want to record
2) when it is?
3) how simple is it to do?
For people familiar with paid TV dedicated devices, most of the time it
relies on extended EPG database and search function in it. Again this is
not part of VDR itself as EPG handling and search is external. Plus in
france, the actual EPG handling is not sufficient. And broadcaster is
the state for some channels so I can try to complain but will probably
not obtain much...
REDIRECTING the stream: To a file. OK. Its part of VDR. I would have
liked to be able to record to something else than mpeg2ts because of the
audio/video synchronisation, lack of metadata, ... Both problems are
being addressed by the naming of the record location, the info file and
the recording of the I frame location. Using a .mkv would have been more
efficient especially for playback outside VDR... Then of course we also
may want to redirect the stream on a socket for network streaming using
a dedicated protocol. This part is again not part of VDR itself but
comes with streamdev, vnsi, but with the extra cost of duplicating
demuxer code.
Then of course, you should think on how you expose the core
functionality outside of VDR.
So I think the analysis og basic function in VDR do deserve a bit more
attention.
And do not misunderstand me: I'm glad VDR exist but I spend really to
much time trying to incorporate it in a decent looking HTPC environment.
And Klaus, thanks for your support I would not have managed without it.
I'm not entirely satisfyied by the result and the main missing part are:
1) decent looking GUI,
2) EPG
I started looking at tvheadend because:
1) channels.conf generation is incorporated somehow (in a way that
fails for me ;-)) But using w-scan to find the transponder you can
manage it,
2) It has support for xmltv (not yet tried)
3) It has been designed with a video streaming perspective
4) It also has an build-in live equivalent and recording
5) XBMC has native streaming protocol for it not yet for VDR,
Unfortunately, it still suffers for some bugs for HDTV support.
Life is always complicated.
--eric
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
