• 1
  • 67
  • 68
  • 69(current)
  • 70
  • 71
  • 174
OpenELEC Testbuilds for RaspberryPi
(2013-01-23, 19:16)popcornmix Wrote: Progressive jpegs can't be decoded by GPU. They are supported, they just get decoded on ARM.

Aha, OK thanks. Since they're being cached locally, do you know if what is written (ie., what is cached) is the non-progressive variety, or progressive? If the former, I'm wondering if this warning is really necessary, and if the latter would it be possible to name the offending image so that it could be dealt with (converted manually to non-progressive format)?
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-23, 19:16)popcornmix Wrote: Does removing guisettings.xml fix it?
Does removing custom guires setting fix it?

Yep! Delete guisettings.xml and it works like a charm (if you remember to re-set "Adjust frame rate..." :S )

CPU at 75-80% with movie + GUI menu (≈ 50% with only movie). Confluence that is.
(2013-01-23, 19:22)MilhouseVH Wrote: Aha, OK thanks. Since they're being cached locally, do you know if what is written (ie., what is cached) is the non-progressive variety, or progressive? If the former, I'm wondering if this warning is really necessary, and if the latter would it be possible to name the offending image so that it could be dealt with (converted manually to non-progressive format)?

Local cache is always encoded by GPU, and so will be non-progressive. Therefore you should only hit the progressive error once per image.
I think jpegs that form part of skin are not cached, so it would be bad if they are progressive - not sure if any are though.

You can convert progressive jpegs to baseline with (from imagemagick)
convert image_prog.jpg -interlace none image_progoff.jpg
(2013-01-23, 20:04)miappa Wrote: Yep! Delete guisettings.xml and it works like a charm (if you remember to re-set "Adjust frame rate..." :S )

The resolutions section of guisettings is a pain. Changing guires breaks what is in there. Changing how modes are reported (like the SBS/TAB change) also can.
I've a suspicion that just connecting to a new monitor with a different list of supported modes may cause you problems.

Trouble is, it's in generic xbmc code, so it's pretty hard to change to make it work better on the Pi.
(2013-01-23, 20:11)popcornmix Wrote: Local cache is always encoded by GPU, and so will be non-progressive. Therefore you should only hit the progressive error once per image.
I think jpegs that form part of skin are not cached, so it would be bad if they are progressive - not sure if any are though.

You can convert progressive jpegs to baseline with (from imagemagick)
convert image_prog.jpg -interlace none image_progoff.jpg

Yes, the trouble is it's difficult to know which image is in progressive format as the filename is not displayed. If this warning message really isn't an issue as all images (certainly meta-data related imagery) will end up being GPU encoded and thus not in progressive format, maybe this WARNING should be changed to a DEBUG?
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.
with the LATEST build, framerate adjustment doesnt work here... it humbles around 23 to 28fps with 23.976fps files.... downgraded to the build before the latest: everythings backfine... hmmmmm
(2013-01-23, 21:53)FattyMcDirty Wrote: with the LATEST build, framerate adjustment doesnt work here... it humbles around 23 to 28fps with 23.976fps files.... downgraded to the build before the latest: everythings backfine... hmmmmm
No idea what this means. Where are you getting "23 to 28fps" from?
Any numbers printed on the screen are likely to be the gui framerate which has nothing to do with the video framerate.
What is the framerate the display is set to (tvservice -s) and is the video smooth?
(2013-01-23, 20:11)popcornmix Wrote: The resolutions section of guisettings is a pain. Changing guires breaks what is in there. Changing how modes are reported (like the SBS/TAB change) also can.
I've a suspicion that just connecting to a new monitor with a different list of supported modes may cause you problems.

Trouble is, it's in generic xbmc code, so it's pretty hard to change to make it work better on the Pi.

This is fine I believe since most people probably only need these functions on a 3D TV (and therefor use only one monitor), but it might be a good idea to have something in the wiki about it.
I will run this for a while and see if anything breaks, and if it does it´s an easy enough fix.
And if it was to be to much problems you can just rename the file/folder (delete HSBS etc.), 3D still works correct but you have to push a button (and scrambled GUI of course).
nope, video stutters with newest build. back on previous build, video is smooth and the info shows stable 24fps.....
(2013-01-23, 23:26)FattyMcDirty Wrote: nope, video stutters with newest build. back on previous build, video is smooth and the info shows stable 24fps.....

