+- 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: 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
- fiveisalive - 2012-02-28
KeithLM Wrote:Well I'm still having the problem. And my initial test yesterday was with a fresh epg7.db since the title/subtitle data changed. I'm curious to see what a valid recording from xbmc looks like in Myth's database. If you wouldn't mind dumping some data that would be helpful. I'm using version 0.24 of Myth pulled from whatever ppa's were provided in my Ubuntu 11.10 install. So I don't know if that makes a difference as to what data is required. And perhaps there's an option in Myth that sets it to be extra picky about program data. After all, channel, plus start time, plus end time should really do it.
As far as the code, I can now tell that PVRClientMythTV::GetEPGForChannel is being used to populate epg7.db, and while that was adding the subtitle to the name, I can't be certain that was a problem. I have found that the seriesid variable in that function corresponds with that field in the database, I don't know what makes programid, but I'm going to try to track that down. Then if I can locate how that data is passed to Myth, if the api handles it, I'll put it in there. It's the best guess I have at the moment.
I've had success scheduling recordings with non-trivial rules via the Mythbox add-on, perhaps it might have some useful code for guiding you in terms of how to access the mythbackend from an external program. It basically uses Python to access the functionality:
https://github.com/analogue/mythbox
- tsp42 - 2012-02-28
KeithLM: I think the problem could be the wrong channel name. Try checking the channel table. It might reveal why the name is wrong. The problem with the subtitle is that there is no valid field for it in the XBMC EPG data. Try looking at the definition of the EPG_TAG in xbmc_pvr_types.h. So the mythtv addon has to translate the mythtv EPG data to xbmc epg data and the other way when xbmc schedules a recording. Most of the time it is enough if the start time title channel and date is correct for mythtv to schedule a recording.
- KeithLM - 2012-02-28
tsp42 Wrote:KeithLM: I think the problem could be the wrong channel name. Try checking the channel table. It might reveal why the name is wrong. The problem with the subtitle is that there is no valid field for it in the XBMC EPG data. Try looking at the definition of the EPG_TAG in xbmc_pvr_types.h. So the mythtv addon has to translate the mythtv EPG data to xbmc epg data and the other way when xbmc schedules a recording. Most of the time it is enough if the start time title channel and date is correct for mythtv to schedule a recording.
OK, I'll look at that, and I'll also see if I can edit the channel name in the record table and see if that changes anything.
fiveisalive, I'll see about trying that also. If I can figure out other valid examples of scheduling requests I might be able to deduce the minimal number of required fields.
- KeithLM - 2012-02-29
I entered a new recording on Cartoon Network from XBMC, then checked in MythTV and it had the error message. So I stopped the backend, edited the database directly and put in TOON, started the backend, and now it shows up in MythTV as looking good.
I'm going to look around in the database as well as MythTV and XBMC options to see if there's something that can be done about these channel names. Perhaps it's some combination of HDHomeRun Prime and Verizon FiOS that gives me two names for each channel whereas other people don't have that, and in XBMC the wrong channel name is being pulled for use in the recordings. In MythFrontend I only see the short name.
*Update* A quick look at the channel table and I see callsign and name, callsign is what should be used, name is what is being used by XBMC.
- KeithLM - 2012-02-29
This is really confusing me now. I've been doing some searching and according to what I find in the docs, recordings are done based on callsign. But libcmyth.h does not have any functions to retrieve callsigns. AddTimer() is putting in the channel name, not the callsign.
So I really don't understand how this is working for anyone, unless you have all your channel names== callsigns. I'd appreciate it if others who have this capability could look at their myth db and see what channel names and callsigns look like for them, just look in the record and channel tables to see what's there. Also, what is being displayed on xbmc in the program guide? Do you see the callsign or the channel name?
In the function PVRClientMythTV::GetEPGForChannel we do have access to the callsign. It's in MythProgram and is accessible as the variable "callsign" in the iterator. If that were stored in the EPG_TAG I think it might be accessible further down the chain of events that leads to the timer being added. I'm not sure, ultimately it needs to get to a MythTimer.
- tsp42 - 2012-02-29
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
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
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
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
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
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
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
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
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
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