Hello All,
(originally posted: http://forum.xbmc.org/showpost.php?p=103...tcount=503)
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