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 - tsp42 - 2012-04-09

It may work now. Too late for more testing (even though sleep is severely overrated).

Edit: please make sure that you have at least version 1.44 installed of libboost as the updated version uses boost-filesystem v3 that is not included before version 1.44



RE: New MythTV add-on using libcmyth - deadite66 - 2012-04-09

compiles in oneirc fine, wouldn't compile properly in natty (possibly due to natty apt repos being broken for me for weeks)



RE: New MythTV add-on using libcmyth - tsp42 - 2012-04-09

Forgot to add the boost library to the Makefile. Should be updated now.


RE: New MythTV add-on using libcmyth - snafle - 2012-04-09

Compiles and launches without problem on Arch x64.


RE: New MythTV add-on using libcmyth - fiveisalive - 2012-04-09

(2012-04-09, 03:33)tsp42 Wrote: It may work now. Too late for more testing (even though sleep is severely overrated).

Edit: please make sure that you have at least version 1.44 installed of libboost as the updated version uses boost-filesystem v3 that is not included before version 1.44

I have boost 1.41 and it looks like it won't compile with old boost now. Unfortunately I'm on an old version of Fedora, and won't be able to update for a while. Is there anyway to compile in backwards-compatible mode, or link against an internally distributed 1.44 boost?

I'm glad that it works with the new version of boost, but I didn't realise this would mean that it wouldn't work with the older versions.




RE: New MythTV add-on using libcmyth - tsp42 - 2012-04-09

fiveisalive: I'm able to link against a self-compiled version of boost v1.46.1 on ubuntu natty (with only have version 1.42 installed) so you should be able to do that. The boost_filesystem and boost_system library is needed for the custom fanarts and icons so it it not possible to avoid them currently.


RE: New MythTV add-on using libcmyth - dodoadoodoo - 2012-04-09

Managed to get it to build and run on an xbmc live 10 installation by downloading the latest boost and then doing:
$ ./bootstrap.sh
$ ./b2
$ sudo ./b2 install
to build and install. Then build xbmc as normal

However, the plugin takes forever to import recordings (I have quite a few), probably because it seems to download not only the "metadata" but also the actual recording (.mpg file). Is this the intention?

/D


RE: New MythTV add-on using libcmyth - tsp42 - 2012-04-09

no it should only fetch the metadata. Are you sure that is downloads the actual recording? Can you check if there are any recordings stored in the coverart or fanart storage group?


RE: New MythTV add-on using libcmyth - fiveisalive - 2012-04-09

(2012-04-09, 18:21)tsp42 Wrote: fiveisalive: I'm able to link against a self-compiled version of boost v1.46.1 on ubuntu natty (with only have version 1.42 installed) so you should be able to do that. The boost_filesystem and boost_system library is needed for the custom fanarts and icons so it it not possible to avoid them currently.

Good to know. Is it possible for xbmc to link against the self-compiled boost, without disturbing the system-wide boost? (I can't replace the system boost without disturbing 100s of packages that are already built against the old boost 1.41).


RE: New MythTV add-on using libcmyth - tsp42 - 2012-04-09

I've added the sorting of recordings into movies / series folders based on duration/genre type and a user definable regular expression.

fiveisalive: Yes I believe so. The system boost library is placed in /usr/lib while the home-made is usually placed in /usr/local/lib.


RE: New MythTV add-on using libcmyth - Jimmer - 2012-04-09

(2012-04-09, 22:19)tsp42 Wrote: I've added the sorting of recordings into movies / series folders based on duration/genre type and a user definable regular expression.

Sounds great, it's really starting to come together now.... however, since the latest merge I now get the following:

Code:
WebServer.cpp: In static member function ‘static int CWebServer::AnswerToConnection(void*, MHD_Connection*, const char*, const char*, const char*, const char*, unsigned int*, void**)’:
WebServer.cpp:158: error: invalid conversion from ‘int (*)(void*, MHD_ValueKind, const char*, const char*, const char*, const char*, const char*, uint64_t, unsigned int)’ to ‘int (*)(void*, MHD_ValueKind, const char*, const char*, const char*, const char*, const char*, size_t, size_t)’
WebServer.cpp:158: error:   initializing argument 3 of ‘MHD_PostProcessor* MHD_create_post_processor(MHD_Connection*, unsigned int, int (*)(void*, MHD_ValueKind, const char*, const char*, const char*, const char*, const char*, size_t, size_t), void*)’
make[1]: *** [WebServer.o] Error 1
make: *** [xbmc/network/network.a] Error 2

when I try to compile on my ATV1. Any pointers? Quick, dirty fixes? It doesn't appear to be a problem compiling on a modern, x86_64 kernel, just the old x86 one with Hardy (2.6.24-28-generic)

Thanks again for all the hard work!

Jimmer

EDIT: if anyone else is having this problem, I got around it by find a hardy deb for libmicrohttpd v4.2 and recompliling....


RE: New MythTV add-on using libcmyth - dodoadoodoo - 2012-04-09

(2012-04-09, 20:33)tsp42 Wrote: no it should only fetch the metadata. Are you sure that is downloads the actual recording? Can you check if there are any recordings stored in the coverart or fanart storage group?

Being lazy I have only configured the default storage group on the b/e. And, yes you are correct, I have both the metadata and actual recordings in those folders (two drives). Seems like someone (cmyth, myth protocol?) is a little bit greedy when fetching the metadata :-)

