• 1
  • 68
  • 69
  • 70(current)
  • 71
  • 72
  • 174
OpenELEC Testbuilds for RaspberryPi
@sdsnyr94
I get the same issues if I overclock specific settings.
For example, if I overclock isp_freq or gpu_freq.
But, it might very possibly be power supplý as well as overclocking might demand more current.

So, check overclock settings and power supply.
(2013-01-24, 17:12)miappa Wrote: @sdsnyr94
I get the same issues if I overclock specific settings.
For example, if I overclock isp_freq or gpu_freq.
But, it might very possibly be power supplý as well as overclocking might demand more current.

So, check overclock settings and power supply.

No overclock, and I have tried 2 power supplies, a powered USB hub, and the connection off my TV... only thing that works without lockup is Xbian Alpha 3.
(2013-01-23, 03:55)spjonez Wrote:
(2013-01-22, 23:25)FattyMcDirty Wrote: one question: using the standard skin now... it's running pretty nice with your help, storage is now on USB, BUT: the artwork, like dvd cases etc... ya.. kinda "low res" - is this intended to be so? can i load them in high-res somehow?
Change *res settings and delete cache:
http://forum.xbmc.org/showthread.php?tid...pid1282798

that did it, thanks!


(2013-01-23, 16:38)popcornmix Wrote:
(2013-01-23, 16:23)FattyMcDirty Wrote: so does no one know how to workaround that issue? it's not related to the pi connected to the amp... that issue also exists when i connect mit rpi directly to my tv..... very strange... and somewhat annoying Sad it's also not build-related... cause i already tried others... so what could it be?

You can try adding:
hdmi_pixel_encoding=<n>

to config.txt. n can be:

HDMI_PIXEL_ENCODING_RGB_LIMITED = 0
HDMI_PIXEL_ENCODING_RGB_FULL = 1,
HDMI_PIXEL_ENCODING_YCbCr444_LIMITED = 2,
HDMI_PIXEL_ENCODING_YCbCr444_FULL = 3,

