[Milhouse]

I thought it had something to do with the pre-loading of artwork into the texture cache, and maybe it still does (though no reason why it should), but I can reliably crash the Pi simply by going into TV Shows, bringing up the Info panel for a particular TV show (Arrow, also The Big Bang Theory) and then clicking on "Choose Art" - after that I need to power cycle the Pi.

Here is the debug log after clicking on the "Choose Art" button, there is no more info after this as the Pi has crashed (there is nothing written to /var/log/messages either):

Code:

02:57:10 T:3042988032   DEBUG: LIRC: Update - NEW at 187117:160 0 KEY_OK devinput (KEY_OK)
02:57:10 T:3042988032   DEBUG: OnKey: 11 (0b) pressed, action is Select
02:57:10 T:3042988032   DEBUG: ------ Window Init (DialogSelect.xml) ------
02:57:10 T:3042988032    INFO: Loading skin file: DialogSelect.xml, load type: KEEP_IN_MEMORY
02:57:10 T:3042988032   DEBUG: LIRC: Update - NEW at 187225:160 0 KEY_OK_UP devinput (KEY_OK_UP)
02:57:10 T:3042988032   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.image_decode handle 0x03bd5610 dllopen : 1
02:57:10 T:3042988032   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.image_decode input port 320 output port 321
02:57:10 T:3042988032   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.resize handle 0x039c6290 dllopen : 1
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.resize input port 60 output port 61
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.image_decode) - port(320), nBufferCountMin(2), nBufferCountActual(3), nBufferSize(81920), nBufferAlignmen(16)
02:57:11 T:2980050016   ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.image_decode - OMX_ErrorStreamCorrupt, Bitstream corrupt
02:57:11 T:3042988032   ERROR: COMXImage::Decode HandlePortSettingChange() failed
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.resize handle 0x039c6290 dllopen : 1
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.image_decode handle 0x03bd5610 dllopen : 1
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.image_decode handle 0x03bd5668 dllopen : 1
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.image_decode input port 320 output port 321
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.resize handle 0x031e3518 dllopen : 1
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.resize input port 60 output port 61
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.image_decode) - port(320), nBufferCountMin(2), nBufferCountActual(3), nBufferSize(81920), nBufferAlignmen(16)
02:57:11 T:3042988032   DEBUG: COMXCoreComponent::AllocOutputBuffers component(OMX.broadcom.resize) - port(61), nBufferCountMin(1), nBufferCountActual(1), nBufferSize(1428480) nBufferAlignmen(16)

Now, even if an image file is corrupt (and for the "Arrow" TV show, the poster, banner and fanart all display when browsing in the library, but now that I look at it more closely, the banner image is showing some glitches that I can also see in Windows Photo Viewer when opening the banner file stored in Thumbnails), a dodgy jpg shouldn't be enough to crash the machine...

If anyone is willing, I've uploaded the original and Pi converted files - perhaps by overwriting existing files of another show in your Thumbnails folder it will be possible to reproduce the crash?

I've tested the latest Git build of OpenELEC, and also Rbej builds - both show the same problem.

[Jester]

I've seen this before, some months ago, there is a trac ticket for it and a fix OMX resize issue when the resolution was either odd or even (can't remember)

I'll try and find it back as it sounds like this.

EDIT:
Have a look here
http://trac.xbmc.org/ticket/13434

[Jester]

On second thought, the issue I mentioned above was on ATV2
http://forum.xbmc.org/showthread.php?tid=136153

However, it seems to be an OMX issue on banner resize, looking at the originals, the banner image is the only one in 300 dpi, maybe it has an issue with this?

gimli/popcornmix might needs to shine some light on this one....

[Milhouse]

Thanks, yes that looks similar. I'm building OpenELEC now with debug enabled and will see if I can capture anything in gdb, but with a non-debug build I couldn't see anything at all in gdb - the Pi just froze.

My advancedsettings.xml has the following:

Code:

<fanartres>720</fanartres>
  <imageres>512</imageres>

Will report back when I have more detail, hopefully gimli and popcorn can chip in either here or on trac, but obviously being Easter I'm not expecting an immediate response!

Regarding the banner size, not really sure as I have other TV shows with the same banner/fanart/poster resolution and proportions that aren't causing a problem.

Potentially there are two problems here, 1) The banner has become corrupted during conversion (it has visible glitches) and then 2) A corrupt image should not cause the machine to hang. Frustratingly, I've just looked at the artwork for The Big Bang Theory (which also causes an identical hang/freeze/crash) and I can't see any obvious glitches there.

[Jester]

I saw the same issue when I rebuild an extra pi 2 days ago, once it gets passed building the cache/banner/thumbsnails it works fine, but initially it freezes.

I'm running this btw (shouldnt matter but you could remove it and see what happens with running the defaults, currently both openelec and raspbmc set these on their default builds)
<imageres>540</imageres>
<fanartres>720</fanartres>

P.S.
Trying to figure out what OMX does here
https://github.com/xbmc/xbmc/blob/master...XImage.cpp

from line ~670

[Jester]

related ??
https://github.com/OpenELEC/OpenELEC.tv/issues/2141

https://github.com/OpenELEC/OpenELEC.tv/issues/2138

[Milhouse]

Yes, interesting... not sure when this problem started, but certainly only noticed it in the last 2-3 days so maybe a recent commit...

[popcornmix]

