• 1
  • 14
  • 15
  • 16(current)
  • 17
  • 18
  • 35
MythTV PVR client Addon Developers Wanted - Developers Only!
outleradam Wrote:If you'd like I could come up with a way to handle a message like that. I just don't know where we are storing guide data. Would you like me to come up with something in C to parse that argument into a series of variables?
I don't think there is much point yet. We don't seem to have the necessary plumbing in xbmc to actually use the events for much interesting. Once we do have a way to use it, actually doing the parsing needs to happen in C++, and shouldn't prove too difficult.

Improving myth's wiki would be useful though because the commands, as you noted, are not very well documented.

Note that I am not familiar with this part of cmyth yet (I didn't even know it existed until yesterday) so don't take me for an expert.
It looks like that event is supposed to pass through /trunk/xbmc/lib/cmyth/libcmyth/event.c line 55. (which also looks like it needs a slight whitespace adjustment)... where it is not passed to the recording for some reason but identified as unidentified.


I referenced over at programinfo.c...
check out line 1324...

This is a comparison from that wiki mythprotocol and what's in proginfo.c.
Code:
title         S(prog->proginfo_title),
subtitle         S(prog->proginfo_subtitle),
description         S(prog->proginfo_description),
category         S(prog->proginfo_category),
chanid         prog->proginfo_chanId,
channum         S(prog->proginfo_chanstr),
callsign         S(prog->proginfo_chansign),
channame         S(prog->proginfo_chanicon),
filename         S(prog->proginfo_url),
filesize         (int32_t)(prog->proginfo_Length >> 32),
starttime         (int32_t)(prog->proginfo_Length & 0xffffffff),
endtime         start_ts,
findid         end_ts,
hostname         S(prog->proginfo_unknown_0),
sourceid         prog->proginfo_recording,
cardid         prog->proginfo_override,
inputid         S(prog->proginfo_hostname),
recpriority         prog->proginfo_source_id,
recstatus         prog->proginfo_card_id,
recordid         prog->proginfo_input_id,
rectype         S(prog->proginfo_rec_priority),
dupin         prog->proginfo_rec_status,
dupmethod         prog->proginfo_record_id,
recstartts         prog->proginfo_rec_type,
recendts         prog->proginfo_rec_dups,
programflags         prog->proginfo_unknown_1,
recgroup         rec_start_ts,
outputfilters        rec_end_ts,
seriesid         prog->proginfo_repeat,
programid         prog->proginfo_program_flags,
lastmodified         S(prog->proginfo_recgroup),
stars         S(prog->proginfo_chancommfree),
airdate         S(prog->proginfo_chan_output_filters),
playgroup         S(prog->proginfo_seriesid),
recpriority2         S(prog->proginfo_programid),
parentid         lastmodified,
storagegroup         S(prog->proginfo_stars),
audio_props         originalairdate);
video_props    
subtitle_type    
year

Could have something to do with it being unrecognized?



