I just gave janbar's latest changes to pvr.mythtv a shot in Gotham now. Until now, I hadn't even realized that there was a non-cmyth option for Gotham. The result is much of the same. This time, the stream wouldn't even start. Here is the
XBMC log.
Furthermore, I saw the following in the kernel log:
Code:
Jan 1 15:45:48 Kodi-Zbox kernel: [ 274.305304] perf samples too long (2516 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
I apologize if this question has already been answered:
Is it possible to build pvr.mythtv.
cmyth for Helix? I would like to try it out to see what happens, but I don't see it in either opdenkamp's or janbar's Helix branches.
(2015-01-01, 22:31)FeloniusMonkey Wrote: [ -> ]I just gave janbar's latest changes to pvr.mythtv a shot in Gotham now. Until now, I hadn't even realized that there was a non-cmyth option for Gotham. The result is much of the same. This time, the stream wouldn't even start. Here is the XBMC log.
Furthermore, I saw the following in the kernel log:
Code:
Jan 1 15:45:48 Kodi-Zbox kernel: [ 274.305304] perf samples too long (2516 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
I apologize if this question has already been answered:
Is it possible to build pvr.mythtv.cmyth for Helix? I would like to try it out to see what happens, but I don't see it in either opdenkamp's or janbar's Helix branches.
From the xbmc log
ERROR: AddOnLog: MythTV PVR Client: (CPPMyth)SpawnLiveTV: tune delay exceeded (5000ms)
This indicates that your live tv tuner is taking more than 5000ms to tune to the requested channel.
You can adjust this tune delay in the Advanced tab of the pvr.mythtv addon, max is 30 seconds - try this for now.
If that does not work please post a debug log.
You can safely ignore the entry in the kernel log, it is quite common.
Mike
(2015-01-01, 23:29)MikeB2013 Wrote: [ -> ]From the xbmc log
ERROR: AddOnLog: MythTV PVR Client: (CPPMyth)SpawnLiveTV: tune delay exceeded (5000ms)
This indicates that your live tv tuner is taking more than 5000ms to tune to the requested channel.
You can adjust this tune delay in the Advanced tab of the pvr.mythtv addon, max is 30 seconds - try this for now.
If that does not work please post a debug log.
Thanks Mike. This was meant as additional troubleshooting to the original report I made yesterday. I was only posting the debug log here as an FYI. The tune delay was also present when I tested pvr.mythtv in Helix. Increasing the tune delay would
sometimes work. However, the stream would still be badly pixelated, persistently buffer, and eventually fail. I didn't even bother increasing the delay in my Gotham test. I only wanted to assert that the issue was with the pvr.mythtv add-on, independent of Helix or Gotham. I also wanted to assert that janbar's latest changes unfortunately did not correct the issue.
What about building pvr.mythtv.cmyth for Helix? Anyone know if that's possible? I'd really like to be able to use Helix. Unfortunately, with pvr.mythtv as my only option, I can't afford to upgrade at this time. At least if I had a stable Helix cmyth build to revert to, I could
test janbar's changes more easily (without having to upgrade to Helix, and then revert back to Gotham each time).
(2015-01-01, 21:10)FeloniusMonkey Wrote: [ -> ]Just a quick question: janbar's repo is a fork of the notspiff repo, yet I haven't seen notspiff mentioned once in this entire thread. I'm curious what the functional differences are between the two. Is notspiff the official repo (since it doesn't appear to be a fork of anything itself)?
UPDATE: I just realized I was looking at a different repo. I was looking at pvr.mythtv, whereas all of these recent changes are actually going on in xbmc-pvr-addons. So what is the purpose of the pvr.mythtv repo? Is it obsolete?
HAPPY NEW YEAR, btw!
The repos "pvr.mythtv" is a new one to build the addon within environment of kodi-cmake from notspiff. For now the master repository still "xbmc-pvr-addons".
@
MikeB2013 , i am thinking a new solution to handle this mess. It is hard because here i haven't the issue ! driving me crazy.
Hi
I have the following problem(mpeg2 demux turned ON) - Whenever i initiate a channel switch to another channel through JSONRPC, it stays on the last frame on the previous channel and seems quite unresponsive. (
log here ) i can click the OSD(o button) on and off,
and thats about it. Cant stop stream, cant exit to main menu.
mpeg2 demux turned OFF, channel switching works, but the channel stops playing after a few seconds,
Log here
I tried adding and compiling with the "else usleep(10000);" - didn't do any difference. Not sure if its the same issue as Mike. Anyway drop me a line if you need some testing.
(2015-01-01, 12:44)emwebe Wrote: [ -> ] (2014-12-31, 23:35)nickr Wrote: [ -> ]One is .2, other is .20.
Just a typo in the post, the actual setting is .20 in all cases. I have corrected the last post.
Finally I solved the problem: after replacing the IPv6 address by ::1 the addon works for me.
Thank you to everybody who tried to help and to those developing and improving this addon!
@
MikeB2013
I made a new update in gotham and master branches, including new method to handle the issue. Please let me know what happen now.
EDIT: Probably you know how to reset last source update you have done. Else the git command is:
git reset --hard
(2015-01-02, 01:11)emwebe Wrote: [ -> ] (2015-01-01, 12:44)emwebe Wrote: [ -> ] (2014-12-31, 23:35)nickr Wrote: [ -> ]One is .2, other is .20.
Just a typo in the post, the actual setting is .20 in all cases. I have corrected the last post.
Finally I solved the problem: after replacing the IPv6 address by ::1 the addon works for me.
Thank you to everybody who tried to help and to those developing and improving this addon!
I know it is a mess
. If you set an IP6 address then backend prefers it instead IP4 and callback addon to use it to connect recorder. IP6 addresses are usable only if your network is configured for. Address like fe80:... is usable by host only. So let blank IP6 address (or ::1 as localhost)
(2015-01-02, 01:07)bjarque Wrote: [ -> ]Hi
I have the following problem(mpeg2 demux turned ON) - Whenever i initiate a channel switch to another channel through JSONRPC, it stays on the last frame on the previous channel and seems quite unresponsive. (log here ) i can click the OSD(o button) on and off,
and thats about it. Cant stop stream, cant exit to main menu.
mpeg2 demux turned OFF, channel switching works, but the channel stops playing after a few seconds, Log here
I tried adding and compiling with the "else usleep(10000);" - didn't do any difference. Not sure if its the same issue as Mike. Anyway drop me a line if you need some testing.
seems to be the same issue. I added a new patch including new method to handle it. You could try master branch for kodi or gotham branch for gotham.
Also kodi 14.0 is far to be perfect as you can see, and you find a new issue to address to xbmc team.
Since there are several issues going on here, would it make sense to break them out into separate threads? I'd be happy to summarize and repost the particular issue I've been involved in.
(2015-01-01, 17:55)janbar Wrote: [ -> ]@all , so thanks for posted samples !
I pushed a new release 1.11.0-helix and 1.9.22-30-gotham including a patch to resolve stuttering in some cases.
- Check my cloud for new releases:
https://www.canneasucre.org/owncloud/pub...4750925043
- Or from launchpad (janbar ppa) for ubuntu users.
I removed sleeping code on read ahead. It seems to be the guilty. Please let me know about then i will push the fix to xbmc team.
Happy new year !
The new 1.11 version seems to be working much better for me. After putting on the demux for mpeg2-ts, pixelation problems also stopped. I haven't really tested it much, but it at least can play live streams for more than a few seconds. I'll update as I get to test it out more over the weekend.
Thanks again for looking into this problem!
EDIT:
On my laptop, it seems to be working fine. However on the raspberry pi, the problem still exists. In addition, for some reason this problem seems to affect my SD channels more so than my HD channels.
(2015-01-02, 01:29)janbar Wrote: [ -> ]@MikeB2013
I made a new update in gotham and master branches, including new method to handle the issue. Please let me know what happen now.
EDIT: Probably you know how to reset last source update you have done. Else the git command is:
git reset --hard
@
janbar
Tried gotham branch, it plays fine without Demux enabled, (no pixellation) but does not survive program transition to the next program on the currently playing channel. Playing stops and drops back to main xbmc screen.
Log is here
http://paste.ubuntu.com/9658328/
Note: This was done on a test system running mythbackend 0.27 fixes with a single usb DVB-T tuner. xbmc running on a laptop connected using wifi.
EDIT: further testing shows that sometimes it survives program transition, sometimes not.
Mike
@
MikeB2013 @
Huuh
New releases 1.11.2 (helix) and 1.9.22-32 (gotham) should fix the transition issue. Let me know.
Really , the stuttering caused by reading ahead is strange. I cannot reproduce here but with your help we will close it definitively. Since xbmc frodo some guys have changed the behavior of live player. Now player breaks playback immediatly once received zero byte. By chance old cmyth addon handles sadly the mythtv buffer returning never 0. Since the new addon i made an effort to handle gracefully this stuff , but it was not counting changes of behavior from xbmc. Using internal demuxing, addon has its own buffer and it handles correctly the "no more bytes" retrying to read until timeout. Using xbmc demuxing you have no chance to read ahead because player stop playback immediatly. This behavior is stupid for live playback !
So now seems we found the root cause, and probably 1.11.2 and 1.9.22-32 fix it.
Since switching to this addon for live tv I have noticed a few times that my EPG will be empty in spots. I am using OTA info for my EPG but never experienced this before. Is there a way to refresh the EPG without restarting kodi and/or is there a fix for this?
(2015-01-02, 13:45)janbar Wrote: [ -> ]@MikeB2013 @Huuh
New releases 1.11.2 (helix) and 1.9.22-32 (gotham) should fix the transition issue. Let me know.
Really , the stuttering caused by reading ahead is strange. I cannot reproduce here but with your help we will close it definitively. Since xbmc frodo some guys have changed the behavior of live player. Now player breaks playback immediatly once received zero byte. By chance old cmyth addon handles sadly the mythtv buffer returning never 0. Since the new addon i made an effort to handle gracefully this stuff , but it was not counting changes of behavior from xbmc. Using internal demuxing, addon has its own buffer and it handles correctly the "no more bytes" retrying to read until timeout. Using xbmc demuxing you have no chance to read ahead because player stop playback immediatly. This behavior is stupid for live playback !
So now seems we found the root cause, and probably 1.11.2 and 1.9.22-32 fix it.
@
janbar
Looking good.
Tested 1.11.2 on Helix using my main mythtv server (0.28pre).
Successfully running 3 frontends (Windows 7, Mythbuntu 64Bit, Raspbmc) at the same time over wifi watching HD or SD with no issues including transition of programs.
Demux of MPEG-TS is not enabled, previously I had pixellation and drop out to main kodi screen, which enabling Demux solved.
Streams tested DVB-T/T2, DVB-S/S2 no issues with any stream HD or SD with or without Demux enabled.
Mike
(2015-01-02, 13:45)janbar Wrote: [ -> ]@MikeB2013 @Huuh
New releases 1.11.2 (helix) and 1.9.22-32 (gotham) should fix the transition issue. Let me know.
Really , the stuttering caused by reading ahead is strange. I cannot reproduce here but with your help we will close it definitively. Since xbmc frodo some guys have changed the behavior of live player. Now player breaks playback immediatly once received zero byte. By chance old cmyth addon handles sadly the mythtv buffer returning never 0. Since the new addon i made an effort to handle gracefully this stuff , but it was not counting changes of behavior from xbmc. Using internal demuxing, addon has its own buffer and it handles correctly the "no more bytes" retrying to read until timeout. Using xbmc demuxing you have no chance to read ahead because player stop playback immediatly. This behavior is stupid for live playback !
So now seems we found the root cause, and probably 1.11.2 and 1.9.22-32 fix it.
this probably also explains why playback returns to the menu when you are flipping channels and you hit the channel that isn't coming in.