(2013-02-17, 04:49)sfrooster Wrote: Scratch that. The stuttering came back with Live Tv. Backend cup was higher too. So I dropped back to my previous version and things are better.

(2013-02-17, 15:21)cfetzer Wrote:

(2013-02-17, 13:12)simora Wrote: Are there config or make options to only build the myth addon from your repo so make install only installs the myth addon or atleast so I don't have to build all the other addons? Then I could stick your repo in and opdenkamp's and get the best of everything.

That again depends on the build system, maybe it's better to ask in the xbmc irc channel or in the linux specific help section of the forum.
Maybe something like "make -C lib/cmyth && make -C addons/pvr.mythtv.cmyth" works for you.

But are you using different pvr addons? If not, then you can just use our repository.
In addition we try to release fixes and new features more often now, so that using opdenkamps git repo might be fine for you as well.

(2013-02-17, 18:07)cfetzer Wrote: Thanks. I've reverted the buffer change for now.

(2013-02-17, 18:33)simora Wrote: EDL is in your 1.6.8+ releases correct? Its just XBMC that needs the PR correct?

(2013-02-18, 20:08)cfetzer Wrote: Commercial skip depends on two changes:
- XBMC: https://github.com/xbmc/xbmc/pull/1743
- Addon: https://github.com/opdenkamp/xbmc-pvr-addons/pull/173

This first version will work with recordings that do not have changing refresh rates.
Not sure if this generalization is correct, but so far I haven't seen this in DVB streams,
but it seems to be the case for some (maybe all) ATSC streams.

This is caused by a general difference how mythtv handles timestamps (frame offsets) where xbmc needs time offsets.
Myth TV 0.27 will add a feature that will allow us to convert those values properly.

(2013-02-17, 21:49)richardk Wrote:

(2013-02-17, 18:07)cfetzer Wrote: Thanks. I've reverted the buffer change for now.

I built the new version, and I can confirm that it resolves the problem with Live TV. Mythbackend cpu usage is now comparable to that when playing a recording.

(2013-02-19, 15:49)richardk Wrote: My MythTV backend has been up for 5 1/2 days now, and the mythtbacked cpu load when playing a recording is edging back up.

I'm seeing 21% - 23% load when playing a HD recording. I fired up the MythTV frontend, and played the same recording. Using mythfrontend on the same configuration and playing the same recording, the mythbackend cpu load runs 10% - 12% -- about half of that when using XBMC.

So, XBMC always seems to cause the mythbackend to double.

And something is causing the mythbackend load to increase over time for both players. (The increases seem, though, to be less severe and more gradual than with the old version of the plugin that's now in distribution. At this point, it's not enough to cause any buffering or stuttering. So it wouldn't be noticed by anyone not monitoring the cpu load on the backend.)

Is it the images in the cmyth plugin? Or some other aspect of the plugin? Or something inherent in the MythTV backend, and unrelated to XBMC? At this point, I don't know. And since the phenomenon takes days to show up clearly, it's not the easiest thing to test.

(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.

(2013-02-19, 06:03)sfrooster Wrote:

(2013-02-18, 20:08)cfetzer Wrote: Commercial skip depends on two changes:
- XBMC: https://github.com/xbmc/xbmc/pull/1743
- Addon: https://github.com/opdenkamp/xbmc-pvr-addons/pull/173

This first version will work with recordings that do not have changing refresh rates.
Not sure if this generalization is correct, but so far I haven't seen this in DVB streams,
but it seems to be the case for some (maybe all) ATSC streams.

This is caused by a general difference how mythtv handles timestamps (frame offsets) where xbmc needs time offsets.
Myth TV 0.27 will add a feature that will allow us to convert those values properly.

Ok, good to know. To clarify, ATSC streams (like those I'd tune with an HDHR Prime) will work with this first version, or will not?

On another point - I built the addon last night, and I'm noticing that after sometime I need to bounce myth-backend or else live tv will stutter with buffering. htop on the backend will confirm that the CPU is running under slightly more load than it does right after the bounce (at which point the stuttering also disappears).

To be fair, this issue may have existed in earlier versions.

Are others seeing this? Is there a fix / workaround?

(2013-02-19, 15:49)richardk Wrote:

(2013-02-17, 21:49)richardk Wrote:

(2013-02-17, 18:07)cfetzer Wrote: Thanks. I've reverted the buffer change for now.

I built the new version, and I can confirm that it resolves the problem with Live TV. Mythbackend cpu usage is now comparable to that when playing a recording.

My MythTV backend has been up for 5 1/2 days now, and the mythtbacked cpu load when playing a recording is edging back up.

I'm seeing 21% - 23% load when playing a HD recording. I fired up the MythTV frontend, and played the same recording. Using mythfrontend on the same configuration and playing the same recording, the mythbackend cpu load runs 10% - 12% -- about half of that when using XBMC.

So, XBMC always seems to cause the mythbackend to double.

And something is causing the mythbackend load to increase over time for both players. (The increases seem, though, to be less severe and more gradual than with the old version of the plugin that's now in distribution. At this point, it's not enough to cause any buffering or stuttering. So it wouldn't be noticed by anyone not monitoring the cpu load on the backend.)

Is it the images in the cmyth plugin? Or some other aspect of the plugin? Or something inherent in the MythTV backend, and unrelated to XBMC? At this point, I don't know. And since the phenomenon takes days to show up clearly, it's not the easiest thing to test.

(2013-02-20, 08:07)tdavis Wrote:

(2013-02-19, 06:03)sfrooster Wrote:

(2013-02-18, 20:08)cfetzer Wrote: Commercial skip depends on two changes:
- XBMC: https://github.com/xbmc/xbmc/pull/1743
- Addon: https://github.com/opdenkamp/xbmc-pvr-addons/pull/173

This first version will work with recordings that do not have changing refresh rates.
Not sure if this generalization is correct, but so far I haven't seen this in DVB streams,
but it seems to be the case for some (maybe all) ATSC streams.

This is caused by a general difference how mythtv handles timestamps (frame offsets) where xbmc needs time offsets.
Myth TV 0.27 will add a feature that will allow us to convert those values properly.

Ok, good to know. To clarify, ATSC streams (like those I'd tune with an HDHR Prime) will work with this first version, or will not?

On another point - I built the addon last night, and I'm noticing that after sometime I need to bounce myth-backend or else live tv will stutter with buffering. htop on the backend will confirm that the CPU is running under slightly more load than it does right after the bounce (at which point the stuttering also disappears).

To be fair, this issue may have existed in earlier versions.

Are others seeing this? Is there a fix / workaround?

My experience with Comcast & HDR Prime - no go.
OTA/ATSC via a HDHomerun dual - worked great!.

Comcast appears to be re-encoding the streams (of course!) to fit better into the cable system. You can possibly re-encode to get rid of the variable frame rate, but then you would also need to reset the commercial breaks on the re-encoded file.

MythTV 0.26 works fine because they generate some extra frame information into the db that is used for playback (pre-computed skip/frame counts, from the looks of it)

(2013-02-20, 21:06)cfetzer Wrote: Did I get this right?: When using "debug-backend-cpu" it still increases cpu load after a while, but it takes (much?) longer?
Or is it fixed now when you use that branch?