I cant figure out what those cryptic strncmp and strncpy are supposed to be.
Use mythicalLibrarian to make a library out of your MythTV files. Leave the recording to MythTV and use XBMC as your library.
Installation and Instructions:http://wiki.xbmc.org/index.php?title=MythicalLibrarian
Technical Support:http://forum.xbmc.org/showthread.php?tid=65644
[url=http://forum.xda-developers.com/showthread.php?tid=1081892][/url]
outleradam Wrote:It looks like that event is supposed to pass through /trunk/xbmc/lib/cmyth/libcmyth/event.c line 55. (which also looks like it needs a slight whitespace adjustment)... where it is not passed to the recording for some reason but identified as unidentified.
Yes, this is what patch 10587 is supposed to address. The new version should work better.
I'll test that patch, I'm making my svn clean now.

Is there a way to just patch and build a single file rather then the entire SVN over again?
Use mythicalLibrarian to make a library out of your MythTV files. Leave the recording to MythTV and use XBMC as your library.
Installation and Instructions:http://wiki.xbmc.org/index.php?title=MythicalLibrarian
Technical Support:http://forum.xbmc.org/showthread.php?tid=65644
[url=http://forum.xda-developers.com/showthread.php?tid=1081892][/url]
wagnerrp Wrote:As indicated by the page you linked to, the message provides a 'programinfo' structure, as documented here. While it uses information from both the `recorded` and `recordedprogram` tables, there is no direct mapping. The existing libraries already have support for this structure in the function cmyth_rcv_proginfo. Processing that structure is simple, the hard part is setting up a background polling thread that shares the same connection you are actively trying to use.

The XBMC frontend currently uses a polling thread to process any backend messages it receives. It doesn't do anything with them other than log them at present. It's in MythSession:Tonguerocess() if anyone is interested. I don't think any listeners get attached either.

Not sure how the thread aspect could be done in the PVR addon since MythSession currently uses the CThread utility class. At this stage it doesn't seem too important since theres nothing being done with them. Might be useful later though.
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
dteirney Wrote:The XBMC frontend currently uses a polling thread to process any backend messages it receives. It doesn't do anything with them other than log them at present. It's in MythSession:Tonguerocess() if anyone is interested. I don't think any listeners get attached either.

Not sure how the thread aspect could be done in the PVR addon since MythSession currently uses the CThread utility class. At this stage it doesn't seem too important since theres nothing being done with them. Might be useful later though.

Actually, each MythFile instance is set as a listener when the connection is made. The only processed backed event is the one to update the live tv chain.
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
PhracturedBlue Wrote:Yes, this is what patch 10587 is supposed to address. The new version should work better.

PhracturedBlue, thanks for the patches. I've overlaid them with some work I had already started in http://trac.xbmc.org/ticket/8680

If people are willing to test, can you get the patch from that ticket and test to see if there are any other UNKNOWN backend messages showing up. There is also a change in the patch to put the stderr output to stdout to make capturing the logs a bit easier.

The patch also contains a possible fix for Live TV. If people could apply the patch and then test Live TV that would be good. If you have any problems or still see any UNKNOWN events listed, please set the log level to debug (at least 1) and then post a link to a pastebin'ed log file here. Log level 3 spits out ludicrous amounts of content so just trim the log to the areas that appear to be causing problems.

Live TV on our system is quite slow for locking onto each channel. Not sure what other peoples experience is like.
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
outleradam Wrote:I'll test that patch, I'm making my svn clean now.

Is there a way to just patch and build a single file rather then the entire SVN over again?

Easiest way to apply an entire patch again is the following:

Code:
svn revert -R .
patch -p0 < name-of-patch.patch
make
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
outleradam Wrote:It looks like that event is supposed to pass through /trunk/xbmc/lib/cmyth/libcmyth/event.c line 55. (which also looks like it needs a slight whitespace adjustment)... where it is not passed to the recording for some reason but identified as unidentified.

I referenced over at programinfo.c...
check out line 1324...

This is a comparison from that wiki mythprotocol and what's in proginfo.c.
Code:
title         S(prog->proginfo_title),
subtitle         S(prog->proginfo_subtitle),
description         S(prog->proginfo_description),
category         S(prog->proginfo_category),
chanid         prog->proginfo_chanId,
channum         S(prog->proginfo_chanstr),
callsign         S(prog->proginfo_chansign),
channame         S(prog->proginfo_chanicon),
filename         S(prog->proginfo_url),
filesize         (int32_t)(prog->proginfo_Length >> 32),
starttime         (int32_t)(prog->proginfo_Length & 0xffffffff),
endtime         start_ts,
findid         end_ts,
hostname         S(prog->proginfo_unknown_0),
sourceid         prog->proginfo_recording,
cardid         prog->proginfo_override,
inputid         S(prog->proginfo_hostname),
recpriority         prog->proginfo_source_id,
recstatus         prog->proginfo_card_id,
recordid         prog->proginfo_input_id,
rectype         S(prog->proginfo_rec_priority),
dupin         prog->proginfo_rec_status,
dupmethod         prog->proginfo_record_id,
recstartts         prog->proginfo_rec_type,
recendts         prog->proginfo_rec_dups,
programflags         prog->proginfo_unknown_1,
recgroup         rec_start_ts,
outputfilters        rec_end_ts,
seriesid         prog->proginfo_repeat,
programid         prog->proginfo_program_flags,
lastmodified         S(prog->proginfo_recgroup),
stars         S(prog->proginfo_chancommfree),
airdate         S(prog->proginfo_chan_output_filters),
playgroup         S(prog->proginfo_seriesid),
recpriority2         S(prog->proginfo_programid),
parentid         lastmodified,
storagegroup         S(prog->proginfo_stars),
audio_props         originalairdate);
video_props    
subtitle_type    
year

Could have something to do with it being unrecognized?

I cant figure out what those cryptic strncmp and strncpy are supposed to be.

Yes, good find. That fill_command will need altering for the new protocol. It doesn't look like it is working for me either with a 0.23 backend so that might have been broken for a while.

@PhracturedBlue, are you able to have a look and make any necessary protocol changes based on the work you have already done? It's nearly midnight in NZ so no more time for me to look at for a few days now.

@outleradam, Google is your friend. http://www.cplusplus.com/reference/clibr...g/strncmp/ I've found cplusplus.com to be a good reference.
Use MythTV for recording TV? Try the integrated MythTV support in XBMC Media Center. Now with commercial skip support built-in and integration with the Movie database!
@murph:
can you try the patch here: http://trac.xbmc.org/ticket/8680
Hoepfully it will REALLY get rid of the BACKEND_MESSAGE stuff

Additionally, can you add this:
Code:
Index: xbmc/lib/cmyth/libcmyth/proginfo.c
===================================================================
--- xbmc/lib/cmyth/libcmyth/proginfo.c    (revision 34958)
+++ xbmc/lib/cmyth/libcmyth/proginfo.c    (working copy)
@@ -1463,6 +1463,8 @@

    length = prog->proginfo_Length;
    if ((ret=fill_command(control, prog, "FILL_PROGRAM_INFO") != 0))
+        cmyth_dbg(CMYTH_DBG_ERROR, "%s: failed to send 'FILL_PROGRAM_INFO', received '%d'\n",
+              __FUNCTION__, ret);
        goto out;

    count = cmyth_rcv_length(control);
@@ -1490,6 +1492,8 @@
     * number is still probably wrong, but it's better than 0.
     */
    if (prog->proginfo_Length == 0) {
+        cmyth_dbg(CMYTH_DBG_ERROR, "%s: proginfo length was 0\n",
+              __FUNCTION__);
        prog->proginfo_Length = length;
        ret = -1;
        goto out;
That should tell us why proginfo_fill is failing

The ulong -1 is still a mystery, but I've looked at all calls to cmyth_rcv_ulong
outside of proginfo_fill (which should not be the cause given the order of error messages), and excluding any cases that would thow a message we don't see, and only came up with 2 cases:
  • cmyth_rcv_version
    cmyth_conn_check_block
So here is a patch to check to see if either of those are giving us trouble:
Code:
Index: xbmc/lib/cmyth/libcmyth/connection.c
===================================================================
--- xbmc/lib/cmyth/libcmyth/connection.c    (revision 34958)
+++ xbmc/lib/cmyth/libcmyth/connection.c    (working copy)
@@ -888,6 +888,9 @@
        }
        cmyth_rcv_ulong(conn, &err, &sent, length);
        if (err) {
+            cmyth_dbg(CMYTH_DBG_ERROR,
+                  "%s: cmyth_rcv_ulong failed\n",
+                  __FUNCTION__);
            return -err;
        }
        if (sent == size) {
Index: xbmc/lib/cmyth/libcmyth/socket.c
===================================================================
--- xbmc/lib/cmyth/libcmyth/socket.c    (revision 34958)
+++ xbmc/lib/cmyth/libcmyth/socket.c    (working copy)
@@ -705,6 +705,10 @@
              "%s: did not consume everything %d < %d\n",
              __FUNCTION__, consumed, len);
    }
