Author
Topic: Alternative to mythtv (Read 24791 times)

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 www.cadsoft.de/vdr/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

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).

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:

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:

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.

VDR is specialized for digital TV (with or without crypted channels using CI-Cams).There are many options to integrate PVR cards and with some patches bttv as well, but the primary feature is using digital tv (cable, dvb-t or sat).

Ei Gude wie,it is great news to here that another guy is working on VDR-implementation to Plutohome. I am using VDR for about 3 years now. My Pluto-installation is more experimental right now. I am concentrating on the VOIP-functions with Asterisk, but I also would like to see my VDR working with Pluto.I am located in Frankfurt am Main, and I am very interested in the current status of your project.

The only problem i have (which I told Burgiman about) is there are just no dvb-s cards available. Both Technotrend and Hauppauge stopped manufacturing them a few months ago, and the replacement models aren't going to be available until autumn, and then we have to wait for drivers. Argh. I'm quite excited to see vdr working because we have several European dealers who are begging us for a good solution for European satellite that integrates the epg guide from the satellite, like VDR. But i've been trying for months to get a dvb-s card. I have an AlphaCrypt CAM Module and a Premiere card on my desk. When I get it, they say we can stream High-def TV w/out re-encoding. the quality should be exceptional.

Yes, Burgiman (Andre) and I have been working on it a lot (Burgiman non-stop). .31 (out later today) includes a specialized VDR that uses a back-end server with our xine players as front-end for whole-house streaming pvr in high-def. The guide appears on the orbiters too.

There's still a lot to do (pause live tv, schedule recordings, etc.). But now that the basics are done that shoudl go fast.

Could someone who is experienced in VDR give us a little help. We are based in the UK and have installed Pluto 2.0.0.31 on a core and have a Technotrend DVB-T card in the core itself and two further cards in an MD. Everything seems to be have installed fine except that VDR as its is installed does not know anything about the local DVB-T channel setup. Could someone explain how we get that data into channels.conf etc?

Could someone who is experienced in VDR give us a little help. We are based in the UK and have installed Pluto 2.0.0.31 on a core and have a Technotrend DVB-T card in the core itself and two further cards in an MD. Everything seems to be have installed fine except that VDR as its is installed does not know anything about the local DVB-T channel setup. Could someone explain how we get that data into channels.conf etc?

Thanks in advance for your help.

Andrew

Hi,

Actually we have Hauppauge Nova-T 9002 cards not Technotrend cards (see syslog excerp below). I am not sure if this makes a difference.

As you can see from the syslog excerp below the cards are being recognized and the crivers loaded. However when we run w_scan (after stopping VDR) to pull in data for VDR's channels.conf we see the error below. Any ideas about why we are seeing this?