+- 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)
- dubstar_04 - 2010-10-12
Guys I cannot thank you all enough for all the hard work you are doing on the mythtv pvr integration.
My c++ skills are poor and my studies and work don't allow me time or i would offer to get involved.
I am however more than willing to get involved with testing and supply feed back and bug reports if you will find this helpful.
I used to regularly build the pvr-testing2 branch to test but work has slowed on that, but hopefully when you guys have got to a point where you would like testing done i will be more than happy to do whatever i can.
I have just built the latest svn and i can confirm that all the channels are indeed loaded, in the correct order.
Is it wrong that i find this very exciting?
Thanks again,
Dubstar_04
- tafypz - 2010-10-12
dubstar_04 Wrote:Guys I cannot thank you all enough for all the hard work you are doing on the mythtv pvr integration.
My c++ skills are poor and my studies and work don't allow me time or i would offer to get involved.
I am however more than willing to get involved with testing and supply feed back and bug reports if you will find this helpful.
I used to regularly build the pvr-testing2 branch to test but work has slowed on that, but hopefully when you guys have got to a point where you would like testing done i will be more than happy to do whatever i can.
I have just built the latest svn and i can confirm that all the channels are indeed loaded, in the correct order.
Is it wrong that i find this very exciting?
Thanks again,
Dubstar_04
Thanks, we can always use people to test on different environments (in my opinion the more the merrier). I should have the EPG data in late tonight (New York Timezone), this will be in the form of a patch on the ticket 10445. After that I will probably provide a patch with some misc info/data (like trying to get the channel icons from the backend). I will post on this thread when this work will be in.
- dubstar_04 - 2010-10-12
tafypz Wrote:Thanks, we can always use people to test on different environments (in my opinion the more the merrier). I should have the EPG data in late tonight (New York Timezone), this will be in the form of a patch on the ticket 10445. After that I will probably provide a patch with some misc info/data (like trying to get the channel icons from the backend). I will post on this thread when this work will be in.
For the channels icons would it not be best to point the channel folder from xbmc to the channel folder on the myth-backend where the icons are?
For example if i set the icon location to:
/var/cache/mythweb/image_cache
Most of the icons are pulled into xbmc.
The icons in this folder may well be written there when mythweb starts but the location is irrelevant.
There seems to be an issue with the channel names but it basically works. I don't how portable this is over the network either.
I'm sure you have a much more slick plan for the implementation, food for thought any way.
I look forward to testing the epg patch.
Thanks,
Dubstar_04
- tafypz - 2010-10-12
dubstar_04 Wrote:For the channels icons would it not be best to point the channel folder from xbmc to the channel folder on the myth-backend where the icons are?
For example if i set the icon location to:
/var/cache/mythweb/image_cache
Most of the icons are pulled into xbmc.
The icons in this folder may well be written there when mythweb starts but the location is irrelevant.
There seems to be an issue with the channel names but it basically works. I don't how portable this is over the network either.
I'm sure you have a much more slick plan for the implementation, food for thought any way.
I look forward to testing the epg patch.
Thanks,
Dubstar_04
Thanks for the input, I am going more for the route when the end setup doesn't require anything but the mythbackend running on the server.
I am planning on storing the images locally in the userdata/addon/pvr.mythtv folder under something like channel_icons. I can get the icons for each channel over the wire from the mythxml api (tested it last night) and dump these icons in that folder. Then the initial channel definition will contain the path and hopefully display it properly.... In any case I will keep your suggestion in mind.
- dubstar_04 - 2010-10-12
tafypz Wrote:Thanks for the input, I am going more for the route when the end setup doesn't require anything but the mythbackend running on the server.
I am planning on storing the images locally in the userdata/addon/pvr.mythtv folder under something like channel_icons. I can get the icons for each channel over the wire from the mythxml api (tested it last night) and dump these icons in that folder. Then the initial channel definition will contain the path and hopefully display it properly.... In any case I will keep your suggestion in mind.
Thats sounds superb. If you can pull the icons from the backend and cache them locally with no input from the user, well, it doesn't really get any better than that.
The prospect of using xbmc as a full replacement for mythfrontend just seems too good to imagine.
Thanks,
Dubstar_04
- tafypz - 2010-10-13
I updated mythxml.2.patch in ticket 10445.
Support for EPG is now available.
- outleradam - 2010-10-13
tafypz: are you programming with MythTV/0.23 or MythTV/0.24(head)?
.024 python bindings are different and should be the ones which are targeted for longevity.
- tafypz - 2010-10-13
outleradam Wrote:tafypz: are you programming with MythTV/.023 or MythTV/.024(head)?
.024 python bindings are different and should be the ones which are targeted for longevity.
outleradam: I am coding against 0.23 but I am not using the python bindings, I am using the mythxml http api.
BTW I am using your tool for my library needs, great stuff !!!
- outleradam - 2010-10-13
cool!
I was thinking, some of the things discussed earlier, like season and episode matching, would be best to be included into the tvdb plugin. It would be nice to extract the ProgramID and Title, as well as the OriginalAirDate and the Subtitle, then feed all of that into the tvdb plugin. TheTvDb plugin needs to be expanded to handle ProgramID.
Basically, it's just an additonal step of verifying the Mythtv ProgramID versus the received TvDb ID and if they do not match, then download the next series in the list until they do. If the match cannot be obtained, then the first in the list should be used.
So basically, theTvDb plugin needs an optional ProgramID input and when that is specified, then it should loop through the Title matches until the programid either matches the Zap2it ID, or it disregards the ProgramID as irrelevant.
Tell me if my thinking is logical here or not.
- karatekickz - 2010-10-13
Thanks for all the great work on the PVR branch. I am really excited to see it working with mythtv.
I wanted to offer up another suggestion about the interoperability between XBMC and the PVR backends in general. What about using the UPNP DVR (ScheduledRecording, etc.) specs (links below) as the intermediary between XBMC and any of the choosen PVR backends?
I am of the opinion that DLNA/UPNP is about to explode in the home media industry and would love to see XBMC be on the bleeding edge.
Pros
1) UPNP/DLNA is a global standard for home media devices to communicate.
2) If a UPNP XBMC PVR Client addon was written, Theoretically it could be the only addin needed to support the majority of PVR backends. Backend devs would simply need to adhere to the UPNP specifications to allow for complete communication and control with XBMC.
As the UPNP PVR standard becomes more widespread even backend devs that have no interest in XBMC would be maintaining their own upnp compliant projects. This will allow the XBMC PVR devs to focus on what's important, the PVR functionality in XBMC itself. Not in fixing problems with changes in the codebase of the plethora of PVR options that exist for the end user.
3) Added functionality to the PVR backend program itself. Implementation of this idea would turn the PVR backend into a UPNP mediaserver implementing the ScheduledRecordings portion of the spec. By adding the changes to PVR backend portion would add other functionality such as being able to access live tv from other upnp clients/players than XBMC (DLNA TVs, Settop media players, Software mediaplayers Win7 WMP etc.)
4) An easier way to separate maintenance of each separate project to facilitate overall interoperability. (ie backend devs work on keeping their backend UPNP compliant and the XBMC PVR keep their project spec compliant)
Cons
1) At first, changes would have to be made to the codebase of the PVR backends rather than XBMC.
2) UPNP adds another complexity for the programmer to understand for communication. Rather than XBMC PVR ADDON - > Mythtv backend the chain would be XBMC UPNP PVR ADDON -> UPNP MediaServer -> Mythtv backend.
3) Very few UPNP DVR platforms currently exist.
While I think this option could lead to slightly more work in the short run, I feel it will provide a more elegant solution that requires less maintenance and provides more out of the box compliance with the many UPNP PVR products coming to market (Broadcomm and others)
Here are some links to the aforementioned specifications
http://upnp.org/specs/av/av2/
http://upnp.org/specs/av/UPnP-av-ScheduledRecording-v1-Service.pdf
I look forward to your feedback. Thanks so much for all the great work.
- elupus - 2010-10-13
I would be happy to keep on working on upnp support in xbmc for this stuff. But until there is a backend that adheres to the standard it would be very very hard.
- tafypz - 2010-10-14
latest patch in ticket 10445 contains a fix to a bug in EPG where the EPG data is shifted by your local UTC offset. The patch also contains a few cleanup items.
- outleradam - 2010-10-15
link to topic discussing changes required to match every mythtv episode to TvDb. http://forum.xbmc.org/showthread.php?tid=83126
Can someone verify that this works with ppa:mythbuntu\0.24. (head)? I cannot connect. No source found. There were some substantial changes and I'm not sure if it is me or what.
Karate: The new python bindings use upnp and only require a pin as an input if the pin is configured by the user. I don't know how the python can interface with c, but feel free to use my mythicalPythonBindings as an example. Maybe the configuration for the PVR settings can be imported by python bindings to get the host ip and what not.
- PhracturedBlue - 2010-10-15
outleradam Wrote:Can someone verify that this works with ppa:mythbuntu\0.24. (head)? I cannot connect. No source found. There were some substantial changes and I'm not sure if it is me or what.
which 'this' are you referring too?
I said I'd fix the libcmyth to work with 0.24. I'll probably work on that this weekend. I am just recovering from some computer trouble that kept me away from xbmc for the past week.
- wagnerrp - 2010-10-15
outleradam Wrote:Karate: The new python bindings use upnp and only require a pin as an input if the pin is configured by the user.
The MythTV python bindings implement a crude MSearch. It's just a bit of fairly simple socket code, and just enough to query and receive available systems running UPnP. It would be relatively simple to duplicate in C/C++ for XBMC, or one could write a 'helper' program to return the database credentials as you suggest.
What karatekickz is suggesting is that MythTV, and any other PVR backend you may want to use, expose itself as a UPnP RUI (remote user interface). The backend would present a web application, which would be displayed on the client (XBMC) and used to set up recording and live playback. New backends would be supported almost effortlessly, but in exchange, you are limited to whatever the capabilities of the web application exposed by the backend. There is no extensibility for capability beyond the backend. There is no ability to provide a unified interface across multiple backends.