/D



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

(2012-04-03, 19:38)dodoadoodoo Wrote: We quite often use "chase play" (start a recording, wait a while, begin watching while still recording) in our house. This basically works well, with the exception that the recording length is not updated while watching, it is firmly set to whatever the length was when you started watching. Not a big a deal unless you want to skip forward, at which point it becomes very annoying. Anyway, I took a look at the code, and it seems that the backend periodically informs the frontend of updated recording sizes via the CMYTH_EVENT_UPDATE_FILE_SIZE. So, I added some code in MythEventHandler::ImpMythEventHandler::Action() to store this information, and adapted PVRClientMythTV::LengthRecordedStream() to check if the EventHandler has any uptodate info. This works well, except for the little detail that LengthRecordedStream really should return the length of the stream (as seconds I presume) and not the size in bytes as provided by the backend event.

Now to my questions:
1. Am I going about this the right way?
2. Have I understood the expected units correctly?
3. If yes and yes, then how do I convert the file size to duration? I guess dividing the size with the average bitrate would do the trick, but how would I find the average bitrate?
4. Is there a simpler way to do this?

/D

I looked at doing this exact thing in the standard myth:// protocol handler as we sometimes also end up watching content that is currently recording. I'd already written a bunch of the code and then noticed that the CMYTH_EVENT_UPDATE_FILE_SIZE event wasn't being sent from the backend. After some more digging it seems that the event only gets fired for Live TV, not standard recordings. Might pay to check on that before going too far. Let me know what you find.

I'm going to look at changing it so if the program is currently recording the file length is retrieved from the backend every, say, 5 minutes. I'm pretty sure the "length" needed by the standard CFile interface in XBMC is bytes so that's all fine. As usual I am time poor so this might not happen for a while...

Not sure what the "length recorded stream" API needs for PVR content.


RE: New MythTV add-on using libcmyth - tdavis - 2012-04-10

(2012-04-09, 22:19)tsp42 Wrote: I've added the sorting of recordings into movies / series folders based on duration/genre type and a user definable regular expression.

fiveisalive: Yes I believe so. The system boost library is placed in /usr/lib while the home-made is usually placed in /usr/local/lib.

Oh, good.. but for some reason, on my mythtv setup, it's SeriesTitle:Tonguerogram (seperated by '::').

Any ideas on what to change this to? I've been playing around, but seem to be getting no where..

Oh, never mind.. I figured it out, just added "::.*" and it started to work.



RE: New MythTV add-on using libcmyth - dodoadoodoo - 2012-04-10

(2012-04-10, 01:51)dteirney Wrote:
(2012-04-03, 19:38)dodoadoodoo Wrote: We quite often use "chase play" (start a recording, wait a while, begin watching while still recording) in our house. This basically works well, with the exception that the recording length is not updated while watching, it is firmly set to whatever the length was when you started watching. Not a big a deal unless you want to skip forward, at which point it becomes very annoying. Anyway, I took a look at the code, and it seems that the backend periodically informs the frontend of updated recording sizes via the CMYTH_EVENT_UPDATE_FILE_SIZE. So, I added some code in MythEventHandler::ImpMythEventHandler::Action() to store this information, and adapted PVRClientMythTV::LengthRecordedStream() to check if the EventHandler has any uptodate info. This works well, except for the little detail that LengthRecordedStream really should return the length of the stream (as seconds I presume) and not the size in bytes as provided by the backend event.

Now to my questions:
1. Am I going about this the right way?
2. Have I understood the expected units correctly?
3. If yes and yes, then how do I convert the file size to duration? I guess dividing the size with the average bitrate would do the trick, but how would I find the average bitrate?
4. Is there a simpler way to do this?

/D

I looked at doing this exact thing in the standard myth:// protocol handler as we sometimes also end up watching content that is currently recording. I'd already written a bunch of the code and then noticed that the CMYTH_EVENT_UPDATE_FILE_SIZE event wasn't being sent from the backend. After some more digging it seems that the event only gets fired for Live TV, not standard recordings. Might pay to check on that before going too far. Let me know what you find.

I'm going to look at changing it so if the program is currently recording the file length is retrieved from the backend every, say, 5 minutes. I'm pretty sure the "length" needed by the standard CFile interface in XBMC is bytes so that's all fine. As usual I am time poor so this might not happen for a while...

Not sure what the "length recorded stream" API needs for PVR content.

What version did you test with? I am running a 0.24 b/e and I seem to get the CMYTH_EVENT_UPDATE_FILE_SIZE event for all current recordings.