• 1
  • 31
  • 32
  • 33
  • 34(current)
  • 35
MythTV PVR client Addon Developers Wanted - Developers Only!
The last commit fixed setting timers segfaulting.

experience so far:

Setting timers adds the database entry but something is missing as the the recording doesnt happen. mythfrontend reports that no episodes are available.

The description for the recording is also the time and date.

The database doent update once a timer is set.

xbmc wont allow the timers to be deleted.


I am still testing these. once i have enough information i will post logs and helpful information.

dubstar_04
All Things PVR
sp00ge Wrote:First thanks dteirney for the work your doing here, much appreciated.

I run a split backend / frontend MythTV configuration which is working fine,
but for some reason the XBMC-PVR frontend is having a problem playing any of my channels which use a cam. I've tried increasing the timeout to the maximum of 30 but still no joy.

I'm not sure how the XBMC-PVR MythTV PVR client works out when there is a channel lock,
but I have noticed that when using MythTV as a client, channels that use a cam show a lock as LMSC (Instead of LMS).

Is there any way to show the lock information in XBMC ?

Well, I've just added a few more channels to my MythBackend and noticed that it wasn't just channels that used a CAM that wouldn't play on XBMC,
BBC HD and BBC 1 HD don't seem to work either along with a few other 'in the clear' non HD channels.

I'll try capture some logs tomorrow
I'm back after being on holiday for 5 weeks followed by another couple to catch up on life back in Auckland and a lot has changed in MythTV Addon land.

tsp42 has spent a bunch of time doing some work on a MythTV Add-On that solely uses libcmyth for the communication to the backend.

Given that the MythXML API is going to be completely changed for Myth 0.25 that is probably the right road to take, at least for the moment.

The Addon that tsp42 has been working on has the timers working correctly along with all the functionality that was in the Addon in my tree.

I'll spend some time in the coming weeks having a look at how I can help tsp42's addon work more stably and support Myth 0.25 going forward (as libcmyth will need to be updated to support 0.25).

I believe that there should just be a single MythTV Addon so any development resource that is willing to work on it helps push the MythTV integration further along.

I'll post more details here once I've talked with tsp42.
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
Hi,
Wanted to know if you were interested in helping me put together a prototype
box runnning on mythtv with XMBC or if your not familiar with mythtv then just an XMBC box.If not I was hoping you could point me in the right direction.
Looking for someone to build the hardware integrated with the software.
Would appreciate it if you could let me know.

Thanks,
Brad Greenwald
CEO
Simit Inc.

The best way to contact me is to email me at [email protected]
Is this planned to be included in the EDEN release?
skyjor Wrote:Hi,
Wanted to know if you were interested in helping me put together a prototype
box runnning on mythtv with XBMC or if your not familiar with mythtv then just an XBMC box.If not I was hoping you could point me in the right direction.
Looking for someone to build the hardware integrated with the software.
Would appreciate it if you could let me know.

Thanks,
Brad Greenwald
CEO
Simit Inc.

The best way to contact me is to email me at [email protected]

There is another mythtv add-on that is under more active development, see this thread:

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

vskatusa; Wrote:Is this planned to be included in the EDEN release?

Support for PVR backends in the upstream has been postponed until after the Eden release as far as I know. First dushmaniac's PVR branch (which contains all the generic PVR support) at:

https://github.com/opdenkamp/xbmc

needs to be integrated into upstream.

