XBMC Community Forum
MythTV PVR client Addon Developers Wanted - Developers Only! - Printable Version

+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: PVR Development (/forumdisplay.php?fid=136)
+--- Thread: MythTV PVR client Addon Developers Wanted - Developers Only! (/showthread.php?tid=82015)



- PhracturedBlue - 2010-10-26 16:09

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 17:37

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 19:07

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 19:11

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 19:17

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 20:58

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 21:38

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 21:45

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 00:15

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 00:36

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