[tsp42]

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.

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.

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

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


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.

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.

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.

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.