Kodi Community Forum
New MythTV add-on using libcmyth - 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: New MythTV add-on using libcmyth (/showthread.php?tid=110694)



RE: New MythTV add-on using libcmyth - InoD - 2012-05-06

There is something else I'd like to look into too. (oh, what have I gotten myself into Wink)
When resuming from standby I get some strange behaviour from the PVR addon. The recordings list is not updated, I sometimes cannot play any recordings and while playing another video I get notifications frequently that recordings are finished or deleted, which is obviously not the case. Not sure if this is related to the mythtv addon specifically or to the PVR system as a whole.
Does anyone recognize this?


RE: New MythTV add-on using libcmyth - tsp42 - 2012-05-06

I suspect that it is because the connection(socket) to the backend is broken when resuming from standby. Currently there is no code to try reestablishing the connection. The libcmyth code that has to be updated. We/I need to add a new function to update the cmyth_conn_t struct.

Any help will of course be highly appreciated. As you may have discovered it can be quite time consuming to fix all these bugs.


RE: New MythTV add-on using libcmyth - InoD - 2012-05-06

Ok, I'll have a look at how this is implemented best. Will probably take some time though....


RE: New MythTV add-on using libcmyth - bilbonvidia - 2012-05-09

(2012-05-06, 21:08)tsp42 Wrote: bilbonvidia: Does it lockup when the program changes like fiveisalive is seeing or when you start xbmc?


It is when changing channel. I am currently running on the last commit before timeshift. Let me know if you want me to upgrade again to try anything testing wise.




RE: New MythTV add-on using libcmyth - bas.t - 2012-05-10

EDIT: This is not relevant anymore. I think commit 91bfc4eaed took care of this.

Hi,
I'm trying to compile but I get errors:

Code:
CPP     xbmc/guilib/GUIListItemLayout.o
fileOps.h: In constructor ‘fileOps2::fileOps2(MythConnection&)’:
fileOps.h:53: warning: ‘fileOps2::m_con’ will be initialized after
fileOps.h:52: warning:   ‘boost::filesystem::path fileOps2::m_localBasePath’
fileOps.cpp:16: warning:   when initialized here
fileOps.h:54: warning: ‘fileOps2::m_sg_strings’ will be initialized after
fileOps.cpp:17: warning:   base ‘PLATFORM::CThread’
fileOps.cpp:16: warning:   when initialized here
fileOps.cpp:21: error: ‘struct boost::filesystem::path’ has no member named ‘c_str’
fileOps.cpp: In member function ‘CStdString fileOps2::getChannelIconPath(CStdString)’:
fileOps.cpp:42: error: ‘struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ has no member named ‘string’
fileOps.cpp: In member function ‘CStdString fileOps2::getPreviewIconPath(CStdString)’:
fileOps.cpp:63: error: ‘struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ has no member named ‘string’
fileOps.cpp: In member function ‘CStdString fileOps2::getArtworkPath(CStdString, FILE_OPTIONS)’:
fileOps.cpp:95: error: ‘struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ has no member named ‘string’
fileOps.cpp: In member function ‘void fileOps2::cleanCache()’:
fileOps.cpp:142: error: ‘struct std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ has no member named ‘string’
fileOps.cpp:151: warning: comparison between signed and unsigned integer expressions
fileOps.cpp:150: warning: unused variable ‘mlm’
fileOps.cpp: In member function ‘bool fileOps2::writeFile(boost::filesystem::path, MythFile&)’:
fileOps.cpp:240: error: ‘struct boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits>’ has no member named ‘c_str’
fileOps.cpp:246: error: ‘struct boost::filesystem::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem::path_traits>’ has no member named ‘c_str’
fileOps.cpp:294: error: ‘struct boost::filesystem::path’ has no member named ‘c_str’
make[1]: *** [fileOps.o] Fout 1
make[1]: Map '/usr/src/setup/xbmc/xbmc/pvrclients/mythtv-cmyth' wordt verlaten
make: *** [pvrclients] Fout 2

I am compiling on Debian Squeeze.
Opdenkamps repo compiles just fine.
What can I do to prevent these errors?


RE: New MythTV add-on using libcmyth - dteirney - 2012-05-10

@bas.t you need to upgrade libboost to 1.46 or later.


RE: New MythTV add-on using libcmyth - Powderking - 2012-05-10

I'm still following your build and still use it as my frontend.
I wanted to say again thank you for your work!
It's great to see it developping Big Grin

I was amazed when I saw that preview and channel pics work now when the backend is on a different machine. And the categories are wonderful too Big Grin


Even though I have three little issues:

The categories aren't always perfect. E.g. I have a movies category where I have lots of recordings. But none of them is a movie. I understand that you sort them by program title only. But mythfrontend does it somehow different. I have a much better categroization there.
Will you be able to change that someday or is this a limitation of the cmyth library?

