Please use latest v17 builds. Isengard is fallen :-)
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, 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.
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)?
(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.
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, 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.
Github can release binary images? I build my jarvis-egl branch, which is OE master + fernet's kodi master.
Btw I only do this for easy testing of fernet's code. But as OE upstream does not care about users anymore I think to stop that... too much oe bug fiddeling.
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!
(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!
What really makes me wonder is, that it does not work at all for some and perfectly for others.
Please if there are regressions from one build to the other, provide log files. Especially the blamed 98 isengard version works flawless for some and not all for others.
I will rebuild in some minutes, when the train is not late :-)
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/
seems we are getting into special cases with certain hardware maybe? not sure what else it could really be but doesn't make a whole lot of sense as I don't think much really changed between your last few isnegard builds that would kill booting all together I would think.
I am happy in my v17 world though!
i can confirm, with asus chromebox, that all files are played correctly (dvd, divx,50/60 hz, mkv h264 /hevc and br iso and also mp3 and flac)
( i have only rarely handshake issue)
edit
peaking about jarvis build
(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/
Thanks much for this valuable feedback. I forwarded the issue to Fernet.
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!
At least we don't stall - but this does not help your audio outage a lot I think :-)
Could it be any reason why I cannot install/download/update any add on not present in any official repo? Anything in any unofficial repo could be viewed but not installed... Strange!
Rebuild images online.
Changelog:
- ffmpeg 2.8.2 with one new kodi patch to fix one HEVC UHD sample
- Fernet's master
Have fun testing.