Hi Dischi, I wrote the below when I'd only had a brief look at HTS TV Headend and when I'd already looked at and cast aside the tvserver on github as freevo 1 had already surpassed some of the functionality (although not the multiple recordings at the same time). I'd also rewritten the TV server to support a lot of the features in freevo 1 + multiple recordings including automatically rearranging recordings to ensure maximum guard times at the start and end.
However, I've now got TVHeadend up and running proper and I'm rapidly coming to the conclusion that the best use of our resources would be to help extend it and use it as our sole TV server. As you point out we haven't had a large developer base and so it makes to sense to pool ours with XBMC etc who are already using TVHeadend. Cheers Adam On Thu, 2013-02-14 at 09:03 +0100, Dirk Meyer wrote: > Hi, > > On 11.02.2013 14:58, Adam Charrett wrote: > > So here's the ideas that have been floating around for a while, some > > already exist in Freevo 1 and I think must be incorporated into Freevo 2, > > others are new. > > Let me start with a basic layout. We have a Freevo GUI that communicates > with a TV server for recording and live playback. I started with a > Freevo TV server and it has many features already implemented -- it > lacks support for live TV and an actual Freevo integration. It works > fine stand alone (or it worked, I did not use it for a long time). Since > Freevo 2.0 is more or less a one man show I tried to make it simpler and > TV support was one of the things I had no time for. > > This means I want Freevo to integrate with a TV server in a general way. > You can use the TV server you want. IMHO TVHeadend does many great > things so I wanted to start there. > > /-> TVHeadend > Freevo -> generic backend -| > \-> Freevo TV server > > So from Freevo's point of view a real Freevo TV server is no different > than TVHeadend. I will write the generic code and the TVHeadend stuff > and maybe someone can take over the TV server code from git and make it > a better TV server. > > > 1. The new TV server/manager should allow plugins and make extensive use > > of signals (or less likely events). > > The main reason behind this is that its much easier to compartmentalise > > new features in this way that will hopefully prevent them from breaking > > existing code. The hope is that once we have a nice shiny new tv server > > someone will come along with a good way of using the different signals to > > allow new features that we haven't thought about (and some that we may > > have like for example auto-recording based upon what has been recorded and > > watched etc). > > Agreed > > > > > 2. The TV server/manager should manage all aspects of the TV > > viewing/recording use cases. > > By this I mean that it should deal with the recording side (by allocating > > devices to use for recording) and the viewing side (by also allocating > > devices for live viewing and keeping track of what recordings have been > > viewed). It this respect I am envisaging the Freevo 1 Recording Manager > > (that collapses series recordings into a single 'directory' entry > > automatically and also allows a recording to be marked for keeping or as > > watched) to be integrated into the new server. > > Take a look at the TVServer code. There is one master TVServer and > several client providing devices. You schedule a recording on the TV > Server and it chooses the best client (e.g. a client with a DVB-C card > has a higher rating than one with a DVB-T card). > > Code: https://github.com/freevo/tvserver > > It uses kaa.epg and dvbstreamer > > 3. On the API side, when making an event/program based bookings lets use > > the unique id from the kaa database to do the booking. ie Only passing > > this integer to the server rather than passing an object containing the > > start/end times, title and description etc. This has a couple of > > advantages, first is the reduction in network traffic and second and more > > important is if that event is updated after a schedule update the > > recording also gets the updated information rather than the snapshot when > > the booking was made. > > Agreed. That should be inside the Freevo plugin for the TV Server and > the server itself. TVHeadend does it a similar way. > > > 4. The TV server should provided conflicting programs information. > > This is very definitely a WAF killer if its not available. Freevo 1 > > provides this already and the code I've been working on also does although > > I'm not convinced I've got the display/resolution side of things 'right' > > yet as it currently shows the recordings based on what tuners they are > > currently assigned to. What I think we want to do here is provide a list > > of conflicting programs and then allow the use to deselect those they > > don't want and 'try' the scheduling operation again. > > See the current code, most stuff is already there. > > > Dischi > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Freevo-devel mailing list > Freevo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freevo-devel ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
