(2013-02-20, 21:35)richardk Wrote: I was hoping that some other folks who've experienced the slowdowns could also test this, but that doesn't seem to be happening.

(2013-02-20, 22:22)cfetzer Wrote: Thanks a lot for that clarification. I had to ask, just to make sure under all circumstances that we won't end up fixing something at the wrong end.
And if you see improvements, we probably have found the wrongly behaving component already.

1-2. It's good to know, that the addon causes in general a bit higher cpu load on the backend. Think might be related to several things and is most likely really difficult to solve. It could be due to different buffer sizes, different usage of the mythtv protocol, timings, ...
I agree, it's an issue, but low prio for now.

3. Ok then janbar's last patch optimized things in our image cacheing component and indeed seems to have an influence on the increased load.

Could you check if you see MythSocket errors in the backend log? If so, it might help if you could enable debug logging in the addon and post logs of both, backend and xbmc, for the timeranges where you see the socket errors.

(2013-02-20, 23:52)MvonSchantz Wrote:

(2013-02-20, 21:35)richardk Wrote: I was hoping that some other folks who've experienced the slowdowns could also test this, but that doesn't seem to be happening.

Sorry for being late to the show! I didn't notice until today, that I was having exactly the same problem. I had been running my backend for a couple of weeks without restarting it, and suddenly today, my recordings were stuttering like crazy when I tried to watch them. Looking at my cpu usage for the backend, it was howering between 85% and 99%. Since I only do SD recordings from an analog source, I guess I could run with excessive cpu usuage for quite some time until there just wasn't enough resources left for playback.

I've now compiled and installed the debug-backend-cpu branch and restarted my backend. Just installing the debug-backend-cpu plugin and restarting XBMC didn't do anything good, but restarting the backend lowered the cpu usage to between 0% and 1%. Now, the real question is, will it stay there?

(2012-10-04, 01:45)markcs Wrote:

(2012-10-03, 17:30)cfetzer Wrote: "Client speaks protocol version 8 but we speak 72" should not cause any problems and is in libcmyth from the beginning. libcmyth tries to connect with different versions until it gets an OK from the server. Not nice, and maybe something to be redone at some point.

@markcs: Aubrien is right, your xbmc version must contain this commit: https://github.com/xbmc/xbmc/commit/465c6927594b239e8ae22687d5962669c849e72c
A current nightly or freshly built version should do it.

Thanks for your replies.
- I did a git pull on both xbmc and the xbmc-pvr-addons (from fetzerch's repository) but both were up to date.
- I deleted the db files in userdate/Database directory.
- I thought my problem may be due to an 'old' install of xbmc that was from the ppa repository for ubuntu. I removed all traces I could find of xbmc under /usr/local/share/xbmc and /usr/share/xbmc
- I reinstalled.

I can enable the addon, but when I try to go into any of the Live TV menu's, i'm told the addon has not started.

...clip...

Thanks!

(2013-02-23, 15:33)richardk Wrote:

(2013-02-20, 23:52)MvonSchantz Wrote:

(2013-02-20, 21:35)richardk Wrote: I was hoping that some other folks who've experienced the slowdowns could also test this, but that doesn't seem to be happening.

Sorry for being late to the show! I didn't notice until today, that I was having exactly the same problem. I had been running my backend for a couple of weeks without restarting it, and suddenly today, my recordings were stuttering like crazy when I tried to watch them. Looking at my cpu usage for the backend, it was howering between 85% and 99%. Since I only do SD recordings from an analog source, I guess I could run with excessive cpu usuage for quite some time until there just wasn't enough resources left for playback.

I've now compiled and installed the debug-backend-cpu branch and restarted my backend. Just installing the debug-backend-cpu plugin and restarting XBMC didn't do anything good, but restarting the backend lowered the cpu usage to between 0% and 1%. Now, the real question is, will it stay there?

Any results to report after several days?

My backend has now been up for almost ten days. I'm seeing divergent mythbackend cpu load numbers depending on the recording being played, and quite a bit of variation during the playing of a single recording. For some recordings, it's 15% -20%, for others it's 30% to slightly over 40%. (I'm running the latest compiled version from "master".)