You are not going to get any help without some information.
Does it happen with all files?
Do you have "sync display to video frame rate" enabled?
When playing the 24fps file what does "tvservice -s" report.
Can you post mediainfo of a failing file and an xbmc.log ?
(2013-01-23, 23:26)FattyMcDirty Wrote: nope, video stutters with newest build. back on previous build, video is smooth and the info shows stable 24fps.....
What info is this? The tv will choose a mode once for example 24Hz and stay there?! Otherwise the tv would shift modes between 24Hz and 25Hz constantly which I never seen any tv do.

No problems here no stuttering. Also with the GUI and vsync on the GUI fps is rock stable.

As popcornmix says you can not back out of a movie (while it's running) to the GUI screen and look at the systeminfo there. And do you have sync display frame rate to movie on?
i don't knowwhy this is so hard to understand. i tested both versions, the latest build and the previous build. i have my gui running at 1080p/60, sync display frame rate to movie is enabled, automatically adjust framerate also enabled - in BOTH versions. the latest build stutters and the gui info screen of xbmc shows me an unstable framerape which drops from 23.xx to 29.xx constantly (NOT the tv info, and it's also NOT the gui framerate, it's the playback info while watching a video and the MOVIE stutters, not the GUI...). the previous build show a stable framerate in this info gui window... so what's the point? i tested both versions, with the exact same settings - one stutters, one doesn't. so is this my fault now? it's not necessary to post a media info since this is happening with all files of that framerate... like my mkv tv-shows or mkv movie sets... well, just stickin' to the previous build then, for now which is running totally fine here...
(2013-01-24, 13:31)FattyMcDirty Wrote: i don't knowwhy this is so hard to understand.

Well, for starters... I don´t think there are any mind readers in here...
None of this was posted before so how do you think people would know what problems you have?
And "just sticking with previous.." does not help the on going work of making a stable release, so if this is your way of helping the community I suggest that you keep out of this forum.
Just saying...
(2013-01-24, 13:52)miappa Wrote:
(2013-01-24, 13:31)FattyMcDirty Wrote: i don't knowwhy this is so hard to understand.

Well, for starters... I don´t think there are any mind readers in here...
None of this was posted before so how do you think people would know what problems you have?
And "just sticking with previous.." does not help the on going work of making a stable release, so if this is your way of helping the community I suggest that you keep out of this forum.
Just saying...
@FattyMcDirty:
If you'd ever had to find and fix an issue in a software program with the kind of information you provided, you'd feel the pain...

If you want to actually help the community (and yourself, btw), please ask whatever info the devs need to try to figure out the issue and provide it...

Do you know XBMC is actually FREE and these developers still carry on developing new versions, functionalities and helping users to fix issues?
yes... sorry for that. trying to provide some more info l8r.
Hey guys and gals - As I have mentioned a few times, my Pi will lock up at random points in a movie, usually after about an hour to an hour and a half. When it locks, it locks the unit cold... and there is no information in the log that shows when or why it locks. (I will need to generate a new log to show this.) This happens with Openelec, Raspbmc, and Xbian Alpha 4.

However, if I go back to Xbian Alpha 3, the video plays to completion. For the test, I am using Rips of the Bluray Extended editions of LOTR: The Two Towers, and LOTR: Return of the King. Both these movies are around 4 hours in length... so I have not watched to see if I receive periodic buffering, I just let it play and walk away.. looking in every once in a while to see if it is still playing.

If I upgrade from Xbian Alpha 3 to Alpha 4... the lockups begin again.

Xbian Alpha 3 is using Kernel 3.6.7.... and it seems that any kernel newer than that causes my issue, including the custom RPi 3.6.y that is in Rbej's builds. Is it possible that someone can build me a custom build.. the same as Rbej's latest, but with the older 3.6.7 kernel? I would love to see if this would play the files to completion.
  • 1
  • 67
  • 68
  • 69(current)
  • 70
  • 71
  • 174

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