• 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
#91
(2013-07-29, 14:32)lordvader Wrote: OK, so I can confirm that my RPi doesn't boot with the bootcode.bin file that's bundled with the 3.1.5 release.
Using the bootcode.bin from the 3.1.3 release, I am able to boot, overclock, run of USB, and all the other awesome stuff.

Can you try copying the bootcode.bin from the 3.1.5 back on just to be sure.
It seems more likely bootcode.bin got coppupted in the upgrade, than it's incompatible with your pi
(there would be a lot more reported issues if that bootode.bin was incompatible with a specific board revision).
#92
Smile 
I am finding this latest build responsive and almost fully functioning for my uses thanks for everyone's efforts.

ArgusTV adon client now much more responsive
BBC iplayer working well
EDL skipping working well
Ditto bookmarks.
Playing .ts H264 Dolby 5.1 recordings fine

Minor gremlins;
Buffer seems to get full? occasionally when try step forward or key in time to jump to its not quite right. I think its on Dolby 5.1 H264 files....
#93
(2013-07-29, 12:27)popcornmix Wrote: Can you try copying the files from FAT partition off the sdcard, formatting it (which should be safe, windows won't touch the ext partitions), and copying back on (and checking they are identical to expected ones).

EDIT: could you backup the sdcard (with dd/winimage) first. Just in case my suggestion fixes it, it may be interesting to analyse the FAT partition.
I have a suspicion that when FAT parition gets sufficiently defragmented it may provoke a bug in the bootcode that stops it booting - but that is not proven.

I took a backup of the entire card (~100MB .tar.gz - working on setting up a dropbox account and will PM you a link), plus the files that are on there. It's a 4GB Class 4 SD card, but only contains a single 3.75GB FAT32 partition as I'm using NFS for /storage.

I analysed the fragmentation level in Windows, and it was 0%. I compared the files that should be on the card, with what are actually on there, and there is no difference so it looks like the integrity of the files is fine.

I performed a Quick format (FAT32) in Windows7, copied the original files back on - no boot. Compared the files, still no differences.

I performed a Full format (FAT32) in Windows7, copied the original files back on - no boot. Compared the files, still no differences.

I then reformatted the partition using mkfs.vfat in Ubuntu 13.04, copied *new* files extracted from a git build (which works on other cards) and still no boot!

And when I say "no boot", all I get is a steady red light as soon as power is applied, no other LEDs are illuminated, not even briefly.

I'm happy to post this SD card to you if you wish to receive it - PM me an address! Smile
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.
#94
(2013-07-29, 18:21)MilhouseVH Wrote: And when I say "no boot", all I get is a steady red light as soon as power is applied, no other LEDs are illuminated, not even briefly.

Can you try squeezing the sdcard into the holder when trying to boot?
I've seen an sdcard that didn't seem to make good contact with the pins in sdcard socket that would boot when pressure was applied.
#95
Regarding the no-boot issue, have you looked into power supply issues?

I have two Pi's with different power supplies.
- A wall wart http://www.newark.com/jsp/search/product...ku=53W8467
- An onboard supply - http://nwazet.com/nwazet-pi-power-supply

Whichever Pi is connected to the onboard supply is rock solid and boots reliably. The one connected to the wall wart supply is fussy - I have had to unplug/replug several times in order to get it to boot. When it doesn't boot, it is stuck on the red light. Swapping power supplies ensures a boot first time every time. FYI, I have tried several other power supplies — iPad power supply, "HDD" designated USB port on my TV — and they perform similarly to the wall wart power supply, so I don't think anything is defective - per se.

Last data point re boot up issues - overclocking, overvolting and connected devices exacerbate the boot up issue by drawing further current.

Finally, I don't know that the more recent builds are unconnected to this issue. Could there be a change to the OS that results in additional demand on the power supply during bootup? In that event, it could explain my and milhouse's bootup issues.
#96
(2013-07-29, 18:42)popcornmix Wrote: Can you try squeezing the sdcard into the holder when trying to boot?
I've seen an sdcard that didn't seem to make good contact with the pins in sdcard socket that would boot when pressure was applied.

Well whaddya know... yep, squeezing it did the trick! What's that all about? And if I stop squeezing during the boot sequence, the boot will fail as it can no longer access the SD card!

Strange that a card which has been working fine since Christmas should just stop working 6 months later - and not just in one Pi, but in two different Pis. Since it's most likely a card problem, I'm guessing that teasing out the pins in the socket won't help... I wonder if the second failure is for the same reason (I still haven't received it back yet - brother being a bit tardy).
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.
#97
(2013-07-29, 18:53)MilhouseVH Wrote: Well whaddya know... yep, squeezing it did the trick! What's that all about? And if I stop squeezing during the boot sequence, the boot will fail as it can no longer access the SD card!

Yes, it's strange. I have one sdcard that seems fractionally thinner than my other ones. It only works when squeezed.
I believe a bit of card or tape attached to the sdcard (on opposite side to pins) will provide a workaround.

