(2012-10-07, 14:59)janbar Wrote: @Aubrien,

Good log. I am investigating...

(2012-10-07, 02:23)Aubrien Wrote: Janbar,
i couldn't get pastebin to take the log as it was loo large. Its quite alot of info for 5 mins of logging, but I know you need it to troubleshoot my issue. I used the email feature in the forum to send an email with the log and it says it sent successfully. Let me know if you get it or not. Thanks!

Here are some interesting things though...

Code:

19:54:45 T:2644073280   DEBUG: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: switch file: current=0 , dir=0
19:55:01 T:2644073280   DEBUG: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: switch file: current=0 , dir=1
19:55:03 T:2644073280   DEBUG: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: switch file: current=1 , dir=0
19:55:03 T:2644073280   DEBUG: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: switch file: current=1 , dir=0
20:00:06 T:2644073280   DEBUG: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: switch file: current=1 , dir=1
20:00:07 T:2644073280   DEBUG: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: switch file: current=2 , dir=1

Started at 19:54:45. 15s channel switch delay. 19:55:01 channel is changed. Next show is at 20:00:00.

This repeats for a while...

Code:

20:00:07 T:2644073280   ERROR: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: no more file
20:00:07 T:2644073280   ERROR: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: no more file
20:00:07 T:2644073280   ERROR: AddOnLog: PVR MythTV Client (cmyth): LibCMyth: (cmyth)cmyth_livetv_chain_switch: no more file

"wait until recorder is ready for watching" is never posted in the log so it is like the delay loop from below is never triggered. I changed i=20.

cmyth_livetv_chain_switch

Code:

for ( i = 0; i < 20; i++ ) {
                                pthread_mutex_unlock(&mutex);
                                usleep(500000);
                                pthread_mutex_lock(&mutex);
                                if ( rec->rec_livetv_chain->livetv_watch == 1 )
                                        break;
                        }

I think what is happening is it is setting the watch flag right away but there is a period of a few seconds where the hardware becomes ready and then begins to record while the file remains 0 size. Basically the backend says go and the hardware takes a few seconds. The same is true for the channel changes except it is more like 7s instead of 3s because it has to IR blast before the little blue light on the recorder comes on. If it were to wait until the file had a non 0 size AND the watch flag was ready then it may solve both the channel change delay and this issue in one swoop. You probably wouldn't need the watch flag at all really if you just checked the file size. I was playing around with the LiveTVDuration property and if it were 0 i wouldn't let it play or if it stopped increasing and then began increasing again then it was done with the program break. That might be a cheesy way of doing it though but it worked.

Hopefully you get my full log, but maybe the above will help too.

(2012-10-07, 15:48)cfetzer Wrote:

(2012-10-07, 14:59)janbar Wrote: @Aubrien,

Good log. I am investigating...

@janbar: Did you have a closer look at the mythtv/mythfrontend sources and how they handle the chain updates and those 2 related events? The mythtv sources helped me a lot when implementing the multiplex detection. Both libcmyth and the myth protocol docs lack docs very often but mythtv's code itself is pretty readable.
I'm almost done with the fileops rework. If you and aubrian have a proper fix for the 'show stopping' and the 'delayed start', I can help integrating those changes into my repo.

(2012-10-07, 20:02)janbar Wrote:

(2012-10-07, 15:48)cfetzer Wrote:

(2012-10-07, 14:59)janbar Wrote: @Aubrien,

Good log. I am investigating...

@janbar: Did you have a closer look at the mythtv/mythfrontend sources and how they handle the chain updates and those 2 related events? The mythtv sources helped me a lot when implementing the multiplex detection. Both libcmyth and the myth protocol docs lack docs very often but mythtv's code itself is pretty readable.
I'm almost done with the fileops rework. If you and aubrian have a proper fix for the 'show stopping' and the 'delayed start', I can help integrating those changes into my repo.

@cfetzer
Yes had a look and to resolve it i added event LIVETV_WATCH to manage the program break. Now it is closed and i am preparing to merge with you. Aubrien has a special context needing a delay to refill buffer after each stage: spawn tv, switch channel and program break. At the moment libcmyth or xbmc player does not manage any delay before retry. So retries to read live stream loop without delay and after 150 retries in a short time the player close live stream. I try to find a global solution with him to manage this case without adding unnecessary waiting time. I think it is possible and it will be an improvement for the addon.
Soon i will pull request to you. This merge it is an hard work and i don't want to break anything. br

Also i will making more than one pull request to simplify the merge. My updated cmyth is fully compatible even without program break management.

(2012-10-07, 20:23)cfetzer Wrote:

(2012-10-07, 20:02)janbar Wrote:

(2012-10-07, 15:48)cfetzer Wrote: @janbar: Did you have a closer look at the mythtv/mythfrontend sources and how they handle the chain updates and those 2 related events? The mythtv sources helped me a lot when implementing the multiplex detection. Both libcmyth and the myth protocol docs lack docs very often but mythtv's code itself is pretty readable.
I'm almost done with the fileops rework. If you and aubrian have a proper fix for the 'show stopping' and the 'delayed start', I can help integrating those changes into my repo.

@cfetzer
Yes had a look and to resolve it i added event LIVETV_WATCH to manage the program break. Now it is closed and i am preparing to merge with you. Aubrien has a special context needing a delay to refill buffer after each stage: spawn tv, switch channel and program break. At the moment libcmyth or xbmc player does not manage any delay before retry. So retries to read live stream loop without delay and after 150 retries in a short time the player close live stream. I try to find a global solution with him to manage this case without adding unnecessary waiting time. I think it is possible and it will be an improvement for the addon.
Soon i will pull request to you. This merge it is an hard work and i don't want to break anything. br

Also i will making more than one pull request to simplify the merge. My updated cmyth is fully compatible even without program break management.

Great I'm done now with the cleanups.
FileOps uses now XBMC's internal file system access methods and no more boost::filesystem and I also fixed the bug that images for new recordings were only present after a xbmc restart.
Also the translations are now done via Transifex ( https://www.transifex.com/projects/p/pvrmythtvcmyth ). Anyone is welcome to contribute translations!

@janbar: Yes, please add either different commits to a single PR or create multiple PRs. Please split / combine them by topics and please split all cmyth related commits (so they can be merged to libcmyth upstream at some time). Currently I have all cmyth related commits prefixed with [cmyth] and all plugin related commits with [mythtv-cmyth].
Then it would be great if you could either comment your changes quite verbose (either in the source files or in the PRs). That helps to understand all the details.
And just let me know if you need any help with the merge!