(shouldn't be needed if TV reports the correct pixel encoding modes supported in its edid)

mh.. those ones changed the situation, but none of them actually keep up with the hdmi-output from my htpc strangely. it just doesn't look as sharp as it should be and the blacks are also greyed out. setting hdmi_pixel_encoding= to 0 results in a VERY pixelated UI, so that one is definitely not the solution. setting it to 1 seems to look like the standard, as if this setting was not manually added. is it possible, that the overall quality of the hdmi-out is not that top notch?
(2013-01-24, 17:30)FattyMcDirty Wrote: mh.. those ones changed the situation, but none of them actually keep up with the hdmi-output from my htpc strangely. it just doesn't look as sharp as it should be and the blacks are also greyed out. setting hdmi_pixel_encoding= to 0 results in a VERY pixelated UI, so that one is definitely not the solution. setting it to 1 seems to look like the standard, as if this setting was not manually added. is it possible, that the overall quality of the hdmi-out is not that top notch?

I believe the output of HDMI is effectively perfect (within 1 lsb of a dedicated pattern generator).
Are you using a computer monitor? (that seems likely if you are getting full range RGB by default).
Can you report the output of "tvservice -s" when a video is playing?

I'm not sure what the problem could be. Can you try a different TV or monitor?
(2013-01-23, 19:22)tfft Wrote:
(2013-01-22, 23:08)tfft Wrote: Here are a couple of debug files which ended-up with a freeze/reboot each,
reboot1.log 503.15 KB http://a4mqui.dl4free.com/en/
reboot2.log 568.91 KB http://gs71m9.dl4free.com/en/

I then disabled CEC (to get rid of its debug messages) and here are more reboots,
reboot3.log 326.88 KB http://5d9gr2.1fichier.com/en/
reboot4.log 164.99 KB http://6ktwkq.1fichier.com/en/
reboot5.log 276.27 KB http://yc54z9.1fichier.com/en/ (zeroconf off)
Are these log files helpful ? Do they contain enough info to point at the freezing problem/issues ?
This is the third report of freezing followed by GUI reboots (the Rpi itself doesn't reboot for clarification, the Rpi simply freezes for a bit and then comes back to life if I'm ssh'ed into it) using recent/newer snapshots. The problem has been confirmed by 3 (or 4) people and a few log files have been uploaded - feedback please.

Images tested,
- r13077 (git 2a54d46e6d)
- r13084 (git 39820e2ef7)

In passing, in almost all the logs the last thing seen are the following messages (significant ?),

WARNING: CRenderManager::FlipPage - timeout waiting for flip to complete
WARNING: CRenderManager::FlipPage - timeout waiting for previous frame

Again, any insight PLEASE ? What further info/data can I do to provide to pin this issue down ?

A tiny debug (reboot) log file,
reboot6.log 16.50 KB http://44jk2f.dl4free.com/en/
All streaming stoppage, including failures/freezes/reboots/etc, should remember the video's last location (which is not the case today), shouldn't it ? So if there is a power failure or a reboot or ... one should be able to pick-up where the stream last left off.

If I'm watching a 4 hour movie which hits a snag and freezes and then reboots the GUI at hour 2 minute 53, once I'm rebooted I should be able to be told where I need to pick-up ("resume") from, no ?

This functionality today is lacking, do others agree on the need to fix this ?
Isn't ogg video supposed to be supported in openelec/xbmc ? I recently converted a file into an 'ogv' format yet when I play it there is no video and I can only hear the audio portion - is this a known issue ?

Using r13084 (git 39820e2ef7) on a vanilla Rpi-256
(2013-01-24, 23:20)tfft Wrote: All streaming stoppage, including failures/freezes/reboots/etc, should remember the video's last location (which is not the case today), shouldn't it ? So if there is a power failure or a reboot or ... one should be able to pick-up where the stream last left off.

If I'm watching a 4 hour movie which hits a snag and freezes and then reboots the GUI at hour 2 minute 53, once I'm rebooted I should be able to be told where I need to pick-up ("resume") from, no ?

This functionality today is lacking, do others agree on the need to fix this ?

How could it bookmark your last position, if the video never actually "stops"? The whole thing just reboots or freezes, and there appear to be no more writes to the database... if there were, we would see more in the logs.
(2013-01-24, 23:20)tfft Wrote: All streaming stoppage, including failures/freezes/reboots/etc, should remember the video's last location (which is not the case today), shouldn't it ? So if there is a power failure or a reboot or ... one should be able to pick-up where the stream last left off.

If I'm watching a 4 hour movie which hits a snag and freezes and then reboots the GUI at hour 2 minute 53, once I'm rebooted I should be able to be told where I need to pick-up ("resume") from, no ?

This functionality today is lacking, do others agree on the need to fix this ?

Finding a solution to the GUI/Pi crashes would of course be best. What you are asking for would require constant resume-point writes to the database while any media is playing, and when the Pi crashes this would most likely results in database corruption (not to mention increased CPU/IO overhead while media is playing). All this to mask the fact that your Pi isn't stable?

So no, I don't at all agree on the need to fix this, when the real problem is your Pi being unstable.

My OpenELEC Pi - overclocked to 1GHz - would hang (ie. totally freeze, power cycle required) once in a while when playing media, but also quite often when scraping media however the latest build (r13090) has completed 4 or 5 Movie AND TV Show scrapes (time required for each combined scrape: 2-3 hours) without a hitch, so maybe the latest firmware (Jan 15) offers some stability improvements.
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.
(2013-01-25, 05:00)MilhouseVH Wrote: ...latest build (r13090)...

Out of curiosity, where can you find this build?

(2013-01-25, 12:12)miappa Wrote:
(2013-01-25, 05:00)MilhouseVH Wrote: ...latest build (r13090)...

Out of curiosity, where can you find this build?

Sorry, should have said it's a custom build I built myself - basically the same as you get from http://openelec.thestateofme.com but with a couple of extra patches (NFS Auto-Update) that will have no impact on overall stability.
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.
(2013-01-24, 23:20)tfft Wrote: All streaming stoppage, including failures/freezes/reboots/etc, should remember the video's last location (which is not the case today), shouldn't it ? So if there is a power failure or a reboot or ... one should be able to pick-up where the stream last left off.

No. Not supported by xbmc on any platform. The crash needs to be fixed.
Most likely it is an out of memory issue. Can you check the dmesg log for "out of memory killer" stopping xbmc?
Where is the media being played from? Network streams (including http streaming from local network) require a lot more memory. Reducing (or setting to 0) cachemembuffersize in advancedsettings may help.
Other common causes of crashing are insufficient power supplies, or too high an overclock.
(2013-01-25, 12:14)MilhouseVH Wrote:
(2013-01-25, 12:12)miappa Wrote:
(2013-01-25, 05:00)MilhouseVH Wrote: ...latest build (r13090)...

Out of curiosity, where can you find this build?

Sorry, should have said it's a custom build I built myself - basically the same as you get from http://openelec.thestateofme.com but with a couple of extra patches (NFS Auto-Update) that will have no impact on overall stability.
NFS autoupdate ie. also affecting the problem we briefly talked about with not having SYSTEM on sdcard that resulted in no automatic firmware/kernel update has been added/fixed in r13090?
Arg I see now that I miss read. "with a couple of extra fixes" lol. Sorry mate.. I hope it gets accepted at some point as you say if it's just one line of code that does not harm anything else it seems silly not to.

Edit: btw. r13090 has not hit "thestateofme" yet. Smile
(2013-01-24, 23:45)tfft Wrote: Isn't ogg video supposed to be supported in openelec/xbmc ? I recently converted a file into an 'ogv' format yet when I play it there is no video and I can only hear the audio portion - is this a known issue ?

Using r13084 (git 39820e2ef7) on a vanilla Rpi-256
ogv I take is not a container but a codec? I never even thought it existed so i would guess no.
What's wrong with h264?! It seems like an unnessesary bother and hard to get on par anywhere with all the more standard industry codecs and popular containers around IMHO.
(2013-01-25, 13:43)tuxen Wrote: NFS autoupdate ie. also affecting the problem we briefly talked about with not having SYSTEM on sdcard that resulted in no automatic firmware/kernel update has been added/fixed in r13090?
Arg I see now that I miss read. "with a couple of extra fixes" lol.

Yes, but fixed only in *my* personal build, with my patches, as the patches are yet to be accepted into the official builds (I'm not sensing much interest here either). Sad
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.
  • 1
  • 68
  • 69
  • 70(current)
  • 71
  • 72
  • 174

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi12