[murph]

I have posted a fix for the ulong issue murph was seeing here (sorry, I missed the backtrace in his post until today)
http://trac.xbmc.org/ticket/10597

It will only happen while watching LiveTV, and since I can't test that, he'll have to test it.

I've applied the patch, but it breaks LiveTV for me. I've added more info to http://trac.xbmc.org/ticket/10597.

[PhracturedBlue]

Something I'd like additional testing on:
I've been trying to get xbmc to reliably import tv-shows from mythtv. Outleradam outlined a sophisticated solution used by MythLibrarian, and we aren't yet at that level of complexity.

However, using SVN trunk + the patches from http://trac.xbmc.org/ticket/10347 (specifically mythtv-tvshow-library.patch, improve_tv_sort.patch, and import_missing_shows_r2.patch), I seem to be having reasonable success getting programs into xbmc's 'TVShow' database.

If anyone wants to give this a try, please let me know how it goes.

Now that I've learned how the events are handled in xbmc, the next task is to ensure that the database automatically syncs with mythtv.

There are additionally likely lots of tweaks we can do (as outlined in outleradam's previous posts) to improve the capture, but getting the basics nailed down will be a big 1st step.

[outleradam]

If we can get the entire struct cmyth_programinfo {} into the database, then that would provide a great new way to scrape. The scraper would then basically search by zap2it id.

1. performing a download of all of the results from thetvdb (rather then ask which one) and scanning the zap2it id versus the programid. This catches shows like battlestar gallactica (1980) versus battlestar gallactica (2004) automatically, with asking or fuzzy logic as a backup.

2. identify the episode by original airdate, and if not possible, then grep through the title list, then if not possible, agrep the title list.

This should be unified into the standard scrapers somehow because zap2itids and programids go hand in hand on 90% of EPG. However, this method deals more with scraping then it does with MythTV or PVR. If we can get the cmyth_local.h struct cmyth_proginfo {} into the XBMC database, it would be a great step in the right direction.

[PhracturedBlue]

If we can get the entire struct cmyth_programinfo {} into the database, then that would provide a great new way to scrape. The scraper would then basically search by zap2it id.

We already try to use original-airdate to do lookup. Specifically we use airdate, then title, then a fuzzy-match on title (well once my patches are applied).

Using zap2it ids when choosing a program is a good idea. Unfortunately, thetvdb doesn't seem to provide an API to query by zap2it id. You can search from their website, but it seems you must use the title for the API. However, the returned data does include the zap2it id, so you could filter on it after doing a title search which would still help you with your Batlestar Gallactica example.

Edit: an apparently undocumented API lets you do this:
http://thetvdb.com/api/GetSeriesByRemote...t=SH672362
http://thetvdb.com/api/GetSeriesByRemote...=tt0411008
I don't know what it would take to integrate that into xbmc, but it is probably a worthwhile endeavor.

[outleradam]

Don't worry about querying by zap2it ID... it's provided in the first search. Also, guide data does not contain a direct zap2it ID.. We have to match something like
programid:EP07107490102 to zap2itid: SH710749
so we remove any leading EP/SH/MV identifiers, remove leading 0's and truncate the last 4 digits from the programID. Then we remove EP/SH/MV identifiers from TheTvDb's zap2itID and we are matching "710749"

There are a few reasons for using ProgramID
1. people input the data into thetvdb, so sometimes it's SH0710749, SH710749 or even EP710749
2. The ProgramID can be used to filter shows. Leading SH's means the show is not identifiable. MV's mean movie, EP means the show should be in theTvDb.
3. The ShowID provided by MythTV usually starts with an SH. It is what should be in thetvdb, however, sometimes there is a leading 0 and sometimes there is a leading EP.

check this out (make it big to see it):



They have been doing work to thetvdb. That zap2it id was not there in the first search when I defined my search routines. mythicalLibrarian parses each result to get the zap2itID

[outleradam]

nevermind... bad patch.

[outleradam]

I've been doing some reading and I'm becomming more and more familiar with how this works. The problem is that I cannot find real documentation about how our addon interface is supposed to hook into XBMC. The protocol is not really documented. I realize the code itself can serve as a documentation of sorts, but every time I try to read it, it takes me way into the depths of XBMC.

We need some sort of a unified front-end developers manual which says something like: guide data should be fed into this module in this format with these filters in place, and events should be routed into the event server in this method.

I'm seeing in the wiki vague entries which say people are doing things and are responsible for them, but I'm not really seeing where the changes are being made.

Would anyone find it helpful if I were to create a small application which would allow communications and display of data to MythTV? I think I could easily write some sort of interface to connect, send and receive messages.

[outleradam]

I wrote this simple Java program to communicate with MythBackend over MythProtocol. You can see what you send and what it types. Using this program, MythTV thinks you are a backend and will send and receive it's common data.

Here is a video of it in action:
http://www.youtube.com/watch?v=yspkQLQ0H1A

Here is the actual file:
http://www.mediafire.com/file/459up2yp6n...m_Diag.jar

You can reference commands from here:
http://www.mythtv.org/wiki/Category:Myth...l_Commands

<<<----Click that little scales button if you find this useful

[PhracturedBlue]

My current goal is to have the Video library stay synchronized at all times. I am not quite ready to do that though.

First I need to understand the MythSession stuff better. We currently open a connection to the server (via CMythSession) and when we're done, we release the session. If the session is not reused within 5 seconds, it will be terminated, and the next request will need to open it again. If the session is reused within 5 seconds, the previous myth connection is maintained.

In both cases, because the cache is based on the results of parsing the proginfo list, and not the list itself, xbmc ends up querying proginfo many times in sequence (once for tv-shows, once for movies, etc)

Does anyone know why it is done this way? I want a persistent MythSessino connection rather than an on-demand one. I am not sure why there is an idle handler to close idle MythSessions

So far, I have done the following:
a) removed the idle handler
b) move all calls to proglist_get_all_recorded to call through MythSession
c) cache the proginfo results in CMythSession, and return the cached result if available
d) Refresh the cache whenever a backend message is received indicating that the recording-list has changed

