Archive > App Server Developers

Alternative to mythtv

(1/6) > >>

archived:
Hi,

after going into the deeps of plutohome (and understanding the structure) i begun to implement VDR (from Klaus Schmidinger) into my plutosystem.

As a hardcore VDR Developer iam sure that it gives me more flexibility and features as mythtv (TVmodul only). People who interested in the features-list look at newbielink:http://www.cadsoft.de/vdr/ [nonactive]
The plugin-list speaks for itself :)

The main advantage is the EPG-data handling of vdr (without external xml-grabbers, directly from satellitedata), the time-shift functions (8 recordings at the same time and viewing another tv-show on an Intel 1800Mhz) AND the STREAMING-plugin.....

:idea:  
Think about my solution:
I installed the dvb-drivers, firmware and VDRsources into the CORE/hybrid and configured it for live-tv and "streamdev-server".
At one MD (debian network boot) i installed the VDR without dvb-drivers (dummy dvb) and activated the "streamdev-client".
Works perfect! but without pluto-functions / orbiter screens ...


so, i need support from you - plutohome developers :)
I spoke with Aaron already and hope, that he will have a look at VDR.
Because of the big developer-community VDR is more powered and faster in development as mythtv. For me, switching to VDR is more comfortable and it has more features & functions...

:idea: let's think about my solution... :idea: iam already started the main-implementation for CORE -> MD Streaming and now, i need a track from the main pluto developers:

- How do i Design Orbiter-Screens with extra parameters to control VDR over sockets or telnet or LIRC or per emulated keys ?
  (HADesigner doesnt work anymore with missing fields errors)
- Where is the "Follow-me" bluetooth control implemented to control externel apps / or mythtv ?
...and so on ...

I will help and develop all the stuff for a nice pluto-plugin, when we will start it together :)

Regards,
Andre

archived:
Hi Andre,

Yes, VDR seems very impressive.  It fell below our radar because I don't think it works in the US--our satellite is encryped and their are no PC cards.  However, I've done installs in Europe with Myth and our analog cards and it's a total nightmare.  Not only the xmltv grabber, but also controlling the satellite box with i/r since every sat box maps channels differently.  So, it sounds like VDR is perfect for Europe, and the Americans will probably stick to Myth.  Fortunately, it's easy to have both.

First, create a Device Template called 'VDR' in category DCESoftware Wrappers/Media Players.  Check that it implements DCE, and check command groups: TV commands and Smart Media Player for now.  Add the event 'Playback Info Changed'.  Add "This device is controlled via category:      Category: Standard Orbiter".  This means it's parent device (which spawns it) will be an orbiter.  The on screen orbiter will take responsibility for launching VDR in one of our ratpoison windows.

Next, create a Device Template called 'VDR Plug-in'.  This will be a plug-in in the router that runs in the same memory space, and manages all the VDR devices.  It implements DCE, and check 'Is Plugin'.  Also add "This device is controlled via:      Device:DCERouter  Category: DCE Router".    Add the command group 'PVR' plugin.

Now, for both devices run: ./DCEGen -d [DeviceTemplate] from the DCEGen directory within the source tree.  That will create the projects in ../VDRxxxx.

For VDR do a: make bin, for VDR Plugin, do a: make so

Put both the resulting binaries in /usr/pluto/bin.  In Advanced, Devices, remove teh Myth Plugin from DCE Router, and add VDR Plugin, and remove Myth Player from under OnScreen orbiter, and add VDR.

Now, when you do a 'quick reload router', next time you choose TV it will use VDR instead.  So on to the implementation:

You can copy mostly from Myth Plugin/PLayer.  Starting with the plugin.  Add MediaHandlerBase as a 2nd base class.  The Media Plugin will call methods derived in there.  Put the ! after the //<-dceag tag (means DCEAuto generated).   Otherwise next time you run DCEGen for the plugin it will overwrite your change.  ! means 'leave it alone'.  Otherwise DCEGen overwrites, because you re-run DCEGen everytime you change the command specs (choose Merge to merge in changes).

    //<-dceag-decl-b->!
    class MythTV_PlugIn : public MythTV_PlugIn_Command, public MediaHandlerBase
    {
   //<-dceag-decl-e->

Add the mandatory implementations from Media Handler Base:

      /** @brief Each Plugin will create its own instance of MediaStream, so it can create a derived version with extra information */
      virtual class MediaStream *CreateMediaStream(class MediaHandlerInfo *pMediaHandlerInfo,vector<class EntertainArea *> &vectEntertainArea,MediaDevice *pMediaDevice,int iPK_Users, deque<MediaFile *> *dequeMediaFile,int StreamID)=0;
      virtual bool StartMedia(class MediaStream *pMediaStream)=0;
      virtual bool StopMedia(class MediaStream *pMediaStream)=0;

For the moment, just make CreateMediaStream return a new, generic stream.  You will likely want to create a more specialized one, like VDR Media Stream which has VDR specific information (like channel, satellite, etc.).  That way when VDR Plugin gets a command to move tv from one room to the next you can restore all the settings.  But for now just:

    return new MediaStream(pMediaHandlerInfo, pMediaDevice, 0, st_RemovableMedia,StreamID);

Then make a simple implementation of StartMedia:

bool VDR_PlugIn::StartMedia(class MediaStream *pMediaStream)
{
DCE::CMD_Start_TV cmd(m_dwPK_Device, pMediaStream->m_pMediaDevice_Source->m_pDeviceData_Router->m_dwPK_Device);
SendCommand(cmd);

DCE:: is a namespace.  If you have auto-complete, when you type DCE:: it will give you a list of all commands with the syntax for all the parameters.

In the register function, do this.  This find the media plugin, and registers your VDR plugin with it.  Since they are both plugins running in the same memory space, they can call each other's methods directly.  Normally all pluto devices run as separate programs sending messages over sockets (it's safer).  But for media, you normally need a plug-in that will have low-level access to the same classes that media plugin uses:

   m_iPriority=DATA_Get_Priority();
    /** Get a pointer to the media plugin */
    m_pMedia_Plugin=NULL;
    ListCommand_Impl *pListCommand_Impl = m_pRouter->m_mapPlugIn_DeviceTemplate_Find(DEVICETEMPLATE_Media_Plugin_CONST);

    if( !pListCommand_Impl || pListCommand_Impl->size()!=1 )
    {
        g_pPlutoLogger->Write(LV_CRITICAL,"VDR plug in cannot find media handler %s",(pListCommand_Impl ? "There were more than 1" : ""));
        return false;
    }
    m_pMedia_Plugin=(Media_Plugin *) pListCommand_Impl->front();

    m_pMedia_Plugin->RegisterMediaPlugin(this, this, XXXXX, true);


Note that XXXXX is the device template for VDR.  Last thing, add a record to DeviceTemplate_MediaType table in pluto_main database where FK_DeviceTemplate is the VDR, and FK_MediaType is 1 (Live TV).  Compile and put your binaries in place.  The RegisterMediaPlugin tells Media Plugin that your VDR_Plugin is responsible for managing the VDR devices, which accodring to the database, can handle live tv.

Now do a quick reload DCERouter, either from an orbiter, or send it a reload message: MessageSend localhost 0 -1001 7 1

When you watch the DCERouter logs (/var/log/pluto/DCERouter.newlog) you should see that it registers your VDR Plugin.  Also, if you do a screen -ls, a copy of VDR should be running, and you should see it registered in DCERouter's log.

Now hit 'tv' from an orbiter (not the onscreen display on the m/d--use an orbiter on another PC).  You should see in the VDR logs:
Need to implement CMD_Start_TV

This means everything is working.  And, on the orbiter you should see a pvr remote control.  As you tune channels, fast forward, rewind, channel surf, etc. you should see in the VDR logs all these messages.

Eventually we can create a new remote for VDR that has extra VDR-specific buttons.  But for now it's best to use the basic one because it's important that VDR implements the same 'smart media player' commands the same way, which is what ensures all remote controls (i/r, phone, tablet, etc.) will work the same way and provide basic control.

If you get stuck, I'll be happy to login and look at the code with you and help.  When you're ready, I'll show you how to do a sqlCVS checkin.  That will checkin your database changes.  And we'll checkin your code into our SVN as well.  That way our automated build system will start building your devices.

archived:
Hi,

I also thing that VDR is better long term choice, cause it's more plugin and remote control oriented... Mythtv is meant more for standalone systems and they are not moving from that paradigm....

But since I'm no programmer and know VDR even less, I can only express support for your work and help with testing if you need anything....

Regards,

Rob.

archived:
Hi Aaron,

i've been very busy last days, but this weekend i'll go with 100% power to the VDR-project :)

Did you get any dvb-card already and do you read my mail?

Regards,
Andre

archived:

--- Quote from: "burgiman" ---Hi Aaron,

i've been very busy last days, but this weekend i'll go with 100% power to the VDR-project :)

Did you get any dvb-card already and do you read my mail?

Regards,
Andre
--- End quote ---


Hi,

I'm looking forward to vdr pluto integration. But I'm curious whether analog bttv, PVR and dvb cards - all work with vdr ?

Regards,

Rob.

Navigation

[0] Message Index

[#] Next page

Sitemap 
Go to full version