The next issue is when I enter this movies category (in fact any with a large number of recordings) it takes minutes until the recordings are listed. I read something about that it downloads all the covers. Has this to do with it?

And the last thing is that I like to have the newest recordings on the top. But When I sort one category the others aren't affected. Would it be possible to implement a menu entry or something that sets everything to be sorted be date?


Thank you again very much for your great work!


RE: New MythTV add-on using libcmyth - lunarok - 2012-05-11

Hi,

I read with attention your work, but I cannot use your git repo for compiling as I'm using MythTV 0.25. And this is going to be common as it's the version include in Ubuntu 12.04, so the version of Mythbuntu too.

But Daniel Teirney has patched the cmyth for support of MythTV 0.25 (https://github.com/dteirney/xbmc/tree/myth-0.25)
And seems it has been pull to the main branch of XBMC git (https://github.com/xbmc/xbmc cmyth 19 hours ago [cmyth] Fix memory corruption caused by incorrect size allocation for… [David Teirney])

Is it possible to merge your lib directory from the xbmc git so we will have the new version of cmyth and support of 0.25 ?
As your addon is full cmyth based, must be enough to get xbmc-pvr working with myth 0.25

Am I wrong ?


RE: New MythTV add-on using libcmyth - Jimmer - 2012-05-11

(2012-05-11, 11:03)lunarok Wrote: Hi,

I read with attention your work, but I cannot use your git repo for compiling as I'm using MythTV 0.25. And this is going to be common as it's the version include in Ubuntu 12.04, so the version of Mythbuntu too.

But Daniel Teirney has patched the cmyth for support of MythTV 0.25 (https://github.com/dteirney/xbmc/tree/myth-0.25)
And seems it has been pull to the main branch of XBMC git (https://github.com/xbmc/xbmc cmyth 19 hours ago [cmyth] Fix memory corruption caused by incorrect size allocation for… [David Teirney])

Is it possible to merge your lib directory from the xbmc git so we will have the new version of cmyth and support of 0.25 ?
As your addon is full cmyth based, must be enough to get xbmc-pvr working with myth 0.25

Am I wrong ?

five has managed it here:

http://forum.xbmc.org/showthread.php?tid=129021&pid=1098065#pid1098065

it needs a file patching, and this was done a little while ago, but it may still be working. Probably better to wait a few days for it to get merged into Dushmaniac, and then again here. It'll happen soon, I'm sure


RE: New MythTV add-on using libcmyth - fiveisalive - 2012-05-12

(2012-05-11, 12:15)Jimmer Wrote:
(2012-05-11, 11:03)lunarok Wrote: Hi,

I read with attention your work, but I cannot use your git repo for compiling as I'm using MythTV 0.25. And this is going to be common as it's the version include in Ubuntu 12.04, so the version of Mythbuntu too.

But Daniel Teirney has patched the cmyth for support of MythTV 0.25 (https://github.com/dteirney/xbmc/tree/myth-0.25)
And seems it has been pull to the main branch of XBMC git (https://github.com/xbmc/xbmc cmyth 19 hours ago [cmyth] Fix memory corruption caused by incorrect size allocation for… [David Teirney])

Is it possible to merge your lib directory from the xbmc git so we will have the new version of cmyth and support of 0.25 ?
As your addon is full cmyth based, must be enough to get xbmc-pvr working with myth 0.25

Am I wrong ?

five has managed it here:

http://forum.xbmc.org/showthread.php?tid=129021&pid=1098065#pid1098065

it needs a file patching, and this was done a little while ago, but it may still be working. Probably better to wait a few days for it to get merged into Dushmaniac, and then again here. It'll happen soon, I'm sure

I tested patching tsp's cmyth branch with the myth-0.25 patch and I have it "working" in the sense that it loads the EPG and channel info. I tested this on a separate machine with no video card, using the "dummy tuner" module built into the mythbackend, so I was unable to test Live TV or recording playback, but at least the EPG/schedule and channel info loads correctly, which is generally a good sign.



RE: New MythTV add-on using libcmyth - InoD - 2012-05-12

Support for graceful reconnecting doesn't seem to be very straightforward, at least, not at the level I'd like to have it implemented.
The cmyth library sets conn_hang in the cmyth_conn_t structure, which can be retrieved using the ConnHung function. However, if you want to initiate the reconnecting from XBMC side (MyhTV PVR Client code), then each function communicating with the library should first check the connection (ConnHung) and if hung initiate the reconnecting. That will result in a lot of code, but you will be able to create notifications.
If implemented at the other end, connection.c in the library, then the connection could be reconnected right where and when it is detected to be disconnected. XBMC will not know it has reconnected, also you might run into an infinite reconnecting loop. But, I think the library should be dumb and not do such a thing unless it is requested to do so.

XBMC offers some functionality to detect when waking up from standby, this could be used to force reconnecting (if you know the connection is gone it is faster to reconnect than the wait for the next command to fail), but having a reconnect mechanism will also cover the other use-cases in which the connection could have been closed.

What do you think is the best way to implement this? Do you have other ideas?


RE: New MythTV add-on using libcmyth - tdavis - 2012-05-13

(2012-05-12, 17:49)fiveisalive Wrote:
(2012-05-11, 12:15)Jimmer Wrote:
(2012-05-11, 11:03)lunarok Wrote: Hi,

I read with attention your work, but I cannot use your git repo for compiling as I'm using MythTV 0.25. And this is going to be common as it's the version include in Ubuntu 12.04, so the version of Mythbuntu too.

But Daniel Teirney has patched the cmyth for support of MythTV 0.25 (https://github.com/dteirney/xbmc/tree/myth-0.25)
And seems it has been pull to the main branch of XBMC git (https://github.com/xbmc/xbmc cmyth 19 hours ago [cmyth] Fix memory corruption caused by incorrect size allocation for… [David Teirney])

Is it possible to merge your lib directory from the xbmc git so we will have the new version of cmyth and support of 0.25 ?
As your addon is full cmyth based, must be enough to get xbmc-pvr working with myth 0.25

Am I wrong ?

five has managed it here:

http://forum.xbmc.org/showthread.php?tid=129021&pid=1098065#pid1098065

it needs a file patching, and this was done a little while ago, but it may still be working. Probably better to wait a few days for it to get merged into Dushmaniac, and then again here. It'll happen soon, I'm sure

I tested patching tsp's cmyth branch with the myth-0.25 patch and I have it "working" in the sense that it loads the EPG and channel info. I tested this on a separate machine with no video card, using the "dummy tuner" module built into the mythbackend, so I was unable to test Live TV or recording playback, but at least the EPG/schedule and channel info loads correctly, which is generally a good sign.

I did this:

Code:
mkdir xbmc
cd xbmc
git clone --branch myth-0.25 https://github.com/dteirney/xbmc.git dt
cd dt
git diff 00e6c1c > ../xbmc-myth-0.25.patch
cd ..
git clone https://github.com/tsp/xbmc.git tsp
cd tsp/
patch -p1 < ../xbmc-myth-0.25.patch

And then patch lib/cmyth/libcmyth/connection.c with

Code:
--- tsp2/lib/cmyth/libcmyth/connection.c        2012-05-12 15:08:00.476169895 -0700
+++ tsp/lib/cmyth/libcmyth/connection.c 2012-05-11 11:03:48.980341238 -0700
@@ -754,6 +754,11 @@
                          __FUNCTION__, host, port, buflen);
                goto shut;
        }
+        /*
+        * Explicitly set the conn version to the control version as cmyth_connect() doesn't and some of
+        * the cmyth_rcv_* functions expect it to be the same as the protocol version used by mythbackend.
+        */
+       conn->conn_version = control->conn_version;

        ann_size += strlen(path) + strlen(my_hostname) + strlen(sgToGetFrom) + 6;
        announcement = malloc(ann_size);

and compiled it up.

Everything works - LiveTV, Recordings, EPG.



RE: New MythTV add-on using libcmyth - tsp42 - 2012-05-13

I've ported the addon to the stable Eden PVR branch. You should be able to "git checkout Eden-PVR" now. Next change will be to add the MythTV 0.25 patch.

(2012-05-09, 15:18)bilbonvidia Wrote:
(2012-05-06, 21:08)tsp42 Wrote: bilbonvidia: Does it lockup when the program changes like fiveisalive is seeing or when you start xbmc?
It is when changing channel. I am currently running on the last commit before timeshift. Let me know if you want me to upgrade again to try anything testing wise.
It would be nice if you could provide me with a stack trace as outlined in the first post.
(2012-05-10, 12:44)Powderking Wrote: I'm still following your build and still use it as my frontend.
I wanted to say again thank you for your work!
It's great to see it developping Big Grin

I was amazed when I saw that preview and channel pics work now when the backend is on a different machine. And the categories are wonderful too Big Grin


Even though I have three little issues:

The categories aren't always perfect. E.g. I have a movies category where I have lots of recordings. But none of them is a movie. I understand that you sort them by program title only. But mythfrontend does it somehow different. I have a much better categroization there.
Will you be able to change that someday or is this a limitation of the cmyth library?
Currently the addon uses the genre type, duration, the MythTV programID and an optional regex to test if a recording is a movie or not. The genre type currently only works for EPG data that follows the DVB genre type convention (=cable TV). I plan to add support for mapping other genres to the ones supported by xbmc. The genres are defined in pvrclient-mythtv.cpp.
Quote:The next issue is when I enter this movies category (in fact any with a large number of recordings) it takes minutes until the recordings are listed. I read something about that it downloads all the covers. Has this to do with it?
No the addon downloads the covers in the background so it shouldn't cause any slowdowns.
Quote:And the last thing is that I like to have the newest recordings on the top. But When I sort one category the others aren't affected. Would it be possible to implement a menu entry or something that sets everything to be sorted be date?

Thank you again very much for your great work!
It could be done. I think it currently uses the default value for the video folders. You may want to add the request to the official XBMC PVR repository as it is not addon specific.

(2012-05-12, 20:40)InoD Wrote: Support for graceful reconnecting doesn't seem to be very straightforward, at least, not at the level I'd like to have it implemented.
The cmyth library sets conn_hang in the cmyth_conn_t structure, which can be retrieved using the ConnHung function. However, if you want to initiate the reconnecting from XBMC side (MyhTV PVR Client code), then each function communicating with the library should first check the connection (ConnHung) and if hung initiate the reconnecting. That will result in a lot of code, but you will be able to create notifications.
If implemented at the other end, connection.c in the library, then the connection could be reconnected right where and when it is detected to be disconnected. XBMC will not know it has reconnected, also you might run into an infinite reconnecting loop. But, I think the library should be dumb and not do such a thing unless it is requested to do so.

XBMC offers some functionality to detect when waking up from standby, this could be used to force reconnecting (if you know the connection is gone it is faster to reconnect than the wait for the next command to fail), but having a reconnect mechanism will also cover the other use-cases in which the connection could have been closed.

What do you think is the best way to implement this? Do you have other ideas?
Well my suggestion would be to add the check to the MythConnection, MythEventHandler::ImpMythEventHandler, MythFile and MythRecorder class. We would also have to add a new cmyth function to reconnect an existing cmyth_conn_t structure. This would save the trouble of renewing and tracking all the cmyth pointers in the c++ code. I don't have much experience with socket programming but I suspect that the current way of detecting a hung connection in socket.c is not the best way to do it.



RE: New MythTV add-on using libcmyth - fiveisalive - 2012-05-13

(2012-05-13, 00:09)tdavis Wrote: I did this:

Code:
mkdir xbmc
cd xbmc
git clone --branch myth-0.25 https://github.com/dteirney/xbmc.git dt
cd dt
git diff 00e6c1c > ../xbmc-myth-0.25.patch
cd ..
git clone https://github.com/tsp/xbmc.git tsp
cd tsp/
patch -p1 < ../xbmc-myth-0.25.patch

And then patch lib/cmyth/libcmyth/connection.c with

Code:
--- tsp2/lib/cmyth/libcmyth/connection.c        2012-05-12 15:08:00.476169895 -0700
+++ tsp/lib/cmyth/libcmyth/connection.c 2012-05-11 11:03:48.980341238 -0700
@@ -754,6 +754,11 @@
                          __FUNCTION__, host, port, buflen);
                goto shut;
        }
+        /*
+        * Explicitly set the conn version to the control version as cmyth_connect() doesn't and some of
+        * the cmyth_rcv_* functions expect it to be the same as the protocol version used by mythbackend.
+        */
+       conn->conn_version = control->conn_version;

        ann_size += strlen(path) + strlen(my_hostname) + strlen(sgToGetFrom) + 6;
        announcement = malloc(ann_size);

and compiled it up.

Yep, that was almost exactly the same set of commands as in my post (but a bit neater than mine).

Quote:Everything works - LiveTV, Recordings, EPG.

Good to hear!


RE: New MythTV add-on using libcmyth - fiveisalive - 2012-05-13

(2012-05-13, 21:53)tsp42 Wrote: I've ported the addon to the stable Eden PVR branch. You should be able to "git checkout Eden-PVR" now. Next change will be to add the MythTV 0.25 patch.

Great news! I would like to add the complete pvr patch against the original stock Eden source in the xbmc package I maintain for Fedora/RPM Fusion. Can you clue me in to which git commit I should use to create the diff/patch?

Second, is the plan to backport features from master to this new branch on a semi-regular basis? The myth 0.25 patch will be critical since Fedora/RPM Fusion only ships with myth >= 0.25.

Third, if I move the files for the add-on client into a separate subpackage (so only that subpackage is dependent on a backend, eg myth), would that cause a probably for xbmc itself? i.e. some people might want xbmc without pvr/myth and having a separate xbmc-{mythtv,tvheadend} packages only containg the addon parts would workaround this.

Lastly, do you know what the plan is for dushmaniac's merge to upstream? I wasn't able to find on open pull request on github, or a forum post about this, but I noticed that development on the addon seems to have stopped in his branch, and there was one forum post that alluded to him preparing for the merge, but nothing from him directly about the schedule for that.