With this implementation, xbmc is much faster parsing my 2000 recorded programs (the current implementation re-reads the full proglist virtually all the time despite cacheing being set). With my changes, it is only ever read when it changes.

This seems to work well, but I'm wondering what the downside of a persistent connection is.

Assuming there isn't a good reason for it, it should now be pretty easy to call the Video processing code each time the proginfo cache is updated. The last piece will be to start a MythSession as xbmc starts. I'm not yet sure how to manage that.

[outleradam]

That's great news. That's what I was saying about my network running continuously transferring the same information.

I can only make an educated guess about the 5 second timer. The XBOX was only recently decomissioned as a platform for XBMC. One of the problems with the XBOX was that it has a limited amount of memory. It could have been an crude implementation of a way to free memory if it was not required.

Another possibility is that disconnecting every 5 seconds is a way to skirt listening for backend messages http://wiki.mythtv.com/wiki/BACKEND_MESS...h_Protocol)

You might be able to look at the lastfm implementation for a reference as to how to autostart the MythTV connection. If I have a bad password input into the LasfFM settings, on startup it will send a notice that I have a bad password sometimes. Another option would be to enable a load on startup option like what is present in scan video/music library on startup.

Are you working with trunk or the PVR branch? I can't seem to make the PVR compile with the current patches. Should I try to see what it would take to merge trunk libcmyth into PVR?

[PhracturedBlue]

That's great news. That's what I was saying about my network running continuously transferring the same information.

I can only make an educated guess about the 5 second timer. The XBOX was only recently decomissioned as a platform for XBMC. One of the problems with the XBOX was that it has a limited amount of memory. It could have been an crude implementation of a way to free memory if it was not required.

You might be able to look at the lastfm implementation for a reference as to how to autostart the MythTV connection. If I have a bad password input into the LasfFM settings, on startup it will send a notice that I have a bad password sometimes. Another option would be to enable a load on startup option like what is present in scan video/music library on startup.

Are you working with trunk or the PVR branch? I can't seem to make the PVR compile with the current patches. Should I try to see what it would take to merge trunk libcmyth into PVR?

I'm only working on the trunk, as my work is currently orthogonal to the PVR based work. I'll talk to dteirney offline as to whether it makes more sense to put all these myth related changes in the pvr branch

[dteirney]

Should I try to see what it would take to merge trunk libcmyth into PVR?

If you don't know enough about libcmyth to make changes to it and can't get the existing PVR related patches compiling I think you'll just be wasting your time trying to do this.

I'll be porting libcmyth to the PVR branch in the next few weeks.

[outleradam]

I have the existing PVR branches compiled. The problems I was having was merging the current changes into PVR. Apparently the supporting libraries are out of date. But you're right, you would be far more effective at performing these changes.

[outleradam]

Just rm -Rf'd, co'd, ./bootstrap && ./configure && make -j5 && xbmc.bin.. Trunk works with mythtv 0.24.

Any chance we can locally translate/DNS the host name into the backend IP?

[PhracturedBlue]

Any chance we can locally translate/DNS the host name into the backend IP?

http://trac.xbmc.org/ticket/10650