+    if(err)
+        cmyth_dbg(CMYTH_DBG_ERROR,
+              "%s: cmyth_rcv_ulong() failed (%d)\n",
+              __FUNCTION__, consumed);
    return -err;
}

If that doesn't help, the easiest thing to do is to use gdb as I asked of outleradam:
Code:
make clean
./configure -disable-optimizations
make
gdb <path to xbmc.bin>
break socket.c:484
run
(you probably need to setup xbmc to run in windowed mode, since once it hits that line of code, xbmc will hang)
then in gdb:
bt full (send this to me)
quit
Sure - I'll apply the patch, when I'm home in a couple of hours

Just to be sure:
The patch from http://trac.xbmc.org/ticket/8680 should be applied to a clean, unpatched dharma (I see against rev35026 in the patch), without the patched from http://trac.xbmc.org/ticket/10587 as this one is closed - I assume so.
nothing of this is in dharma. it's in trunk.
murph Wrote:Sure - I'll apply the patch, when I'm home in a couple of hours

Just to be sure:
The patch from http://trac.xbmc.org/ticket/8680 should be applied to a clean, unpatched dharma (I see against rev35026 in the patch), without the patched from http://trac.xbmc.org/ticket/10587 as this one is closed - I assume so.

yes, apply 8680 and the 2 patches above, but not 10587. They were built against trunk, however, they will likely apply to dharma as well.
my fault - my directory is named xbmc_dharma, since I use a dharma checkout and then merged the revs 34874,34908,34909,34910,34911 from trunk into it.
Well, here is an intermediate update....

