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 - janbar - 2013-01-01

(2012-12-31, 17:44)Nachteule Wrote:
(2012-12-31, 02:07)janbar Wrote: If you have always this issue with 0.26, then i think you use an old commit of the addon. Take care about "make zip": the zip is not updated with lastest compiled binary. Use instead "make clean zip". And unzip directly the new addon into the folder ~/.xbmc/addons/
Br

Hi janbar,

thanks for your help

As i wrote at the beginning, i already use MythTv 0.26. I don't believe that i have an old commit, i fetched my version Dec 22 17:56 from fetzerch's git, and i already know about this "make zip" issue, however i don't use this because i only copy the new XBMC_MythTV_cmyth.pvr into XBMC's folder (make clean zip takes too much time on my HTPC).

Currently i'm using a workaround, i fetch up to 4 times for the correct proginfo, mostly i get the correct info at the 2nd try, however sometimes 4 requests are needed.
And that's my problem, i get the wrong (old) proginfo from backend. But the real new info is needed to put it into the chain.

In my point of view there could be 2 reasons for this behavior:
1) one or more old proginfo's are in the queue
2) backend send's the update requests too early and if the client asks for new proginfo, the new file does not exist and the old file will be received

If you would like to have a look to the full log (it's a log before i made any changes in source), you can download it here https://www.hidrive.strato.com/lnk/7OPAjr2P
The interesting part is around 01:40:00, at this time old show ends and new show begins

Happy new year to all
Hi, yes we know this case. Backend send chain update event, but query recorder returns old proginfo. There is already a workaround for it in cmyth by catching event done_recording. But since bedouin reported an issue on 0.24, i updated the code to try also chain update events during the program break. So it could try to insert old program. Anyway the old program go to the trash. The code must to support at least 0.24. And this case is not an issue. If you have stop show issue with 0.26, then your client didn't receive the event done_recording. I will have a look on your log. Thanks.
Happy new year Wink



Loading channels and EPG taking a long time with MYSQL error - dteirney - 2013-01-01

I just updated to the latest version of the addon and XBMC last night and now loading of the channels etc. after startup takes ages and has the following show up in the XBMC log over and over again. I can't find any documentation on the recordedartwork table in the MythTV wiki (http://www.mythtv.org/wiki/Database_Schema). I'm still using Myth 0.24 so perhaps that table is only present in later version of MythTV?

Code:
20:06:56 T:139914543249152   ERROR: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_mysql_query_result: mysql_query(SELECT coverart, fanart, banner FROM recordedartwork WHERE inetref = NULL AND season = 0 AND host = 'davmyth';) Failed: Table 'mythconverg.recordedartwork' doesn't exist



RE: Loading channels and EPG taking a long time with MYSQL error - janbar - 2013-01-01

(2013-01-01, 09:17)dteirney Wrote: I just updated to the latest version of the addon and XBMC last night and now loading of the channels etc. after startup takes ages and has the following show up in the XBMC log over and over again. I can't find any documentation on the recordedartwork table in the MythTV wiki (http://www.mythtv.org/wiki/Database_Schema). I'm still using Myth 0.24 so perhaps that table is only present in later version of MythTV?

Code:
20:06:56 T:139914543249152   ERROR: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_mysql_query_result: mysql_query(SELECT coverart, fanart, banner FROM recordedartwork WHERE inetref = NULL AND season = 0 AND host = 'davmyth';) Failed: Table 'mythconverg.recordedartwork' doesn't exist

Hi, yes i must to add to db version check. This feature exists since 0.25. I prepare a patch for this new year.


RE: Loading channels and EPG taking a long time with MYSQL error - janbar - 2013-01-01

(2013-01-01, 15:56)janbar Wrote:
(2013-01-01, 09:17)dteirney Wrote: I just updated to the latest version of the addon and XBMC last night and now loading of the channels etc. after startup takes ages and has the following show up in the XBMC log over and over again. I can't find any documentation on the recordedartwork table in the MythTV wiki (http://www.mythtv.org/wiki/Database_Schema). I'm still using Myth 0.24 so perhaps that table is only present in later version of MythTV?

Code:
20:06:56 T:139914543249152   ERROR: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_mysql_query_result: mysql_query(SELECT coverart, fanart, banner FROM recordedartwork WHERE inetref = NULL AND season = 0 AND host = 'davmyth';) Failed: Table 'mythconverg.recordedartwork' doesn't exist

Hi, yes i must to add to db version check. This feature exists since 0.25. I prepare a patch for this new year.

Fixed with PR #74



RE: New MythTV add-on using libcmyth - janbar - 2013-01-01

(2012-12-29, 01:54)Nachteule Wrote: Timer can not be deactivated, but deleting works

If i deactivate a timer, the state goes to "error", however in the backend this timer is deactivated.

Following patch solves the problem, timer can be activated/deactivated:

Code:
--- pvrclient-mythtv.cpp-orig   2012-12-22 17:56:29.000000000 +0100
+++ pvrclient-mythtv.cpp        2012-12-27 22:18:23.496017163 +0100
@@ -974,7 +974,7 @@
       break;
     case RS_LATER_SHOWING:
     case RS_REPEAT:
-    case RS_INACTIVE:
+    //case RS_INACTIVE:
     case RS_NEVER_RECORD:
     case RS_OFFLINE:
     case RS_OTHER_SHOWING:
@@ -985,6 +985,7 @@
     case RS_LOW_DISKSPACE:
       tag.state = PVR_TIMER_STATE_ERROR;
       break;
+    case RS_INACTIVE:
     case RS_CANCELLED:
     case RS_MISSED:
     default:
Perhaps janbar or fetzerch can test it and merge it into git

Thanks. I removed all unused states from cases. Default state will be DISABLED. The PR is #75.



RE: New MythTV add-on using libcmyth - Nachteule - 2013-01-01

(2013-01-01, 16:59)janbar Wrote: Thanks. I removed all unused states from cases. Default state will be DISABLED. The PR is #75.

Perfect, thanks. It's the better way Smile


RE: New MythTV add-on using libcmyth - Nachteule - 2013-01-02

@janbar

(2013-01-01, 06:25)janbar Wrote: Hi, yes we know this case. Backend send chain update event, but query recorder returns old proginfo. There is already a workaround for it in cmyth by catching event done_recording. But since bedouin reported an issue on 0.24, i updated the code to try also chain update events during the program break. So it could try to insert old program. Anyway the old program go to the trash. The code must to support at least 0.24. And this case is not an issue. If you have stop show issue with 0.26, then your client didn't receive the event done_recording. I will have a look on your log. Thanks.
Happy new year Wink

thanks for your help.

Maybe i misunderstand you - my client does receive the event_done_recording, but querying proginfo will return old data.
What i did is requesting proginfo up to 5 times. Sometimes i have to do 4 reasks until receiving correct proginfos. It's a very strange thing for me.




RE: New MythTV add-on using libcmyth - janbar - 2013-01-02

@Nachteule

Never see that after done_recording event in a active livetv chain. What is your version/commit of myth 0.26 ?
We should be able to reproduce it.
Thanks.

Edit: also what is your os and arch for myth backend. It could be help us to test the thing.
Thanks.


RE: New MythTV add-on using libcmyth - Nachteule - 2013-01-02

Hi janbar
(2013-01-02, 11:37)janbar Wrote: @Nachteule

Never see that after done_recording event in a active livetv chain. What is your version/commit of myth 0.26 ?
We should be able to reproduce it.
Thanks.

Edit: also what is your os and arch for myth backend. It could be help us to test the thing.
Thanks.

I got my myth from here: http://packman.links2linux.de/package/mythtv-0_26/354930. I started with version mythtv-0_26-0.26.0-1.3, 5 then i updated to mythtv-0_26-0.26.0-3.1 five days ago. However, this newer version seems to make more trouble than the 1st one (files of current livetv chain were deleted automatically during livetv, stopping livetv, and crashing of mythbackend). So, yesterday i compiled my own mythtv-0_26-0.26.0-3.2.rpm which i am using now since yesterday evening. I looked to the changelog, this version has myth fixes until dec 23.

My system runs under openSUSE 12.1 x86_64, 8GB Ram, AMD Eden E-350 CPU. Backend and XBMC runs on the same machine

XBMC is Frodo RC2 and myth addon comes from fetzerch's git cloned Dec 22.

If you are interested of my hack of function cmyth_livetv_chain_update in livetv.c, you can see it here http://pastebin.com/XQJsKLRP

Hope that helps


RE: New MythTV add-on using libcmyth - janbar - 2013-01-02

@Nachteule

I test addon with nightly mythtv 0.26 from mythbuntu. So probably we have the same fix. Also i haven't any problem with program break or others. During my last bench the tv chain counted 83 breaks before i stop it. So i think your issue is other. In previous post i saw that you use tmpfs to store livetv recordings. I think it is not a good way. This special filesystem is normally use to share large memory segment between process. Also a tv chain count lot of big files larger than your memory or swap available. These files should be stored like others recordings files and they still open until end. I propose you to try to store livetv files to permanent storage and see what happen.
Br.

Edit: I think also you should cleanup your backend database by removing manually all livetv recordings rows because they don't exist any more (tmpfs!) and normally deletions are managed by backend itself.

Edit: Reading your hack i saw you haven't the last livetv fix (commit 4647f111e85c1131025ec857ff4917dd664f6adc). This fix could be help you to resolve your issue. It is part of my PR for bedouin (PR #73).


RE: New MythTV add-on using libcmyth - Nachteule - 2013-01-02

@janbar

(2013-01-02, 21:04)janbar Wrote: @Nachteule

I test addon with nightly mythtv 0.26 from mythbuntu. So probably we have the same fix. Also i haven't any problem with program break or others. During my last bench the tv chain counted 83 breaks before i stop it. So i think your issue is other. In previous post i saw that you use tmpfs to store livetv recordings. I think it is not a good way. This special filesystem is normally use to share large memory segment between process. Also a tv chain count lot of big files larger than your memory or swap available. These files should be stored like others recordings files and they still open until end. I propose you to try to store livetv files to permanent storage and see what happen.
Br.

Edit: I think also you should cleanup your backend database by removing manually all livetv recordings rows because they don't exist any more (tmpfs!) and normally deletions are managed by backend itself.

My problems also occurs without tmpfs. I only used tmpfs for 2 reasons:
1) to check if this makes any difference or not. It does not.
2) If disk is under heavy load (copy large files, unzip rar's), live-tv is totally unusable
.
Backup database is clear, sometimes i use the script from here http://www.mythtv.org/wiki/Find_orphans.py, and btw, mythbackend automatically removes files if more space is needed

3 hours ago i went back to normal disk (ext4) for my live-tv folder

Maybe my problem has an other reason, but fact is, the addon has sometimes to request new proginfo more than 1 times.

But of course, if you can't reproduce this, you can't find out what's going on.




RE: New MythTV add-on using libcmyth - janbar - 2013-01-03

@Nachteule
Have you updated mount options for your ext4 fs ?
I check mine and then i will post them.

Other ways if you haven't hi level raid 0 for your storage. I haven't one for the htpc. I use a simple hd 2.5" 1TB.
- Deactivate mythcommflag or activate only during the night if you use it.
- Fix to 1 the max running job for transcode.
- etc... So limit the activities depending of your config.

I use these options to mount my ext4 filesystem where recordings are stored:
UUID=644d22c8-5086-4326-98cc-89f3725be082 /local ext4 noatime,nodiratime 0 2


RE: New MythTV add-on using libcmyth - Nachteule - 2013-01-03

(2013-01-03, 12:03)janbar Wrote: @Nachteule
Have you updated mount options for your ext4 fs ?
I check mine and then i will post them.

Other ways if you haven't hi level raid 0 for your storage. I haven't one for the htpc. I use a simple hd 2.5" 1TB.
- Deactivate mythcommflag or activate only during the night if you use it.
- Fix to 1 the max running job for transcode.
- etc... So limit the activities depending of your config.

I use these options to mount my ext4 filesystem where recordings are stored:
UUID=644d22c8-5086-4326-98cc-89f3725be082 /local ext4 noatime,nodiratime 0 2

I also have a 1TB 2.5" HD, volume is mounted with "acl,user_xattr,noatime", all volumes except /boot are in a LVM2

mythcommflag, transcode are not used, i tested this features several times but results were very disappointing. And, i don't need them.

Last night i run a long test without any user interactions, just running live-tv. here are my results

Code:
Jan  2 23:00:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 1034_20130102220000.mpg
Jan  3 00:30:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 1034_20130102233000.mpg
Jan  3 02:48:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103014800.mpg
Jan  3 03:29:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103022900.mpg
Jan  3 03:32:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 2 retrys needed before getting correct url 17403_20130103023200.mpg
Jan  3 04:05:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103030500.mpg
Jan  3 04:18:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103031800.mpg
Jan  3 05:04:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103040400.mpg
Jan  3 05:57:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103045700.mpg
Jan  3 06:45:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103054500.mpg
Jan  3 07:34:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103063400.mpg
Jan  3 08:03:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 1 retrys needed before getting correct url 17403_20130103070300.mpg
Jan  3 08:32:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103073200.mpg
Jan  3 09:33:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 2 retrys needed before getting correct url 17403_20130103083300.mpg
Jan  3 10:00:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 4 retrys needed before getting correct url 17403_20130103090000.mpg
Jan  3 10:29:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103092900.mpg
Jan  3 10:56:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 1 retrys needed before getting correct url 17403_20130103095600.mpg
Jan  3 11:49:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103104900.mpg
Jan  3 12:18:00 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 1 retrys needed before getting correct url 17403_20130103111800.mpg
Jan  3 12:47:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 3 retrys needed before getting correct url 17403_20130103114700.mpg
Jan  3 13:17:01 T:139870131328768    INFO: AddOnLog: MythTV cmyth PVR Client: LibCMyth: (cmyth)cmyth_livetv_chain_update: 0 retrys needed before getting correct url 17403_20130103121700.mpg


You can see, every 3rd show would be stopped without my hack.


RE: New MythTV add-on using libcmyth - janbar - 2013-01-03

@Nachteule

I have analyzed your previous log about stop show (few post ago). Well , after event "done_recording" your backend continue to send "i am recording the old prog". This is crazy. I can build a workaround for that without force chain update when we haven't need. Then you could try it.


RE: New MythTV add-on using libcmyth - fetzerch - 2013-01-03

(2012-12-31, 23:35)tdavis Wrote:
(2012-12-12, 00:08)cfetzer Wrote:
(2012-12-11, 18:10)tdavis Wrote: Excellent, it compiled up and appeared to get the EDL list.. more testing to see how well it works.

Thanks for the feedback. I'm using this for quite a while now and it's working fine. At least the XBMC/Addon part. It depends of cause on the comskip quality. So if your breaks appear to early or to late it needs configuration/fixes on the MythTV side.

Ok, I've just tried to rebuild to RC2, and both PR's don't work, so it needs to be rebased.

Also found that when using VDPAU decoding under Nvidia, it runs fast; that's why my commercial skips under xbmc are too early.

Rebased both PRs so it should work again. When you're saying 'too early'. What does it mean? Seconds? Minutes?
The problem is that MythTV stores frame offsets, but XBMC needs time offsets and we convert them by multiplying the frame rate. If that is inaccurate it won't work properly.