MythTV PVR client Addon Developers Wanted - Developers Only!

MythTV PVR client Addon Developers Wanted - Developers Only! - Printable Version

+- 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)

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

- outleradam - 2010-10-26

no luck with the hosts file. I assume it's trying to access xbmc-live instead of ip/port?

- PhracturedBlue - 2010-10-26

outleradam Wrote:no luck with the hosts file. I assume it's trying to access xbmc-live instead of ip/port?

hmm gethostbyname is a standard unix system call, I think it shuld work with a hosts file. Just to verify, you created /etc/hosts
with the contents:

Code:
192.168.1.110 xbmc-live

I can't check it tonight, but I'll try connecting via a remote machine tomorrow to see if I can reproduce.

- dteirney - 2010-10-26

outleradam Wrote:no luck with the hosts file. I assume it's trying to access xbmc-live instead of ip/port?

I assume you have followed all the typical instructions when you setup MythTV. http://wiki.xbmc.org/?title=MythTV#Setup_in_MythTV

I do recall some issues when I updated to Myth 0.23 and needed to add a hostname to IP address mapping in my /etc/hosts file. Note that it's probably not enough to have the mapping in the router as the typical hostname lookup on Linux doesn't go past the machine or if it does it will go directly to the registered DNS server (probably your ISP DNS server) for the DNS lookup (and it won't know what "XBMC-Live" is as it's not a fully qualified domain name).

XBMC uses the hostname returned in the protocol response, if it is present, to cope with multiple backends, e.g. one master and one or more slaves. I suspect that is what changed in 0.23, e.g. that field was actually filled in all the time rather than just for slave based recordings.

- dteirney - 2010-10-26

outleradam Wrote:no luck with the hosts file. I assume it's trying to access xbmc-live instead of ip/port?

I'm pretty sure the following is the error I was getting until the /etc/hosts file was updated on my remote XBMC machine.

Code:
(cmyth)cmyth_conn_connect_file: cmyth_connect(XBMC-live, 6543, 16384) failed

If "ping XBMC-live" doesn't work from the command line on the machine where XBMC is running you'll need to troubleshoot why. On my remote XBMC machine the "nslookup" and "host" commands can't resolve my MythTV server name but "ping" can. Not sure why.

- outleradam - 2010-10-26

PhracturedBlue Wrote:hmm gethostbyname is a standard unix system call, I think it shuld work with a hosts file. Just to verify, you created /etc/hosts
with the contents:

Code:
192.168.1.110 xbmc-live

My /etc/hosts file was already present and had mapping for 127.0.0.1 and 192.168.1.122, to adam-netbook. I added XBMC-live just as it should be.

dteirney Wrote:I assume you have followed all the typical instructions when you setup MythTV. http://wiki.xbmc.org/?title=MythTV#Setup_in_MythTV

I did not do this

Quote:To ensure XBMC has proper access to the MythTV mysql database, run the following commands on the mysql server. Replace PASSWORD or xbmc with whatever you prefer, but keep the single quotes for syntax. <xml>mysql -u root -p (enter mysql root password when prompted) mysql> grant SELECT,INSERT,UPDATE,DELETE,CREATE,DROP on mythconverg.* to 'xbmc' identified by 'PASSWORD';</xml>

XBMC is getting mysql data from the backend, not the database. All I'm missing is the video file from the backend now. cMyth is taking care of the connection. Or am I wrong?

dteirney Wrote:I'm pretty sure the following is the error I was getting until the /etc/hosts file was updated on my remote XBMC machine.

Code:
(cmyth)cmyth_conn_connect_file: cmyth_connect(XBMC-live, 6543, 16384) failed

If "ping XBMC-live" doesn't work from the command line on the machine where XBMC is running you'll need to troubleshoot why. On my remote XBMC machine the "nslookup" and "host" commands can't resolve my MythTV server name but "ping" can. Not sure why.

I will test this when I get home.

This is from the wiki:

Quote: The Myth Protocol used by XBMC Media Center uses the IP Address configured in the Myth TV backend to determine where to stream the recordings from.

Why are we using the host name?

- PhracturedBlue - 2010-10-26

outleradam Wrote:My /etc/hosts file was already present and had mapping for 127.0.0.1 and 192.168.1.122, to adam-netbook. I added XBMC-live just as it should be.

Well I just did some experiments from a remote backend.
Without an entry in my hosts file, I get exactly the same results as you using both 0.23 and 0.24 (same log message about gethostname returning a bogus IP)

Once I added the line to my hosts file, both 0.23 and 0.24 play correctly from a remote backend.

I don't have hyphens in my hostnames, and am not an expert in the hosts file, but my guess is you still ave an issue here.

Quote:Why are we using the host name?

I think the answer is that if you have a slave-backend, the only way to find it and ask it for a recording is by hostname since that is what myth stores. Since there isn't an easy way to distinguish between a master and slave backend from cmyth, it uses the hostname provided by myth for a given recording. So all remote frontends need to be able to lookup all remote backends by name (i.e. using the hosts file)

- wagnerrp - 2010-10-26

PhracturedBlue Wrote:I think the answer is that if you have a slave-backend, the only way to find it and ask it for a recording is by hostname since that is what myth stores. Since there isn't an easy way to distinguish between a master and slave backend from cmyth, it uses the hostname provided by myth for a given recording. So all remote frontends need to be able to lookup all remote backends by name (i.e. using the hosts file)

In order to know that a certain recording exists on a certain hostname, you either need access to the database or to a backend. Why not just ask them what the address for that hostname is?

From the database:

Code:
#echo "select data FROM settings WHERE value='BackendServerIP' AND hostname LIKE 'myth0%'\G;" | mysql -u**** -p**** mythconverg

*************************** 1. row ***************************

data: 10.254.2.30

From Myth Protocol:

Code:
--> 35      QUERY_SETTING myth0 BackendServerIP

<-- 11      192.168.1.1

From MythXML:

Code:
#wget -q -O - 'http://mythbe:6544/Myth/GetSetting?Key=BackendServerIP&HostName=myth0'

<?xml version="1.0" encoding="utf-8"?>

<GetSettingResponse>

<Count>1</Count>

<HostName>myth0</HostName>

<Values><Value key='BackendServerIP'>192.168.1.1</Value></Values>

</GetSettingResponse>

- PhracturedBlue - 2010-10-26

wagnerrp Wrote:In order to know that a certain recording exists on a certain hostname, you either need access to the database or to a backend. Why not just ask them what the address for that hostname is?

I know very little about the capabilities of the myth protocol. This looks like the right solution but is beyond the scope of the change in question.
The current behavior is the same in 0.23 and 0.24 as far as the lookup requirements go.

- outleradam - 2010-10-26

PhracturedBlue Wrote:I don't have hyphens in my hostnames, and am not an expert in the hosts file, but my guess is you still ave an issue here.

That is the Ubuntu way. It automatically sets up computers with names like adam-desktop.

- murph - 2010-10-26

Hi!

Reading this thread since it started, I'm trying to find a way to contribute.

I can confirm that PhracturedBlue's patches (ticket 10535) are working on Dharma.

My mythbackend is coming from "ppa:mythbuntu/0.24", on a yavdr 0.3 (lucid):

Quote:MythTV Version : 26977
MythTV Branch : branches/release-0-24-fixes

I've checked out Dharma from SVN (as of this writing it is revision 35018) and compiled it:

Code:
svn checkout http://xbmc.svn.sourceforge.net/svnroot/xbmc/branches/Dharma/ xbmc_dharma

cd xbmc_dharma

./bootstrap

./configure

make

Starting with --debug, I get expected errors:

Quote:(cmyth)cmyth_conn_connect: asked for version 8, got version 63
(cmyth)cmyth_conn_connect: asked for version 63, got version 63
(cmyth)__cmyth_rcv_length: read() failed (0)
(cmyth)cmyth_conn_connect: cmyth_rcv_okay() failed