Teasing the sdcard pins may work (although the problem doesn't seem to be in the socket, which works with the other cards).
#98
As the Pis are both in cases I've placed a blob of bluetak and a chopped credit card under the slot and it seems to be doing the trick (mostly) - I wonder if some solder along the pins of the SD card might be more effective?
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.
#99
Just to confirm the problem I'm having with my hubs getting hot is nothing to do with these builds as it happens with Raspbian Wheezy as well, so it's either something at a lower software/firmware level or I've just got two faulty boards (maybe there was a bad batch around when I bought them).
(2013-07-29, 19:24)popcornmix Wrote:
(2013-07-29, 18:53)MilhouseVH Wrote: Well whaddya know... yep, squeezing it did the trick! What's that all about? And if I stop squeezing during the boot sequence, the boot will fail as it can no longer access the SD card!

Yes, it's strange. I have one sdcard that seems fractionally thinner than my other ones. It only works when squeezed.
I believe a bit of card or tape attached to the sdcard (on opposite side to pins) will provide a workaround.

Teasing the sdcard pins may work (although the problem doesn't seem to be in the socket, which works with the other cards).

I am sorry I didn't recognise the issue earlier, I would have chimed in earlier... I can confirm that i can boot only if ad a small spacer underneath the SD card. I think it is a combination of lazy pins (the board is actually not really flat) and the SD being thinner.
Anyway I use a bit of plastified paper (it used to be a label tag on some clothe i bought) shaped as SD card and I haven't had a missed boot...

M
Quote:Myth PVR has had show-stopping bugs in every Rbej build AFTER July 3, 2013. This includes the July 29 build.

1. Skip, including big skip and commercial skip does not work. Instead of skipping, the playback hiccups for a second and resumes approximately from where you left off.

2. Less important, possibly related: When you pause or skip, the display at the top right corner reports incorrect information. Sometimes it indicates a very short program length, just slightly exceeding the point you are in the show (like 0:15/0:17). Sometimes it reverses program length and position, and reports incorrect program length (like 7:22:00/1:15).

These features work correctly in Gotham alpha 5 (tested in OS X).

These problems appear to have been introduced with the experimental FF feature. If I have to choose between skip and FF, I'd rather have skip (i.e. skip, commercial skip and big skip). Accordingly, I have been reverting to July 3 after testing new builds.

+1
(2013-07-29, 19:24)popcornmix Wrote:
(2013-07-29, 18:53)MilhouseVH Wrote: Well whaddya know... yep, squeezing it did the trick! What's that all about? And if I stop squeezing during the boot sequence, the boot will fail as it can no longer access the SD card!

Yes, it's strange. I have one sdcard that seems fractionally thinner than my other ones. It only works when squeezed.
I believe a bit of card or tape attached to the sdcard (on opposite side to pins) will provide a workaround.

Teasing the sdcard pins may work (although the problem doesn't seem to be in the socket, which works with the other cards).
Holy cow, now I've heard it all! Glad I'm in the software forums so I could learn about a potential hardware issue. Just crazy but I will remember it. I wonder if the SD cards are just wearing out from frequent insertion/removal.
(2013-07-29, 19:33)doveman2 Wrote: Just to confirm the problem I'm having with my hubs getting hot is nothing to do with these builds as it happens with Raspbian Wheezy as well, so it's either something at a lower software/firmware level or I've just got two faulty boards (maybe there was a bad batch around when I bought them).

Just recalled you are powering the Pi from GPIO. Not sure if the architecture of the Pi properly isolates two supplies either side of the USB - is it possible the two supplies fighting each other is what is causing the hub to heat up?
(2013-07-29, 18:42)popcornmix Wrote:
(2013-07-29, 18:21)MilhouseVH Wrote: And when I say "no boot", all I get is a steady red light as soon as power is applied, no other LEDs are illuminated, not even briefly.

Can you try squeezing the sdcard into the holder when trying to boot?
I've seen an sdcard that didn't seem to make good contact with the pins in sdcard socket that would boot when pressure was applied.

I had a card that had a hairline crack in the plastic that caused this issue.
I did copy the bootcode back to verify, and it definitely isn't working.

For the time being I'm using 3.1.5, with the bootcode from 3.1.3.

Also, let me clarify. A stock 3.1.5 install works fine. As soon as I alter anything in the /storage partition the Pi will only boot with the older bootcode.

(2013-07-29, 15:27)popcornmix Wrote:
(2013-07-29, 14:32)lordvader Wrote: OK, so I can confirm that my RPi doesn't boot with the bootcode.bin file that's bundled with the 3.1.5 release.
Using the bootcode.bin from the 3.1.3 release, I am able to boot, overclock, run of USB, and all the other awesome stuff.

Can you try copying the bootcode.bin from the 3.1.5 back on just to be sure.
It seems more likely bootcode.bin got coppupted in the upgrade, than it's incompatible with your pi
(there would be a lot more reported issues if that bootode.bin was incompatible with a specific board revision).
  • 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223