• 1
  • 34
  • 35
  • 36(current)
  • 37
  • 38
  • 146
OpenELEC Testbuilds for RaspberryPi (Kodi 17.0)
(2016-01-09, 02:12)herrmeier01 Wrote: I will create debug logs of Yatse remote tomorow. Now my TV is in use and not avaiable for test :-)

Don't worry - I dug out a copy of Yatse and have reproduced the issue. On both RPi and RPi2 as well as x86, Yatse navigation isn't working in build #0108, but is working in #0107.

Kodi in #0108 is just not responding to any Yatse navigation keys - no response whatsoever, as if it isn't "seeing" them. The Home/Movies/TV buttons work, however. The volume mute button also works, but not volume up or volume down. I can reboot (and presumably use other power menu options) but that's about it.

If I revert the Joystick controller change, PR8807, then Yatse works again. Have left a comment on github.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2016-01-09, 02:30)herrmeier01 Wrote: Ok, I will create a new one with #0108. Do you recommend any additional component logging or is a simply debug log enough?

Regular debug log should be sufficient for audio/video issue.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
I have tried a number of builds and the build that started buffering for live tv is between build #1206 and #1207. I couldn't test out build #1206 because I couldn't get the hdhomerun or serverwmc to work. I think it is #1207 from the description that started the buffering. The current build #0108 If you enable omx live tv buffering is gone. Thank you for the workaround. If further testing is needed I am glad to assist.
Thanks you Milhouse for analysing the Yatse remote issue. I started Live-TV and waiting for video stutter for make the debug
Debug log of video stutter http://pastebin.com/raw/a9fED3an
I start debug log when the problem occurs to keep it small

By the way is there a command to start debbuging from linux shell?
Hi,

I have a problem with lirc, could it be same problem as in post 314?
Before I use an older release from November and there lirk is working.


Wohnzimmer:~ # vcdbg log msg 2>&1 | paste
http://sprunge.us/ebaR
Wohnzimmer:~ # cat /flash/config.txt | paste
http://sprunge.us/MEKa
Wohnzimmer:~ # dmesg | paste
http://sprunge.us/eIJG
Wohnzimmer:~ # md5sum /flash/overlays/lirc-rpi-overlay.dtb
0627b693153571f7f9031d8554aa9de0 /flash/overlays/lirc-rpi-overlay.dtb
(2016-01-09, 15:17)Heinz1971 Wrote: I have a problem with lirc, could it be same problem as in post 314?
Before I use an older release from November and there lirk is working.

I didn't see any errors in the logs. If you can find the first build here that fails that may identify the cause.
first of all: thanks a lot for the work in constant updating!

I was just wondering why airplay isn't working anymore. Is there any planned update?
On my apple devices I can select epenelec (kodi raspberry pi 2), but on Kodi nothing will happen.

Thx
(2016-01-09, 15:50)kakkabolle Wrote: I was just wondering why airplay isn't working anymore. Is there any planned update?
On my apple devices I can select epenelec (kodi raspberry pi 2), but on Kodi nothing will happen.

Is this specific to these test builds?
Have you read: http://forum.kodi.tv/showthread.php?tid=238523
(2016-01-09, 13:13)herrmeier01 Wrote: By the way is there a command to start debbuging from linux shell?

Code:
texturecache.py debugon
texturecache.py debugoff
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2016-01-09, 15:53)popcornmix Wrote:
(2016-01-09, 15:50)kakkabolle Wrote: I was just wondering why airplay isn't working anymore. Is there any planned update?
On my apple devices I can select epenelec (kodi raspberry pi 2), but on Kodi nothing will happen.

Is this specific to these test builds?
Have you read: http://forum.kodi.tv/showthread.php?tid=238523

THX! Now it's working Smile Yes I'm using the newest test build from the first page. I've already went through your posted thread. A new post helped now: turn the airplay video/photo support off.
Under options I couldn't find it, since I was under advanced settings and not expert settings...
(2016-01-09, 04:17)Milhouse Wrote: Don't worry - I dug out a copy of Yatse and have reproduced the issue. On both RPi and RPi2 as well as x86, Yatse navigation isn't working in build #0108, but is working in #0107.

Kodi in #0108 is just not responding to any Yatse navigation keys - no response whatsoever, as if it isn't "seeing" them. The Home/Movies/TV buttons work, however. The volume mute button also works, but not volume up or volume down. I can reboot (and presumably use other power menu options) but that's about it.

If I revert the Joystick controller change, PR8807, then Yatse works again. Have left a comment on github.

I came to the same situation with Yatse.

However I found playback of x265 videos stuttering. It started from build #0107, rolled back to build #0106 back to normal. There's no marcoblock, no artifacts, just stop after a few second, playback tried starting again for another few seconds and completely halt, both video and audio. While in that state, I can still transfer another build to the update directory and command a reboot using Yatse (both #0107 and #0108). I guess it was only the GPU hanged.

Is that any hope that 10-bit HEVC will be supported on RPi2 in future? Or it exceeded the capability of the processor?
(2016-01-09, 18:24)wchick132 Wrote: However I found playback of x265 videos stuttering. It started from build #0107, rolled back to build #0106 back to normal. There's no marcoblock, no artifacts, just stop after a few second, playback tried starting again for another few seconds and completely halt, both video and audio. While in that state, I can still transfer another build to the update directory and command a reboot using Yatse (both #0107 and #0108). I guess it was only the GPU hanged.

Is that any hope that 10-bit HEVC will be supported on RPi2 in future? Or it exceeded the capability of the processor?

Are H.265 videos stuttering or permanently stalling?
Not much happened with #0107 apart from some locking changes. There was a deadlock introduced but there was a fix in #0108.

So, are you certain #0107 introduced the problem and that it wasn't fixed in #0108?
I'm playing a H.265 now using #0108 without issue.

I think it's unlikely that 10-bit H.265 will be possible. Not for HD video.
(2016-01-09, 18:38)popcornmix Wrote: Are H.265 videos stuttering or permanently stalling?
Not much happened with #0107 apart from some locking changes. There was a deadlock introduced but there was a fix in #0108.

So, are you certain #0107 introduced the problem and that it wasn't fixed in #0108?
I'm playing a H.265 now using #0108 without issue.

I think it's unlikely that 10-bit H.265 will be possible. Not for HD video.

It stuttering for the first few seconds and after another few seconds, it just stalled permanenttly.

Yes, pretty sure build #0107 introduced the problem. I then rolled back to build #0106 and everything backs to normal.

I'll check build #0108 on another setup again, as Yatse wasn't working and on one setup that's my only way to control. Please noted that I watched x265 with subtitles (usually English in srt format). Remember we had problem before only when x265 video with subtitles?

How about 10-bit 720p? Is this still not possible?

Edit:
Just tested on another setup that use CEC and TV remote to control. Yeah, it's fixed. No stuttering and halt so far for the last couple of minutes that I tested.

Thanks.
(2016-01-09, 18:48)wchick132 Wrote: How about 10-bit 720p? Is this still not possible?

No. 10-bit is significantly harder than 8-bit.
  • 1
  • 34
  • 35
  • 36(current)
  • 37
  • 38
  • 146

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 17.0)6