Then I've merged the changesets given in ticket 10535 from trunk and compiled again:

Code:
cd xbmc/lib/cmyth/libcmyth

svn merge -c 34874,34908,34909,34910,34911 http://xbmc.svn.sourceforge.net/svnroot/xbmc/trunk/xbmc/lib/cmyth/libcmyth

cd ../../../../

make

I need to do this inside libcmyth directory, since merging over the complete branch seems to be nightmare due to slow svn connection.

Connection to backend and streaming of live tv is now working, although I see messages on the console like this:

Quote:(cmyth)cmyth_event_get: unknown mythtv BACKEND_MESSAGE ....
(cmyth)cmyth_proginfo_get_detail: cmyth_proginfo_fill() failed
(cmyth)__cmyth_rcv_ulong: received illegal integer: '-1'

If anything else is needed to prove this working, let me know!

HTH,
Murph

- outleradam - 2010-10-26

wagnerrp Wrote:In order to know that a certain recording exists on a certain hostname, you either need access to the database or to a backend. Why not just ask them what the address for that hostname is?

It's already done like that. My source is:

Code:
myth://192.168.1.110/

so somewhere along the way XBMC is translating 192.168.1.110 into server name. This information is only supplied by cmyth and is specified nowhere else on the computer. For some reason, XBMC is taking my information, receiving other information and overriding the server ip with the server name.

- divingmule - 2010-10-26

Working fairly well so far. Wish I could say the same for mythfrontend:mad:

XBMC PRE-10.5 r 35018
MythTv 0.24 RC1
Ubuntu Lucid Linux 2.6.32-25-generic

mythbackend-stdout.txt
xbmc.log

In these logs I started playing a recording, then switched to live tv.

- PhracturedBlue - 2010-10-26

outleradam Wrote:It's already done like that. My source is:

Code:
myth://192.168.1.110/
so somewhere along the way XBMC is translating 192.168.1.110 into server name. This information is only supplied by cmyth and is specified nowhere else on the computer. For some reason, XBMC is taking my information, receiving other information and overriding the server ip with the server name.

Your logs show where it comes from. the info retrieved with a recording specifies the hostname, and cmyth just does a gethostbyname() on that.

The only thing that cmyth does 'wrong' is to assume that the hostname supplied for a given recording can be trandlated by gethostbyname, as opposed to asking mythbackend to do the translation.

Fixing that properly will require some invasive changes to cmyth, since it doesn't really have a safe way to save state. It wouldn't be hard to just use some static variables for a quick hack, but if we're going to fix it, we might as well do it correctly. I dunno when I'll have time to work on it, so the workaround is just to ensure your system can lookup the hostname (as dteirney said, the ability to 'ping' teh hostname is probably sufficient)

- outleradam - 2010-10-27

Ok, I got it to work once, only after I added my server to the hosts file and rebooted everything. However, it only worked once.

It is now freezing up 90% of the time. Here is a youtube video which shows an SSH and a VNC window into my netbook running XBMC and accessing the MythTV.PVR.

http://www.youtube.com/watch?v=iBWD00vcq6M
Make it full screen and you can read everything.

- PhracturedBlue - 2010-10-27

outleradam Wrote:Ok, I got it to work once, only after I added my server to the hosts file and rebooted everything. However, it only worked once.

It is now freezing up 90% of the time.

So after the 1st time, restarting xbmc is not sufficient to get it going again?

At this point all you can do is to compile xbmc in debug mode and rerun with gdb.

Code:
make clean

./configure --disable-optimizations

make

you might want to turn off debug, it isn't very useful when using gdb, and you can't redirect stdout when using gdb (that I know of)

Code:
gdb <path to xbmc>

run

...get xbmc to hang...

Ctrl-C

thread apply all bt full

quit

Send the results of that last command.
that should hopefully show what it is doing