Kodi Community Forum
MythTV PVR client Addon Developers Wanted - Developers Only! - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=26)
+---- Forum: PVR (https://forum.kodi.tv/forumdisplay.php?fid=136)
+---- Thread: MythTV PVR client Addon Developers Wanted - Developers Only! (/showthread.php?tid=82015)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35


- tafypz - 2010-10-18

PhracturedBlue Wrote:I have added support for MythTV 0.24 (well assuming they don't change the protocol in svn between now and then)

The ticket is:
http://trac.xbmc.org/ticket/10535

The 2 big changes were:
57: significant changes to proginfo structure
62: add token system.

FYI, a reasonably correct list of protocol changes can be found here:
http://www.mythtv.org/wiki/Category:Myth_Protocol

I didn't verify all of libcmyth's capabilities to be compliant, but at least the ones used to read from proginfo and to fetch recordings are now working.

Awesome, I hopefully will be able to try out the recording schedule functions tomorrow


- dteirney - 2010-10-18

wagnerrp Wrote:The only complaint we have with libcmyth is its handling of the protocol check. It doesn't limit connection to a single protocol version, or even a range of versions. Rather, it blindly repeats back the version the backend says it is in order to force a connection. This is very dangerous behavior, and so the additional token check in trunk was added to ensure 3rd party libraries have actually been updated to speak what they claim to.

In contrast, the connection classes used by the MythBox plugin are an example of how to do things properly. It has multiple classes for different ranges of protocol versions, in order to properly handle differing ProgramInfo sizes and command arguments.

libcmyth is definitely not a shining example of how to deal with the changes that have been made to the Myth Protocol. The "if protocol version > X" statements are ugly as sin. And yes, the library doesn't check that it definitely supports the version the backend reports which is nasty. Still it's a better starting point than nothing and at least understands the somewhat proprietary protocol format.

@PhracturedBlue, not sure how much you looked into the connection code, but is it possible to not do the "Ask for the backend protocol version using version 8" for every single connection. From my loose understanding, we need to know what protocol version the backend supports, because you can't ask to use protocol version X when connecting to the backend. The library should only need to do that once though.


- dteirney - 2010-10-18

analogue Wrote:I'll throw my hat in the ring since the pvr add-on is starting to see lots of activity now. It has been quite a while since I've done c/c++ but it should be interesting. First things first...need to get setup under Eclipse to edit/compile/test. Anyone using eclipse?

I'm using Eclipse CDT. Details albeit pretty lacking on http://wiki.xbmc.org/index.php?title=Eclipse_CDT_Setup_For_XBMC_Development


- dteirney - 2010-10-18

waldo22 Wrote:Have you been following what jfcarroll has been doing with addons in multiple programming languages here:

http://forum.xbmc.org/showthread.php?tid=80984

Does that change the situation any?

-Wes

Not right now. Most of that work is to expose the existing Python API and there isn't any Python API for the PVR area.

Maybe in the future it will be possible, but for the meantime, C++ is where it's at. There are enough library parts available that the solution can still be done in C++, just means that we can't use the MythTV Python API and we need to make a few improvements to libcmyth along the way.


- PhracturedBlue - 2010-10-18

dteirney Wrote:@PhracturedBlue, not sure how much you looked into the connection code, but is it possible to not do the "Ask for the backend protocol version using version 8" for every single connection. From my loose understanding, we need to know what protocol version the backend supports, because you can't ask to use protocol version X when connecting to the backend. The library should only need to do that once though.

This should be possible, though it is beyond the scope of my current patch. I'm not sure there is much gain. You can't ask myth for its protocol number before connecting, so you only save one connection attempt by caching the version. A static variable would be really crude, but likely trivial solution for this.

libcmyth is pretty kludgey, and only works because the protocol only rarely changes significantly. replacing it with something better would be nice, but also a huge amount of work.


- outleradam - 2010-10-18

Well... um.. I'm going to take a quick stab here at using the python bindings in C++... keep in mind I've only done a hello world app once and that was 4 years ago...
Code:
#include <stdio.h>
#include <stdlib.h>
int main ()
{
  char string;
  printf ("Obtaining python variables");
  char=system ("python MythTVtoXBMCPythonBindings.py --GimmeDatabase");
  printf ("This file is output in var=value format and should be declared as variables and will also include handling messages from py to be interperated: %d.\n",char);
  return 0;
}

Dunno... Whacha think?


- PhracturedBlue - 2010-10-18

outleradam Wrote:Dunno... Whacha think?

That's going to be pretty inefficient. You'd be better off using the built-in python interpreter in xbmc instead. Unfortunately, the interface from c++->python isn't very robust as far as I can tell(the python bindings in xbmc are really meant to make xbmc capabilities available from python, not the reverse)

I'm not sure exactly what you are trying to get at, but overall, it will probably be cleaner and easier to re-implement the python code in C++ than to try to call to it and build yet another interface layer.

Also, I'm not an expert in python, so perhaps there are other interface mechanisms I'm not aware of.


- outleradam - 2010-10-18

Well, the main thing is that MythTV takes care of their python bindings. Every version of the database gets a new version of python bindings. Basically, from a developers standpoint, you just have to support MythTV Python Bindings and they support MythTV. This is my reason for switching to python bindings in mythicalLibrarian and going with a statement like the following.
Of course BASH is quite a bit simpler then C++:
Code:
mkfifo dbOut
pythonBindings.py --filename="myfile.ext">dbOut
while read var equals value
do
    test "$equals" = "=" && declare $var=$value
done<DBOut
MovieAirDate=$airdate; OriginalAirDate=$originalairdate; ShowCategory=$category; Stars=$stars; Plot=$description; Zap2itSeriesID=$seriesid; ProgramID=$programid; ChanID=$chanid; ShowStartTime=$starttime
And now everything is dumped from database into a series of variables of the same name.

I look at it like this, it may be an extra step, but that step is what keeps things working as they should throughout the different versions without modification to the more difficult programming.

Again, I'm not good with C++, and I don't know what works in C++. Just trying to help.


- PhracturedBlue - 2010-10-18

I understand the reasoning. I was all for this approach too (using the python bindings, since myth actually provides them rather than libcmyth which we need to support ourselves). If we could write the add-on in Python it would be a no-brainer since both xbmc and myth bindings would be available, but apparently that isn't possible. I don't understand the limitations that prevent that from being possible.

Maybe there are compelling enough reasons to use the python bindings rather than libcmyth, but if so, I think it would be better to find a more integrated route than using a system call for each query.

Dteirney knows this stuff a lot better than me. I'll refrain from further comment until he weighs in.


- outleradam - 2010-10-19

See, I'm kinda picturing the PVR addon to work something like this:

Image

http://i236.photobucket.com/albums/ff111/DrivingTibNaked/XBMCPVR.png

Leaving the .PVRs as addons in Python would be the best option. Basically abstracting everything and leaving it up to the programmer of each PVR addon.

And, from what I'm reading here, the .PVRs could be written in python to work with C or C++: http://docs.python.org/release/2.5.2/ext/intro.html
or java: http://www.jython.org/
or .NET: http://pythonnet.sourceforge.net/


- dteirney - 2010-10-19

PhracturedBlue Wrote:I understand the reasoning. I was all for this approach too (using the python bindings, since myth actually provides them rather than libcmyth which we need to support ourselves). If we could write the add-on in Python it would be a no-brainer since both xbmc and myth bindings would be available, but apparently that isn't possible. I don't understand the limitations that prevent that from being possible.

Maybe there are compelling enough reasons to use the python bindings rather than libcmyth, but if so, I think it would be better to find a more integrated route than using a system call for each query.

Dteirney knows this stuff a lot better than me. I'll refrain from further comment until he weighs in.

Here are the facts as I know them.
1) The XBMC PVR Addon interface is a C++ only interface at the moment. I don't know all the details for why that is, but it's not trivial exposing a Python version of that interface. I've talked with some of the other devs in the team IRC and they have all suggested getting it to work in C++. Fundamentally, the logic of the data conversion between the MythTV view of the data and what XBMC needs has to be understood regardless of programming language used.

2) MythTV exposes some APIs that 3rd party applications can make use of. MythXML is one, MythProtocol is another and the Python Bindings are yet another.

