Viewing artwork causes Pi to crash - SOLVED
#16
(2013-04-01, 16:24)MilhouseVH Wrote: 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.

I don't think the image is corrupted, the issue is adobe writing an uncompressed version of the jpeg in the extended tags, which rpi didnt like with the old firmware, the new firmware just skips this tag as it's not used.

another example image is this one
http://thetvdb.com/banners/graphical/121361-g19.jpg

which is mentioned in this ticket.
https://github.com/OpenELEC/OpenELEC.tv/issues/2138

which probably is now fixed too with the new firmware.
Reply
#17
OK, although the Arrow banner clearly is corrupt (it has visual glitches not present in the original), though this may have been a one-off as I've just re-cached it with 29 March firmware and the visual glitches are now gone.

However, if these extended tags are now being ignored by the 29 March firmware, why does the "Bitstream corrupt" message (logged at ERROR level) still appear in the logs?
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.
Reply
#18
Before the 14th March change, the assumption was that you had enough data in the first packet (80K) to extract the dimensions (e.g. SOF was contained in first 80K).
JPEGs with uncompressed (adobe/APP2) data attached broke this assumption.
However, it still behaved sensibly. You got a "bitstream corrupt" message, and decoding fell back to libjpeg and everything worked (although a little slower than usual).

14th March added a fix for this problem that meant the APP2 data was skipped.
It did introduce a new bug causing the hang. This was spotted internally and fixed in March 29th firmware.

The two new files have a large APP1 data, which we don't skip (as that can contain useful exif data).
Because of this the files don't get GPU decoded, but shouldn't hang.
I've added the new files to the bug report, so GPU decoding will hopefully work in the future.

It may be worth finding out what produces these files. The one on the trac ticket is 688K for a 758x140 file which is 6.6 bytes per pixel.
i.e. much larger than even an uncompressed 32bpp PNG file. Obviously not ideal for a speedy UI (although xbmc should use t a smaller cached version after the first decode).
Reply
#19
Thanks popcornmix. Not sure where I got mine from, either fanart.tv or thetvdb.com - sadly I have no idea what application produced them.
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.
Reply
#20
Not sure if helpful

http://thetvdb.com/banners/graphical/121361-g19.jpg

mentioned Adobe Photoshop CS5.1 in the origin tag....
Reply
#21
Thanks guys, MillHouse lead me here from a post i had made on the OpenElec github. I've gone back to 2.99.5 for now and everything is golden.

I tried the latest Dev build but it still crashed for me.
Reply
#22
The latest dev build still crashes even with the 29 March firmware?
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.
Reply
#23
(2013-04-01, 17:19)popcornmix Wrote: Obviously not ideal for a speedy UI (although xbmc should use t a smaller cached version after the first decode).

Sorry to keep banging on about this, but it's this final sentence that has me confused, as I don't understand why the converted image should continue to provoke the "Bitstream corrupt" image from the Pi decoder.

I entirely understand that, upon first decode, the input image may contain all sorts of garbage that the decoder has to workaround or skip entirely, in which case the "Bitstream corrupt" error message is entirely appropriate, but shouldn't the Pi decoder/encoder then be outputting what is - as far as the Pi decoder is concerned - an entirely valid and non-corrupt (but much smaller) jpg image?

It's just that, with 29 March firmware, while I see (and understand) the "Bitstream corrupt" message on first decode (ie. when the input is the 300K "Arrow" banner with Adobe garbage), I don't understand why the "Bitstream corrupt" message should continue to be output during subsequent decodes when the image being decoded is now the version created by the Pi (in this case, a much smaller 37K banner and apparently devoid of Adobe - and I would have thought, any other - garbage).
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.
Reply
#24
(2013-04-01, 21:51)MilhouseVH Wrote: It's just that, with 29 March firmware, while I see (and understand) the "Bitstream corrupt" message on first decode (ie. when the input is the 300K "Arrow" banner with Adobe garbage), I don't understand why the "Bitstream corrupt" message should continue to be output during subsequent decodes when the image being decoded is now the version created by the Pi (in this case, a much smaller 37K banner and apparently devoid of Adobe - and I would have thought, any other - garbage).
If you delete the 37K banner and let it be recreated, does the replacement also produce "bitstream corrupt" messages? That wound be unexpected.
Reply
#25
Yes, I deleted it both with rm, and also the texturecache script (C tvshows - ie. delete and recache all tvshows). In both cases, when first decoded (and cached) it produced "bitstream corrupt" (expected) but also on subsequent decodes, when decoding the newly cached and smaller file, it still produces "bitstream corrupt" (not expected).

You can download the original and converted files (latter created with OE from 30 March, firmware from 29 March) here (208K Zip)
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.
Reply
#26
Latest firmware update should fix the "corrupt bitstream" error produced by banner.jpg and 121361-g19.jpg.
(It now discards APP1 extensions that are not exif).
Reply
#27
Excellent, many thanks - no error at all now, not on first conversion or subsequent decodes!
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.
Reply
#28
Quote:I've been having the same problem with OpenElec. What RPi OS are you using to run this update?

Thanks.

EDIT:
I have solved my issue using this and a forum post over at OpenElec.
I have posted my solution over at the OpenElec forum I thought I would help others encase they have the same issue and post it here as well.

Quote:Here are my steps to resolve the issue based on the info PVG provided...
1. Download latest firmware as a ZIP archive on my PC from -> github.com/raspberrypi/firmware
2. Copy bootcode.bin , fixup.dat , start.elf from the boot/ folder in the ZIP to the RPi somehow; I used the SAMBA share \\192.168.1.101\Videos

Then I SSH'ed to my RPi:
3. Ran command: mount -o remount,rw /dev/mmcblk0p1 /flash
4. Ran command: cd /storage/videos
5. Ran command: mv bootcode.bin fixup.dat start.elf /flash
7. Ran command: reboot
Reply

Logout Mark Read Team Forum Stats Members Help
Viewing artwork causes Pi to crash - SOLVED0