+- 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)
- tafypz - 2010-10-19
outleradam Wrote:This method may break in 0.25 when the recordings/guide databases are changed.
I understand what is entailed by going straight to the DB and the future updates but as it was previously mentioned there is not one single interface that allows us to create a recording schedule right now.
I don't want to sound like a d**k, but I am growing tired of the people trying to ram Python down the throats of the few developers writing the mythtv pvr addon.
As it was previously mentioned (many times), there is no way right now to create a PVR addon in anything but C++. If people want to use python, right now only regular addons are supported and Analogue has created mythbox . While I understand the intentions behind pushing Python and that no ill is meant, it is not possible right now.
I am only speaking for myself but if anybody wants the pvr addon to be develop in python, create the pvr addon framework that will allow pvr addons to be written in Python submitted in svn and I will gladly use it. For now it is not possible to do it in python, it is going to be C++.
I understand that the posters may not know C++ and are willing to help using Python (and I appreciate that) but guys from my point of view, it is getting reallly old...
- karatekickz - 2010-10-19
Great thread. Great discussion. I am always so amazed with all of your knowledge.
For the guys interested in the python end, you would be the perfect people to implement the python UPNP stack to mythtv. Most of the work is already implemented in Coherence Python UPNP stack http://coherence.beebits.net/ . You can read some of my earlier posts as to the many benefits of this option.
You would be adding a lot of functionality to mythtv (Live TV, to any UPNP/DLNA compliant device) and at the same time abstracting the mythtv backend logic for the XBMC devs. The XBMC PVR devs could then simply invoke UPNP methods in the language of their choosing for the PVR functionality.
I would be interested in helping in any way possible for this to happen.
- wagnerrp - 2010-10-19
karatekickz Wrote:For the guys interested in the python end, you would be the perfect people to implement the python UPNP stack to mythtv. Most of the work is already implemented in Coherence Python UPNP stack http://coherence.beebits.net/.
Any UPnP implementation in MythTV is going to be written in C++/Qt, using the existing Myth libraries. The backend already exists as a server daemon, and there is no reason to write a new one from scratch in a completely new language just to run UPnP.
- tafypz - 2010-10-20
Thanks to wagnerrp, I should have a first shot at the Schedules (or "Timers" in pvr addon lingo) this week end. I am in the process of creating libmythsql, I am following the same pattern put in place for libmythxml to do so. I have also added a few methods to libmythxml to get the MySql Connection info and getting the data from the settings table.
The libmythsql has a main facade a la MythXml called MythSql which takes the dbschema version as an argument to its constructor. This MythSql will then call the appropriate version of the command (which wraps the SQL query and response processing like in mythxml). There will be a different command for each DBSchema version (if the underlying table has been modified). I am using mysql/mysql.h which is one of the libs required to be on the system to run xbmc.
I will update the mythxml patch tonight or tomorrow to provide the few new commands I added and will provide the mythsql patch this week-end.
if somebody is already running 0.24, can the person send me a PM with the record table schema and the DBSchemaVer value from the settings table.
This will allow me to see if there are any differences and code it accordingly.
Right now my development is done against the latest 0.23.1 from svn.
I forgot to mention that the scheduler portion (which is the responsible for updating the info from the db) will have to be called, unfortunately the libcmyth is not in the pvr addon yet. my code will therefore just create and retrieve the db records.
- karatekickz - 2010-10-20
wagnerrp Wrote:Any UPnP implementation in MythTV is going to be written in C++/Qt, using the existing Myth libraries. The backend already exists as a server daemon, and there is no reason to write a new one from scratch in a completely new language just to run UPnP.
I am completely aware of the C++ implementation of UPNP in myth. UPNP does not seem to be something the dev team values as a priority. Which is a shame as imo UPNP could be the protocol for Front/Backend communication rather than a hodgepodge of the ever changing mythXML, myth protocol etc.
Currently, the C based upnp stack is written from scratch rather than relying on the reliability of the other preexisting C based stacks. Live TV is not supported in any form even though it's been talked about for years. The ScheduledRecording upnp schema has also not been implemented nor talked about by the devs.
Separating the upnp server from myth also allows for other uses such as running the upnp server on an always on Router or NAS and using wake on lan (WOL) to wake up the myth server for recording or live tv etc.
For all these reasons, I feel a complete rewrite could be appropriate for someone interested in implementing the full DLNA/UPNP spec to take myth to the next level of interoperability in the home.
- tafypz - 2010-10-20
karatekickz Wrote:I am completely aware of the C++ implementation of UPNP in myth. UPNP does not seem to be something the dev team values as a priority. Which is a shame as imo UPNP could be the protocol for Front/Backend communication rather than a hodgepodge of the ever changing mythXML, myth protocol etc.
Currently, the C based upnp stack is written from scratch rather than relying on the reliability of the other preexisting C based stacks. Live TV is not supported in any form even though it's been talked about for years. The ScheduledRecording upnp schema has also not been implemented nor talked about by the devs.
Separating the upnp server from myth also allows for other uses such as running the upnp server on an always on Router or NAS and using wake on lan (WOL) to wake up the myth server for recording or live tv etc.
For all these reasons, I feel a complete rewrite could be appropriate for someone interested in implementing the full DLNA/UPNP spec to take myth to the next level of interoperability in the home.
Don't get me wrong, this would be great but I think that this is something you need to discuss with the mythtv devs. From a service consumer point of view unless I am mistaken there is no support for commercial skipping in the upnp mediaserver spec. If one would want to use commercial skipping, it would entail writing a hybrid upnp / direct client approach (I don't know how clean this would be).
- wagnerrp - 2010-10-20
karatekickz Wrote:Separating the upnp server from myth also allows for other uses such as running the upnp server on an always on Router or NAS and using wake on lan (WOL) to wake up the myth server for recording or live tv etc.
There are plans by one of the backend guys to split mythbackend in half. One would be the scheduler, upnp server, embedded database, web-based setup, and possibly internalized mythweb (instead of through Apache). The other would manage tuners, and the storage to go with those tuners. The jobqueue would probably only exist as an independent process, as it currently does with mythjobqueue.
This would allow people to run the tunerless, always-on backend they've asked for for some time, but that does not open the possibility to run on a router or embedded NAS box. Those systems simply don't have the memory to run a sizable relational database or web server. The larger 'plug computers' still don't have the computational capacity to run the scheduler as is desired.
karatekickz Wrote:I am completely aware of the C++ implementation of UPNP in myth. UPNP does not seem to be something the dev team values as a priority. Which is a shame as imo UPNP could be the protocol for Front/Backend communication rather than a hodgepodge of the ever changing mythXML, myth protocol etc.
Currently, the C based upnp stack is written from scratch rather than relying on the reliability of the other preexisting C based stacks. Live TV is not supported in any form even though it's been talked about for years. The ScheduledRecording upnp schema has also not been implemented nor talked about by the devs.
UPnP is little more than a bit of multicast used for auto-detection of an HTTP server, along with a set of standard XML calls. MythTV already had an existing HTTP server, so the UPnP functionality was built around that, rather then pulling in an external dependency, or pulling another library into the repository, and having to run on a separate port. No one will argue that there are significant deficiencies in the existing server, but there was reason for doing it the way it was.
The backend protocol could never be replaced by UPnP. The frontend currently pulls far more information than is available through the limited set of calls specified by UPnP. The most you could achieve would be to exchange one custom interface with a custom data format, for one using XML. There has been talk about moving to a more standard format, but it has been centered on ProtoBuf, not XML.
- wagnerrp - 2010-10-20
tafypz Wrote:From a service consumer point of view unless I am mistaken there is no support for commercial skipping in the upnp mediaserver spec.
One of the devs has a semi-functional branch for doing just that. You are correct that there is no specific protocol for adding skips in a UPnP client, but there are ways around it. He is essentially splitting the recording into multiple files, and stitching it together with a playlist. The problem he is having is that after removing chunks of video, the timecodes are wrong, and it is causing issues with playback on some devices.
As I understand it, that is the only way to handle variable content, such as live TV and in-progress recordings.
- tafypz - 2010-10-20
wagnerrp Wrote:One of the devs has a semi-functional branch for doing just that. You are correct that there is no specific protocol for adding skips in a UPnP client, but there are ways around it. He is essentially splitting the recording into multiple files, and stitching it together with a playlist. The problem he is having is that after removing chunks of video, the timecodes are wrong, and it is causing issues with playback on some devices.
As I understand it, that is the only way to handle variable content, such as live TV and in-progress recordings.
Thanks for the heads up
- dteirney - 2010-10-21
tafypz Wrote:Thanks to wagnerrp, I should have a first shot at the Schedules (or "Timers" in pvr addon lingo) this week end. I am in the process of creating libmythsql, I am following the same pattern put in place for libmythxml to do so. I have also added a few methods to libmythxml to get the MySql Connection info and getting the data from the settings table.
The libmythsql has a main facade a la MythXml called MythSql which takes the dbschema version as an argument to its constructor. This MythSql will then call the appropriate version of the command (which wraps the SQL query and response processing like in mythxml). There will be a different command for each DBSchema version (if the underlying table has been modified). I am using mysql/mysql.h which is one of the libs required to be on the system to run xbmc.
I will update the mythxml patch tonight or tomorrow to provide the few new commands I added and will provide the mythsql patch this week-end.
Another option would be to add the SQL function into libcmyth. I'll look at moving the existing libcmyth code to the addon over the weekend. There is already a number of areas in libcmyth that use SQL to communicate with the backend.
Since the Myth Protocol call is needed to get the scheduler to run that might make sense as well.
Carry on working as you are and I'll have a look at whether the SQL statement can be worked into somewhere sensible in libcmyth.
- dteirney - 2010-10-21
PhracturedBlue Wrote: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.
Yes, I was thinking something like a static variable as well. The gain is not seeing lots of errors in the mythbackend.log file due to a protocol version mismatch on connection. Many people think that the way XBMC is connecting to the backend is broken because of the errors in the mythbackend.log file. Reducing the number of errors in the log to just one per XBMC usage session would help mitigate that and be one less ping / pong per connection setup.
- dteirney - 2010-10-21
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.
All of these patches are now committed to XBMC SVN trunk. Thanks so much for your great work on this. If anyone else is using a "soon to be Myth 0.24" backend from MythTV trunk or similar, can you please test and see if you run into any problems.
- wagnerrp - 2010-10-21
PhracturedBlue Wrote:I have added support for MythTV 0.24 (well assuming they don't change the protocol in svn between now and then)
We've been in feature freeze for weeks, and one RC is already out. Fairly safe to assume 0.24 will ship with version 63.
- outleradam - 2010-10-21
I built MythTV from head last night. Just for notes, if anyone tries to build MythTV head, MythFrontend is experiencing random problems with VNC right now, but worked over ssh -X. If you use frontend, I would not recommend building from head. MythWeb and MythBackend are working fine.
I will build XBMC on a virtual machine from SVN and test later tonight. Expect results from 0.24 around 1900CST, unless someone else beats me to it.
- tafypz - 2010-10-21
@wagnerrp: do you know if the upcoming recording list can be created via sql or is it something that needs to be accessed through the scheduler via the protocol (if there are any such command)
Thanks