+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: PVR Development (/forumdisplay.php?fid=136)
+--- Thread: New MythTV add-on using libcmyth (/showthread.php?tid=110694)
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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207
- tsp42 - 2012-02-29 08:43
In my case the call sign and channel is the same and I suspect it is for most people. But it is good for testing that you have a different setup. I will update the livcmyth code so it can also retrieve the call name or use it when scheduling a recording.
- KeithLM - 2012-02-29 09:02
tsp42 Wrote:In my case the call sign and channel is the same and I suspect it is for most people. But it is good for testing that you have a different setup. I will update the livcmyth code so it can also retrieve the call name or use it when scheduling a recording.
Cool, thanks, let me know when you make those changes and I'll test it out.
I wonder if Verizon FiOS, being a relatively new provider (started in 2005) were able to go with a more sophisticated protocol that allowed name and callsign since they had no existing systems to be backwards compatible with.
Myth Protocol Error - tricky720101 - 2012-02-29 22:11
Managed to build xbmc but by manual method, the git clone did not work correctly when run in the script
I have managed to connect to mythtv backend but not reliably, epg download good but live tv has jerky image and on channels that take a while to tune (due to encrpy) do not show at all, tried to increase timeout for tune but this did not work. Eventually xbmc lossing pvr connection due to backend segment fault. The backend log shows a mismatch on protocol versions:-
2012-02-28 21:57:22.035 TVRec(1): Changing from WatchingLiveTV to None
2012-02-28 21:57:26.699 MainServer::HandleVersion - Client speaks protocol version 8 but we speak 63!
2012-02-28 21:57:26.731 MainServer, Warning: Unknown socket closing MythSocket(0x16d3dd0)
2012-02-28 21:57:26.733 MainServer::ANN Playback
Client speaks version 8
mythtv 0.24 is currently on V63.Can anyone shed some light on this??
Regards
Rick
- tsp42 - 2012-02-29 22:16
tricky720101: Yes at least the part about the protocol version. When the connection between the xbmc frontend and backend is established, the frontend sends protocol version 8 to get the correct version as it is the only way to get this information from the backend.
KeithLM: I'm more inclined to believe the different callsign is due to the presence of two different tuners. I'm afraid that you have to wait till the weekend for the fix.
- KeithLM - 2012-03-01 01:49
tsp42 Wrote:KeithLM: I'm more inclined to believe the different callsign is due to the presence of two different tuners. I'm afraid that you have to wait till the weekend for the fix.
No worries on the delay, I'm just tinkering at this point.
I'm just using one HDHomeRun Prime with a cablecard and it has 3 built-in tuners. From what I've gathered, different tuner devices actually affect the value of chanid in the channel table, or something like that. Looking in my channel table all my chanid fields are equal to 1000 + channum. I believe if I had a second source then those chanid fields would be 2000 + channum.
- sysadm1n - 2012-03-02 05:23
tricky720101 Wrote:Managed to build xbmc but by manual method, the git clone did not work correctly when run in the script
If you already have a ~/src/xbmc directory then git clone won't download the branch again. So if you have to manually do the git clone for some reason or if you go in and do a git pull then you can still run the script to automate the build and install process.
- nmcaullay - 2012-03-02 08:30
Hi all, is there any trick to using git pull, and recompiling? I did the clone as per the first posts in this thread, and xbmc works fine.
I do a git pull, make, and sudo make install, which appear to work fine.
But, I get segfaults, and crashlogs that render the install invalid.
I dont have access to pastebin at work, but this is the top of the first crashlog. any ideas?
Nathan
Code:
############## XBMC CRASH LOG ###############
################ SYSTEM INFO ################
Date: Thu Mar 1 22:37:46 EST 2012
XBMC Options:
Arch: i686
Kernel: Linux 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012
Release:
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric
############## END SYSTEM INFO ##############
############### STACK TRACE #################
=====> Core file: /home/macdoodles/Downloads/xbmc/core (2012-03-01 22:37:45.941437500 +1000)
=========================================
[New LWP 16539]
[New LWP 16555]
[New LWP 16561]
[New LWP 16560]
[New LWP 16563]
[New LWP 16566]
[New LWP 16559]
[New LWP 16565]
[New LWP 16556]
[New LWP 16564]
[New LWP 16557]
[New LWP 16562]
[New LWP 16568]
[Thread debugging using libthread_db enabled]
Core was generated by `/usr/local/lib/xbmc/xbmc.bin'.
Program terminated with signal 6, Aborted.
#0 0xb78a8424 in __kernel_vsyscall ()
Thread 13 (Thread 0xa69ffb70 (LWP 16568)):
#0 0xb78a8424 in __kernel_vsyscall ()
#1 0xb602ded1 in select () from /lib/i386-linux-gnu/libc.so.6
#2 0xb14eb273 in cmyth_event_select (conn=0xac85cf24, timeout=0xa69feacc) at event.c:186
#3 0xaafc32b4 in MythEventHandler::ImpMythEventHandler::Action (this=0xac8906f0) at cppmyth/MythEventHandler.cpp:176
#4 0xaafdc491 in cThread::StartThread (Thread=0xac8906f0) at thread.cpp:258
#5 0xb6d08d31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb60350ce in clone () from /lib/i386-linux-gnu/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further
Thread 12 (Thread 0xa9efeb70 (LWP 16562)):
#0 0xb78a8424 in __kernel_vsyscall ()
#1 0xb6043063 in ?? () from /lib/i386-linux-gnu/libc.so.6- sysadm1n - 2012-03-02 09:03
nmcaullay Wrote:Hi all, is there any trick to using git pull, and recompiling? I did the clone as per the first posts in this thread, and xbmc works fine.
I do a git pull, make, and sudo make install, which appear to work fine.
But, I get segfaults, and crashlogs that render the install invalid....
Be sure to uninstall and re-configure:
Code:
sudo make uninstall
git pull
./configure
make
sudo make install- Jimmer - 2012-03-02 09:33
nmcaullay Wrote:Hi all, is there any trick to using git pull, and recompiling? I did the clone as per the first posts in this thread, and xbmc works fine.
I do a git pull, make, and sudo make install, which appear to work fine.
But, I get segfaults, and crashlogs that render the install invalid.
I dont have access to pastebin at work, but this is the top of the first crashlog. any ideas?
Nathan
Just to add to sysadm1n's advice above, I always force a git reset and clean before pulling just to make sure (had a few problems with the early days of Dushmaniac's branch missing the "make clean" and "make distclean" now I do this as a matter of routine) and I always re-bootstrap (although some people only do this if their system/os changes)
Code:
git reset --hard HEAD
git clean -xfd
git pull
./bootstrapthen your custom configure options & make
I personally don't make install - I use checkinstall to roll my own debs instead, makes rolling back to a previous install as simple as using dpkg
How MythTV Backend Allocates Tuners to Multiple Clients - guyrichie - 2012-03-03 12:43
Hello All,
(originally posted: http://forum.xbmc.org/showpost.php?p=1034820&postcount=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/2006-August/010538.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/mythtv/users/437848 & http://code.mythtv.org/trac/ticket/7164)
Unless I'm missing some information to the contrary