Yes, interesting... not sure when this problem started, but certainly only noticed it in the last 2-3 days so maybe a recent commit...

The jpegs all decode for me (just by browsing to them). banner.jpg does give a "bitstream corrupt" error, but correctly falls back to libjpeg (which produces an image) and I see no hang.

We have recently added support for jpegs with large extension tags (e.g. adobe APP1 tag which contains an uncompressed copy of the decoded jpeg).
However reverting back before this, doesn't change the "bitstream corrupt behaviour on banner.jpg.

Note that banner.jpg is 306K for 758x140. That is basically the size of an uncompressed 24bpp image. I think it contains an uncompressed copy of the image which the GPU doesn't like.
I'll check if that can be fixed, or if there's another problem (possibly the jpeg is invalid, and the uncompressed image is what libjpeg shows).

I think the hanging problem is something different. Possibly provoked by a jpeg that GPU decode fails on and falls back to libjpeg decode.
If you can reproduce the hang repeatably (ideally just by browsing photos, or using JSON interface to display the jpeg), then that would help.

[Milhouse]

Just going back through some old builds and I have a build from 14 March which is *fine*, but a build from 23 March hangs/freezes when bringing up the "Choose art" dialog... got a few more old builds which may narrow it down further...

Edit: OK this is the best I can do on narrowing it down - somewhere between 15 March and 20 March:

Code:

-rw-rw-r--  1 neil neil  96143043 Mar 15 18:09 OpenELEC-RPi.arm-devel-20130315180045-r13588.tar.bz2 <---- GOOD
-rw-rw-r--  1 neil neil  96085626 Mar 20 20:47 OpenELEC-RPi.arm-devel-20130320192300-r13628.tar.bz2 <---- BAD

The above are UK times. The revision number probably bears no relation to anything in the stock repository, but both builds would have been fully up to date with the stock repo apart from my patch to initramfs/init.

[popcornmix]

Just going back through some old builds I have a build on 14 March is *fine*, but a build from 23 March hangs/freezes... got a few more old builds which may narrow it down further...

I'm assuming 14 March still produces "bitstream corrupt" on banner.jpg?

There are firmware changes to jpeg decode on 18 March, and 29 March.
It would be interesting if "start.elf" is significant in causing/fixing the hang. Double check that latest firmware doesn't fix it (not sure if you already have that).

[Milhouse]

I'm assuming 14 March still produces "bitstream corrupt" on banner.jpg?

Yes, 15 March also.

debug.log (pastebin) for 15 March build when opening "Choose art" dialog for "Arrow" TV Show.

The three images shown in the "Choose art" are (from the top to the bottom, in case the order bears any relation to sequences shown in the debug log): Banner, Poster then Fanart

The 15 March build has firmware dated 4 March.

Code:

rpi512:~ # vcgencmd version
Mar  4 2013 00:06:09
Copyright (c) 2012 Broadcom
version 374181 (release)

There are firmware changes to jpeg decode on 18 March, and 29 March.
It would be interesting if "start.elf" is significant in causing/fixing the hang. Double check that latest firmware doesn't fix it (not sure if you already have that).

My latest git build of OE (finished building just 10 minutes ago) has the following firmware:

Code:

rpi512:~ # uname -a
Linux rpi512 3.6.11 #1 PREEMPT Mon Apr 1 13:10:44 BST 2013 armv6l GNU/Linux
rpi512:~ # vcgencmd version
Mar 19 2013 00:02:38
Copyright (c) 2012 Broadcom
version 377915 (release)

I've rebuilt OE with debug enabled, but gdb doesn't produce anything useful:

Code:

rpi512:~ # gdb /usr/lib/xbmc/xbmc.bin
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv6zk-openelec-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/xbmc/xbmc.bin...done.
(gdb) thread apply all bt
(gdb) run
Starting program: /usr/lib/xbmc/xbmc.bin
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGILL, Illegal instruction.
0xb6e49420 in _armv7_neon_probe () from /usr/lib/libcrypto.so.1.0.0
(gdb) continue
Continuing.

Program received signal SIGILL, Illegal instruction.
_armv7_tick () at armv4cpuid.S:17
17      armv4cpuid.S: No such file or directory.
(gdb) continue
Continuing.
[New LWP 2199]
[New LWP 2201]
[New LWP 2200]
[New LWP 2203]
[New LWP 2219]
[LWP 2201 exited]
[LWP 2200 exited]
[LWP 2219 exited]

[LWP 2219 exited] appears after I click the "Choose art" button, then the Pi locks up.

[popcornmix]

@MilhouseVH
Can you try with latest start.elf/fixup.dat (or start_x.elf/fixup_x.dat) from:
https://github.com/Hexxeh/rpi-firmware

[Milhouse]

Hurrah, it works again!

Code:

rpi512:~ # vcgencmd version
Mar 29 2013 23:13:56
Copyright (c) 2012 Broadcom
version 380831 (release)

OK, so just need to wait for Stefan to update the OE repo with the latest firmware. Thanks popcornmix and Jester.

[Jester]

Title updated, thx popcornmix
case closed

March 29 firmware:
Firmware: Skip unused jpeg markers

[Milhouse]

I suppose a related question is why banner.jpg became corrupted - do you think this is fixed by the 29 March firmware also? My Big Bang Theory banner.jpg (which also used to crash the device with 19 March firmware) also shows the "Bitstream corrupt" message despite there being no obvious visual glitches.