Re: Request: E parameter in channels.conf for epg scan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux