Dirk Meyer wrote:
Rob Shortt wrote:
We will also need some diseqc support.
What is this?
http://en.wikipedia.org/wiki/Diseqc
Most people use a diseqc switch to connect their DVB card to 2-4
satellite dishes or LNBs.
I have also written code for retrieving EPG data from DVB.
We also have code pieces for that already.
Great. I will forward the stuff that I have to the list so you can look
at it if you like.
o How to support a network for recorder
o How to get data without using NFS
o Different ideas (Raw UDP/RTP/HTTP)
o Where to use the chunk file system
o How to sync EPG data
o How to autoconfigure the system
I have some ideas on these items too. We can discuss these in more
detail when you send the email.
OK, here some details.
Worst case: we have 4 different PCs. One for Freevo, one for the
recordserver, one for the recorder and one with all the harddrives and
NFS. We can't just record into a file, because the GUI will see the
new files too late because of NFS. So we need some sort of streaming,
but also need the file chunks for temp storage.
GUI -> recordserver: I want to watch TV at channel X
recordserver checks which recorder to use
recordserver -> recorder: Record something with live tv output
recorder -> recordserver: here is an url
recordserver -> GUI: here is an url
There are two possible ways of using the network:
1. Add a HTTP server inside the recorder. The recorder will save the
chunks over NFS, but it will also read the files. Since it is the
same machine, no NFS delays due to local caching.
The recorder will return an url to connect to to get the
data. Mplayer can seek in HTTP streams. But I have no idea if this
also works when the file is still growing when watching. Also it
may be a problem when you want to seek after current time.
2. Send data via UDP. We will need to add time shifting into the
client. The recorder will send the raw data over UPD, maybe
multicast, maybe also in RTP.
The client will receive the data, show it and store the data as
file chunks to make live pause possible.
I prefer 2., but it will require changes to the player. I guess it
will be easier to change xine, so we will focus on xine for now. Maybe
a python program can receive the data nd store it as normal file to
support all kinds of player. This would require a special kaa.record
device to receive UDP data.
I prefer 2 as well. Creating an op_udpraw plugin for kaa.record should
be simple, and something for capturing it on the client side and writing
chunked files should me ok as well. I don't know how hard it would be
to get xine to use chunked files as input BUT IIRC I had xine
successfully doing timeshifting with raw udp input. :)
Now to the epg. The recorder can get EPG data while it is idle. It
could save the data somewhere and has a webserver
http://recorder:888/epg to make it possible to download the epg as
xmltv.
Now we need to sync our databases between the machines. The master is
always the recorderserver. It will query the recorder for the EPG from
time to time to keep the db up to date. It will have a special version
attribute. E.g. the current version is 3. Now the recordserver also as
an url to receive the database as xmltv listing. The GUI on a
different machine will recive the data and adds it to its own
db. After some time
GUI -> recordserver: get db version
recordserver -> GUI: 3
Nothing happens. Now the recordserver updates its epg. The version
will be set to 4 and all new programs will get a flag '4'
GUI -> recordserver: get db version
recordserver -> GUI: 4
GUI -> recordserver: get db > 3
recordserver -> GUI: http://recordserver:1234/specialurl
and the GUI can receive the update.
That's an interesting way of dealing with the EPG. I wonder how much
overhead would be involved. Also I'd suggest not to use XMLTV to share
guide data internally as parsing it takes too much CPU+memory.
I was thinking something a little different for the EPG. I would like
to have a single point on the network for the EPG, as an mbus app.
Using some client protocol that we define, various Freevo frontends
would query the EPG process for guide information. In addition to this,
authorized clients (DVB recorder, or tv_grab helper on another machine)
could supply the EPG process with new data. The EPG process itself
could also be responsable for running an internal tv_grab at specified
intervals.
-Still thinking...
-Rob
--
-------------------------------------------------------
Rob Shortt | http://tvcentric.com | Freevo
[EMAIL PROTECTED] | http://freevo.sf.net | Free your TV
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