A small glitch in "xbmc/lib/cmyth/libcmyth/proginfo.c" patch from post #240 broke playback and I've looked completely at the wrong place for a long time, since I thought it has to be something with the changes from ticket #8680 patch.

After a couple of recompiles, separating each file I found, that there are some missing curly brackets:

Quote: if ((ret=fill_command(control, prog, "FILL_PROGRAM_INFO") != 0))
cmyth_dbg(CMYTH_DBG_ERROR, "%s: failed to send 'FILL_PROGRAM_INFO', received '%d'\n",
__FUNCTION__, ret);
goto out;

should read:

Quote: if ((ret=fill_command(control, prog, "FILL_PROGRAM_INFO") != 0)) {
cmyth_dbg(CMYTH_DBG_ERROR, "%s: failed to send 'FILL_PROGRAM_INFO', received '%d'\n",
__FUNCTION__, ret);
goto out;
}

Anyway, here is what I found out so far.

* unkown BACKEND_MESSAGE nearly gone - just one message left, which appeared after some time (about 10min) watching:

Quote:(cmyth)cmyth_event_get: unknown mythtv BACKEND_MESSAGE 'LIVETV_WATCH 1 0'

* cmyth_proginfo_fill fails only in function cmyth_proginfo_get_detail:

Quote:(cmyth)cmyth_proginfo_fill: proginfo length was 0
(cmyth)cmyth_proginfo_get_detail: cmyth_proginfo_fill() failed

Here is the full debug log of this session:
http://pastebin.com/2TeWDYiF

The debug code of "cmyth_rcv_ulong" didn't get called, I'm doing now the backtrace thing with gdb.

Ok, I was faster then expected with gdb. Backtrace is available here http://pastebin.com/Sy480sUH.
  • 1
  • 14
  • 15
  • 16(current)
  • 17
  • 18
  • 35

Logout Mark Read Team Forum Stats Members Help
MythTV PVR client Addon Developers Wanted - Developers Only!8