[vdr] Request: E parameter in channels.conf for epg scan

Eric Valette eric.valette at free.fr
Mon Dec 13 09:23:06 CET 2010


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




More information about the vdr mailing list