2015-11-15, 12:11
Please use latest v17 builds. Isengard is fallen :-)
(2015-11-15, 12:20)pikachu320 Wrote: Ok, will try again and come back to you. A few of the changes I mentionned could still be useful for future images.
(2015-11-15, 13:36)D-an-W Wrote: I know this is a dumb question and I apologise in advance but are the v17 builds you refer to Jarvis which is listed as v16 on the blog etc (I use a shared database so need the same version on all my hardware for it to fully work)?For now v16 based. But the code will land in v17 first and won't make it into v16 final.
(2015-11-15, 12:52)fritsch Wrote:(2015-11-15, 12:20)pikachu320 Wrote: Ok, will try again and come back to you. A few of the changes I mentionned could still be useful for future images.
Will have a look. Currently travelling and very busy.
(2015-11-15, 14:30)pikachu320 Wrote:(2015-11-15, 12:52)fritsch Wrote:(2015-11-15, 12:20)pikachu320 Wrote: Ok, will try again and come back to you. A few of the changes I mentionned could still be useful for future images.
Will have a look. Currently travelling and very busy.
Don't worry, I have no SLA with you on this :p
At first sight, it seems that my random crash problem have been solved with your OpenELEC-Generic.x86_64-6.0-devel-20151110195330-r21567-g685e6e7 build. I'll continue testing and see if something happens.
Please note that the latest build (OpenELEC-Generic.x86_64-6.0-devel-20151113133714-r21569-g59302ad.img.gz) was problematic for me for another thing: I had NMI lockups of CPU#0 during install. The other build available on your website isn't problematic. Unappropriate changes in kernel for some hardware?
I also wonder why you publish the builds there, instead of using github (and its release system?). It would be nicer to have a view of how you built this img, this way we can see the changelog and pinpoint what was better or worse, and improve the process by having PR for example.
(2015-11-15, 18:04)jjslegacy Wrote: You are making me think I should move away from OE. I suppose there is no real reason I use it but it certainly is convenient.
Side note a other nice evening of using the latest build from the 13th. Working flawlessly and feels very refined and smooth.
Appreciate all the hard work guys!
cat kodi.log | pastebinit
http://paste.ubuntu.com/13286040/
cat /var/log/Xorg.0.log | pastebinit
http://paste.ubuntu.com/13285266/
dmesg | pastebinit
http://paste.ubuntu.com/13285268/
DISPLAY=:0 vainfo | pastebinit
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
http://paste.ubuntu.com/13285270/
id | pastebinit
http://paste.ubuntu.com/13285271/
aplay -L | pastebinit
http://paste.ubuntu.com/13285272/
(2015-11-15, 19:26)Jorgensen Wrote: I am currently experiencing problems with my DTS-HD MA videos. I am seeing a lot of skipped frames, both visually and from the OSD info. Previously, with the old VAAPI implementation I had no issues with these videos.
If I restart the movie, the skipped frames occurs at different times in the movie. Sometimes the skipped frames occurs every 10-20 seconds, other times there are several minutes between the skipped frames. If I disable "DTS-HD MA capable receiver", I don't see any skipped frames. Videos with Dolby True HD sound works fine. My NUC is connected to my receiver via a HDMI cable.
In the log files, I start the same movie 3 times. The second time I started the movie, the skipping was the worst.
Code:cat kodi.log | pastebinit
http://paste.ubuntu.com/13286040/Code:cat /var/log/Xorg.0.log | pastebinit
http://paste.ubuntu.com/13285266/Code:dmesg | pastebinit
http://paste.ubuntu.com/13285268/Code:DISPLAY=:0 vainfo | pastebinit
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
http://paste.ubuntu.com/13285270/Code:id | pastebinit
http://paste.ubuntu.com/13285271/Code:aplay -L | pastebinit
http://paste.ubuntu.com/13285272/
Quote:17:50:09 T:140021016811264 WARNING: VAAPI::FFGetBuffer - no surface available - dec: 0, render: 0
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] thread_get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] decode_slice_header error
17:50:09 T:140021016811264 WARNING: VAAPI::FFGetBuffer - no surface available - dec: 0, render: 0
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] thread_get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] decode_slice_header error
17:50:09 T:140021016811264 WARNING: VAAPI::FFGetBuffer - no surface available - dec: 0, render: 0
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] thread_get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] decode_slice_header error
17:50:09 T:140021016811264 WARNING: VAAPI::FFGetBuffer - no surface available - dec: 0, render: 0
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] thread_get_buffer() failed
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] decode_slice_header error
17:50:09 T:140021016811264 ERROR: ffmpeg[7F592EF7D700]: [h264] no frame!