While this is much higher than immediately after a boot, it's not high enough to cause problems. And it doesn't seem to be increasing dramatically anymore.

So the current version of the addon will probably work fine for everyone except those with a really old and slow backend system.

Unfortunately, version 1.6.8 did not make it into OpenELEC 2.99.3 (RC3). It still shows 1.6.7. It would be really unfortunate if it doesn't get into the final release, since it's been improved so much.

I'm thinking of rebooting my backend and watching what happens when it's touched only by the latest addon code. Before I do that, cfetzer, is there anything else you'd like me to test with a backend that's been up for a while?

(2013-02-23, 19:34)st2000 Wrote:

(2012-10-04, 01:45)markcs Wrote:

(2012-10-03, 17:30)cfetzer Wrote: "Client speaks protocol version 8 but we speak 72" should not cause any problems and is in libcmyth from the beginning. libcmyth tries to connect with different versions until it gets an OK from the server. Not nice, and maybe something to be redone at some point.

@markcs: Aubrien is right, your xbmc version must contain this commit: https://github.com/xbmc/xbmc/commit/465c6927594b239e8ae22687d5962669c849e72c
A current nightly or freshly built version should do it.

Thanks for your replies.
- I did a git pull on both xbmc and the xbmc-pvr-addons (from fetzerch's repository) but both were up to date.
- I deleted the db files in userdate/Database directory.
- I thought my problem may be due to an 'old' install of xbmc that was from the ppa repository for ubuntu. I removed all traces I could find of xbmc under /usr/local/share/xbmc and /usr/share/xbmc
- I reinstalled.

I can enable the addon, but when I try to go into any of the Live TV menu's, i'm told the addon has not started.

...clip...

Thanks!

Has this been resolved?:

"Client speaks protocol version 8 but we speak 7*"

I am having the problem too.

My client is mythbox running as an addon to raspbmc which I just created yesterday (i.e. fresh download of all files) on 2013.02.22. My mythback end is running version .26.

-thanks

version information:
raspbmc-rls-1.0-hardfp-b20130208-u20130208
MythTV Version : v0.26.0 Network Protocol : 75

(2013-02-24, 18:43)cfetzer Wrote: Sorry for the late response. I checked your log, but that socket error should be fine. We need to know the backend version and mythbackend prints this error when we try to get it. Should be harmless. Do you see any of those errors? "writeStringList: Error, No data written on writeBlock)"?

I still believe that there's something wrong in how we setup/use the socket connections to the backend. But it's very difficult and time consuming to debug.

Sure just reboot the backend. I'd be interested as well what happens if you only run the latest addon code. I really hope you are right and the current version works for most of the people.

(2013-02-24, 19:53)richardk Wrote:

(2013-02-24, 18:43)cfetzer Wrote: Sorry for the late response. I checked your log, but that socket error should be fine. We need to know the backend version and mythbackend prints this error when we try to get it. Should be harmless. Do you see any of those errors? "writeStringList: Error, No data written on writeBlock)"?

I still believe that there's something wrong in how we setup/use the socket connections to the backend. But it's very difficult and time consuming to debug.

Sure just reboot the backend. I'd be interested as well what happens if you only run the latest addon code. I really hope you are right and the current version works for most of the people.

I did find a couple of those errors, but only a couple:

Code:

richard@MythTV:/var/log/mythtv$ grep writeStringList mythbackend.log
Feb 20 18:36:50 MythTV mythlogserver: mythbackend[2088]: E ProcessRequest mythsocket.cpp:375 (writeStringList) MythSocket(9c0ba50:78): writeStringList: Error, No data written on writeBlock (925 errors)#012#011#011#011starts with: 245432  0[]:[]458[]:[]Leverage[]:[][]:[][]:[]0[]:[]0[]:[][]:...
Feb 20 21:00:28 MythTV mythlogserver: mythbackend[2088]: E CoreContext mythsocket.cpp:344 (writeStringList) MythSocket(9ee4bc8:-1): writeStringList: Error, socket went unconnected.#012#011#011#011We wrote 0 of 692 bytes with 1 errors#012#011#011#011starts with: 684     BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE UPDATE[]:[...

After 10 days of uptime, I'm still seeing the mythbackend cpu load increase gradually. Playing some recordings is now taking 60% - 70% cpu. So there is still a problem, and I'm guessing that it would eventually result in stuttering or buffering. But it would now take a while (weeks?) to get to that point. It may be that most users restart their systems before that.

The current version of the addon is a huge improvement, so I do hope it gets out to users soon!

(2013-02-19, 20:53)richardk Wrote:

(2013-02-19, 20:06)sfrooster Wrote: I don't know what you're running for a backend (mine is only a Zotac MAG), but I'm at the point of a daily reboot. The need *may* be exacerbated by some network latency (one xbmc node is across a 100 ft cable run serviced by a cable/ethernet bridge) - once the CPU usage creeps up a little, I start to see excessive buffering on the remote node. The less remote node (which is harware identical to the other) is less... fragile.

I'm running MythTV on an older system based on an Athlon 64X2 5000 cpu, with 2GB of memory. It's connected to my XBMC frontend across a wired gigabit Ethernet connection.

With the latest versions of the addon, I haven't needed daily reboots, but something is making the mythbackend cpu load incrase slowly.

I'm going to try to avoid rebooting, and see if the load keeps increasing and (if so) how much.

(2013-02-26, 05:16)Bpoppe Wrote: Hey all. I just got a Raspberry Pi on Saturday and already have it up and running, connected to my Mythbox. I'm running Myth 0.26 on my back end and Raspbmc as the distro for the RBPi. Im using the MythTv PVR add-on. The only question I have is how do I enable comm skipping on XBMC? I read through a few pages of this thread and couldn't seem to find anything.

Thanks in advance for any help you can provide.

(2013-02-26, 05:16)Bpoppe Wrote: Hey all. I just got a Raspberry Pi on Saturday and already have it up and running, connected to my Mythbox. I'm running Myth 0.26 on my back end and Raspbmc as the distro for the RBPi. Im using the MythTv PVR add-on. The only question I have is how do I enable comm skipping on XBMC? I read through a few pages of this thread and couldn't seem to find anything.

Thanks in advance for any help you can provide.

(2013-02-26, 15:23)st2000 Wrote:

(2013-02-26, 05:16)Bpoppe Wrote: ...Im using the MythTv PVR add-on...

How did you get that to work (watching myth 0.26 recordings on Raspbmc/mythbox)?

I built my raspbmc / mythbox Raspberry Pi 4 days ago using a fresh store bought SDCard and found that it only supported up to mythtv protocol 70. Let me know if I am wrong, but I think that is older then can possibly work for any mythbackend 0.26 release. So I pulled the latest mythbox from the mythbox GIT repository. That version supports up to myth protocol 74. Sadly, my 0.26 mythbackend is already using myth protocol 75. I added some to code to mythbox to see if I could fake out the mythbackend, but it does not appear to work.
...

(2013-02-26, 22:54)pgjensen Wrote: I saw in the latest changelog for v1.6.9 through GIT "Fixed recovering from backend connection loss on Windows."

I compiled this version and put it on all of my stations, but noticed just last night that when the computer was asleep overnight and I came back to LIVE TV, it just sat there spinning and every 30s or so it'd show a red error that the backend connection was lost. It loops for 2-3 minutes and then just stops. Was the change above for a different problem?