3) MythXML can be "talked" to pretty easily from C++. Tapypz already has all of the MythXML interfaces that can be used for the PVR Addon working. I just need to start commiting a bunch of that work.

4) MythProtocol can be "talked" to via libcmyth (assuming all the MythProtocol methods have been implemented, and there's a possibility they haven't). PhracturedBlue has already done the necessary work to at least get this to communicate with a 0.24 backend. I just need to put these patches in.

5) The HTTP API within MythXML can be used (as is by tafypz) for playing back recordings. Hopefully seeking works well still.

6) There is still a list of functions that need to be implemented somehow by the PVR Addon to complete the solution. Some of those haven't even been identified as having solutions using Myth Protocol. For example, how does a Recording get scheduled via any interface? The Python Bindings (http://www.mythtv.org/wiki/Python_bindings) don't seem to have anything based on the docs, and the SCHEDULER_ADD_RECORDING method in Myth Protocol (http://www.mythtv.org/wiki/Myth_Protocol) seems to have been deleted if the wiki page is accurate.

If the community wants a PVR Addon for MythTV within the coming months then C++ seems to be the only road with an unobstructed view to the end goal.


- outleradam - 2010-10-19

dteirney, I understand that we want to get this done quickly.

The MythTV 0.24 Python Bindings (head) wiki page has much more information about the new python bindings. They've enhanced many aspects of the new python bindings which were torn down and rebuilt during development cycle 0.22-0.23. Although I can't search the MythTV website from work as it is categorized as streaming media and blocked, I can tell you that there is a separate documentation page for the enhanced 0.24 Python Bindings. The 0.23 Python Bindings did not have enough information for mythicalLibarian previously, but the 0.24 have more then enough.

We really should look at storing guide data in XBMC. This would allow for freedom of processing displayed data. There is an enormous amount of data available in the guide and when combined with what we have currently, this would allow for better identification and overall user experience.

Guide data could be processed to display season and episode information on request. This would allow for artwork to be downloaded and all the features of the video library to be available to the user while watching a video.

This would simplfy the process of requesting information from the back-end as we would already know what we want from every back-end.

Of course, in order to get information from the back-end, it would require one of the following:
1. export from backend/database
2. XMLTV/SchedulesDirect processing/channel scanning
3. link to backend/database

Utilizing this would make it easy to request information from any backend. The .PVR's job would simply be to translate what XBMC PVR.frontend wants into data that the .PVR can handle.

As long as the front-end is truely a front-end, it should be a matter of establishing a universal communications protocal which identifies the 3 key features by means of universal identification methods. When the guide data source is the same, the identification will be the same.

Universal identification methods
Channel/time
frequency/time
Physical Channel/Program/time
Title/time
Title/Subtitle/time
Title/Original Airdate/time
ProgramID/time

In order to make everything unified as a single front-end to work with multiple backends, these interfaces need to be implemented. If not, then every PVR will be handled differently. For XBMC to truely be a unified front-end we need a set of standards to unify Front-ends.

Don't get me wrong. I very much appreciate the work the devlopers have done so far. It is nearly fully implemented. It should be expanded in the future so that we don't rely on having all the functionality of MythTV for every interface. Many PVRs do not have the same functionality of MythTV.


- wagnerrp - 2010-10-19

dteirney Wrote:For example, how does a Recording get scheduled via any interface? The Python Bindings (http://www.mythtv.org/wiki/Python_bindings) don't seem to have anything based on the docs, and the SCHEDULER_ADD_RECORDING method in Myth Protocol (http://www.mythtv.org/wiki/Myth_Protocol) seems to have been deleted if the wiki page is accurate.

There is currently no way to create a new recording rule completely through any one interface. The rule must be edited or created manually, through direct database manipulation of the `record` table. A scheduler run is issued with a RESCHEDULE_RECORDINGS call over mythproto, using the recordid to update a single rule, or -1 to update all. The command will respond immediately, and the end of the scheduler run can be detected with the SCHEDULE_CHANGE asynchronous event.


- tafypz - 2010-10-19

wagnerrp Wrote:There is currently no way to create a new recording rule completely through any one interface. The rule must be edited or created manually, through direct database manipulation of the `record` table. A scheduler run is issued with a RESCHEDULE_RECORDINGS call over mythproto, using the recordid to update a single rule, or -1 to update all. The command will respond immediately, and the end of the scheduler run can be detected with the SCHEDULE_CHANGE asynchronous event.

Thanks for the info, I will look into the SQL for creating the schedules.


- outleradam - 2010-10-19

This method may break in 0.25 when the recordings/guide databases are changed.