Once that is done, then individual PVR client add-ons (like tsp42's MythTV add-on described in http://forum.xbmc.org/showthread.php?tid=110694 ) will need to be pushed upstream before it appears in the default built. That said, I believe dushmaniac and tsp make regular binary snapshots available for installation (at least for Windows). In the case of tsp's branch, for Linux and MacOS X, you'll probably need to build from source yourself for the time being.
i get this

03:43:54 T:106930176 DEBUG: InitialiseClient - initialising add-on 'MythTV PVR Client'
03:43:54 T:106930176 DEBUG: PVR - Create - creating PVR add-on instance 'MythTV PVR Client'
03:43:54 T:106930176 DEBUG: ADDON: Dll Initializing - MythTV PVR Client
03:43:54 T:106930176 DEBUG: SECTION:LoadDLL(/private/var/stash/Applications/XBMC.frappliance/XBMCData/XBMCHome/addons/pvr.mythtv/XBMC_MythTV.pvr)
03:43:54 T:106930176 DEBUG: Loading: /private/var/stash/Applications/XBMC.frappliance/XBMCData/XBMCHome/addons/pvr.mythtv/XBMC_MythTV.pvr
03:43:54 T:106930176 ERROR: Unable to load /private/var/stash/Applications/XBMC.frappliance/XBMCData/XBMCHome/addons/pvr.mythtv/XBMC_MythTV.pvr, reason: dlopen(/private/var/stash/Applications/XBMC.frappliance/XBMCData/XBMCHome/addons/pvr.mythtv/XBMC_MythTV.pvr, 1): Symbol not found: _GetChannelGroupMembers
Referenced from: /private/var/stash/Applications/XBMC.frappliance/XBMCData/XBMCHome/addons/pvr.mythtv/XBMC_MythTV.pvr
Expected in: flat namespace
in /private/var/stash/Applications/XBMC.frappliance/XBMCData/XBMCHome/addons/pvr.mythtv/XBMC_MythTV.pvr
03:43:54 T:106930176 INFO: Called Add-on status handler for '4' of clientName:MythTV PVR Client, clientID:pvr.mythtv (same Thread=no)
03:43:54 T:164708352 DEBUG: Thread CAddonStatusHandler:pvr.mythtv start, auto delete: 1
03:43:54 T:106930176 ERROR: PVR - InitialiseClient - can't initialise add-on 'MythTV PVR Client'


when having the client enabled
any ideas why ?
Smile 
Hello All,

I have been testing XBMC-PVR with MythTV and VDR backends with cmyth (https://github.com/tsp) and xvdr (https://github.com/pipelka) respectively. Despite no difference in graphical user interface of XBMC-PVR, there is currently a critical oversight in the functionality of the MythTV backend whist serving multiple XBMC-PVR frontends over a network (unless someone can tell everyone otherwise).

Background Info: Virtual Tuners
Both MythTV and VDR are cable of creating 'virtual' tuner(s) to every physical DVB tuner. The DVB standard, emits multiple video, audio and data MPEG transport streams that make up 'channels' per multiplex. Despite filtering to a specific channel on a given multiplex the other channels on that multiplex are available at the same time. A 'virtual' tuner is able to deliver these other available channels for either recording or Live-TV playback. VDR allocates 1nr 'virtual' tuner per every physical tuner (please advise if this can be modified?). MythTV backend defaults to 1nr 'virtual' tuner per every physical tuner, however this can be modified in the backend set-up.

VDR Backend and Multiple Connected XBMC-PVR Frontends Over Network
The VDR backend handles and issues its physical and virtual tuners to clients with a very efficient methodology (http://www.linuxtv.org/pipermail/vdr/200...10538.html). This logical priority delivers the XBMC-PVR clients successful channel surfing / hopping and recording of all channels in the EPG, limited only by the number of tuners, physical or virtual, assigned to the VDR backend.

The Problem: MythTV Backend and Multiple Connected XBMC-PVR Frontends Over Network
The MythTV backend, on handshaking / accepting clients, will issue the first available tuner, physical or virtual. By default it does this in ascending order to which the tuners were added in the backend set-up. Thus, if two DVB-S tuners were added first then followed up two DVB-T tuners, the first connected client will be issued with the first physical DVB-S tuner. When the next client connects, MythTV backend will issues the next available tuner. Which by default, will be the virtual tuner to the first physical tuner. This means that both clients are locked on the same multiplex. Therefore, the only channels that each of the two connected clients can surf / hop between are those that are on the currently tuned multiplex.

Solutions for MythTV Frontend Users
MythTV frontend overcomes this by one of two, less than satisfactory methods. Firstly, MythTV frontend can be configured to override the backends selection methodology by requesting the first available tuner in descending order rather than ascending order described above. However, if more than one frontend is configured in this way, the same lock will occur. Finally, the user can manually change the tuner (via the 'source' option) within the MythTV frontend on-screen display menu.

Solutions for XBMC-PVR Users
A non-intrusive method is to simply disable all virtual tuners in the MythTV backend set-up. This will ensure that every connected client will have a dedicated physical tuner. This physical tuner is then able to surf / hop to any channel in the EPG. However, virtual tuners have their worth. For example, given the correct parameters two physical tuners can record / playback four or possibly greater than four channels at once. This example is obviously dependant firstly, on how many virtual tuners are enabled (the number of virtual tuners is ultimately limited by your TV card hardware) and secondly, all the channels that are recording / being viewed live are on no more than the two tuned multiplexes. Alternatively the MythTV backend requires development to automatically issue a tuner in the same methodology as VDR. This development can either be in the form of a permanent feature to MythTV backend or a patch just for those who want to use XBMC-PVR (see: http://www.gossamer-threads.com/lists/my...ers/437848 & http://code.mythtv.org/trac/ticket/7164)

Unless I'm missing some information to the contrary Huh
guyrichie Wrote:Hello All,

I have been testing XBMC-PVR with MythTV and VDR backends with cmyth (https://github.com/tsp) and xvdr (https://github.com/pipelka) respectively. Despite no difference in graphical user interface of XBMC-PVR, there is currently a critical oversight in the functionality of the MythTV backend whist serving multiple XBMC-PVR frontends over a network (unless someone can tell everyone otherwise).

Background Info: Virtual Tuners
Both MythTV and VDR are cable of creating 'virtual' tuner(s) to every physical DVB tuner. The DVB standard, emits multiple video, audio and data MPEG transport streams that make up 'channels' per multiplex. Despite filtering to a specific channel on a given multiplex the other channels on that multiplex are available at the same time. A 'virtual' tuner is able to deliver these other available channels for either recording or Live-TV playback. VDR allocates 1nr 'virtual' tuner per every physical tuner (please advise if this can be modified?). MythTV backend defaults to 1nr 'virtual' tuner per every physical tuner, however this can be modified in the backend set-up.

VDR Backend and Multiple Connected XBMC-PVR Frontends Over Network
The VDR backend handles and issues its physical and virtual tuners to clients with a very efficient methodology (http://www.linuxtv.org/pipermail/vdr/200...10538.html). This logical priority delivers the XBMC-PVR clients successful channel surfing / hopping and recording of all channels in the EPG, limited only by the number of tuners, physical or virtual, assigned to the VDR backend.

The Problem: MythTV Backend and Multiple Connected XBMC-PVR Frontends Over Network
The MythTV backend, on handshaking / accepting clients, will issue the first available tuner, physical or virtual. By default it does this in ascending order to which the tuners were added in the backend set-up. Thus, if two DVB-S tuners were added first then followed up two DVB-T tuners, the first connected client will be issued with the first physical DVB-S tuner. When the next client connects, MythTV backend will issues the next available tuner. Which by default, will be the virtual tuner to the first physical tuner. This means that both clients are locked on the same multiplex. Therefore, the only channels that each of the two connected clients can surf / hop between are those that are on the currently tuned multiplex.

Solutions for MythTV Frontend Users
MythTV frontend overcomes this by one of two, less than satisfactory methods. Firstly, MythTV frontend can be configured to override the backends selection methodology by requesting the first available tuner in descending order rather than ascending order described above. However, if more than one frontend is configured in this way, the same lock will occur. Finally, the user can manually change the tuner (via the 'source' option) within the MythTV frontend on-screen display menu.

Solutions for XBMC-PVR Users
A non-intrusive method is to simply disable all virtual tuners in the MythTV backend set-up. This will ensure that every connected client will have a dedicated physical tuner. This physical tuner is then able to surf / hop to any channel in the EPG. However, virtual tuners have their worth. For example, given the correct parameters two physical tuners can record / playback four or possibly greater than four channels at once. This example is obviously dependant firstly, on how many virtual tuners are enabled (the number of virtual tuners is ultimately limited by your TV card hardware) and secondly, all the channels that are recording / being viewed live are on no more than the two tuned multiplexes. Alternatively the MythTV backend requires development to automatically issue a tuner in the same methodology as VDR. This development can either be in the form of a permanent feature to MythTV backend or a patch just for those who want to use XBMC-PVR (see: http://www.gossamer-threads.com/lists/my...ers/437848 & http://code.mythtv.org/trac/ticket/7164)

Unless I'm missing some information to the contrary Huh

That is some great information, definitely well researched. Thanks for your efforts on that. You may want to think about posting this on this thread as well: http://forum.xbmc.org/showthread.php?tid=110694

It is for the cmyth addon currently being worked on by tsp. It has a more active user base and is more likely someone will pick up on the issue.
As everyone has probably noticed this development stalled over a year ago. Primarily when it was announced that MythXML support was being dropped for the Myth 0.25 release in favour of the new Services API. At the time there wasn't a great deal of information available on what those new services would look like.

tsp42 has been doing a lot of work on an Addon for Myth TV that uses the Myth Protocol via the libcmyth library (and he's made a number of additions to that as well).

I will be asking dushmaniac to delete this Addon from the master PVR repository to avoid the confusion that has arisen with people trying to use this addon and finding that it doesn't work.

I would like to sincerely thank all those people from the community that provided time, effort and support for this addon. I will keep a copy of the latest code locally with me in case anyone thinks it would be useful for a project interacting with the Services API.

In the short term I will be in contact with tsp42 to determine how I can help with the Myth Protocol based addon so XBMC finally has a PVR frontend that beats the pants of mythfrontend Smile

So, for all your Myth TV viewing pleasure in XBMC please head on over to http://forum.xbmc.org/showthread.php?tid=110694
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
I was wondering if anyone was planning to work on a Services API-based addon. The advantage of the Services API is that it will not break with every new version of MythTV. They plan to make it immune to protocol changes. I have looked at the API a bit, but I'm not familiar enough with the XBMC PVR interface to know if it has everything necessary. (I did find that the wiki entry for the Services API is incomplete, but the wsdl interface gives a complete listing of available calls.)

Anyway, I was just curious and might take a look down the road if I have some time.

Joel
(2012-05-01, 21:08)joelmeans Wrote: I was wondering if anyone was planning to work on a Services API-based addon. The advantage of the Services API is that it will not break with every new version of MythTV. They plan to make it immune to protocol changes. I have looked at the API a bit, but I'm not familiar enough with the XBMC PVR interface to know if it has everything necessary. (I did find that the wiki entry for the Services API is incomplete, but the wsdl interface gives a complete listing of available calls.)

Anyway, I was just curious and might take a look down the road if I have some time.

Joel
I think it would be better to incorporate the API in the cmyth library. The API for scheduling a recording is not implemented yet from what I can see so you still have to mess with the MySQL database.
Libcmyth MythTV addon for xbmc-pvr [source] [forum thread]
(2012-05-01, 23:42)tsp42 Wrote: I think it would be better to incorporate the API in the cmyth library. The API for scheduling a recording is not implemented yet from what I can see so you still have to mess with the MySQL database.

Yeah, that probably is the way to go.

Adding a recording is supported, it just isn't documented in the wiki. If you point your browser to http://<your backend ip>:6544/Dvr/wsdl, you will see methods for dealing with recordings, including AddRecordSchedule. When I first started looking, I thought that was a major hangup for making a usable frontend with the Services API.

Joel
Is there a way we can patch the work dtierney is doing with cmyth to use Myth 0.25 against this and test it?
Someone would need to alter all of the current MythXML URL's to point to the new locations and make whatever changes there are to the returned XML structure.

Can someone who has Myth 0.25 post the wsdl somewhere? I'm not upgrading to 0.25 just yet. If they can I could have a look at what Service APIs there actually are and see if a solution could be put together using the Services API entirely rather than having to fallback to the Myth Protocol or MySQL queries / updates.
If the new Services API does contain all the stuff necessary maybe I will revist some of this work...

The old MythXML interface didn't have a solution for LiveTV or Scheduling of Recordings or retrieving Cut / Commbreak Lists. Most everything else was possible and even the HTTP streaming of recordings worked with XBMC's internal player just fine. Live TV for the current MythXML Addon simply routes to the internal LiveTV URLs that then end up using the internal myth:// support, which by all accounts is average at best.
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
  • 1
  • 31
  • 32
  • 33
  • 34(current)
  • 35

Logout Mark Read Team Forum Stats Members Help
MythTV PVR client Addon Developers Wanted - Developers Only!8