• 1
  • 25
  • 26
  • 27(current)
  • 28
  • 29
  • 174
OpenELEC Testbuilds for RaspberryPi
(2012-10-31, 18:14)fake666 Wrote:
(2012-10-31, 18:08)gimli Wrote: This is a decoder bug on the PI, which is worked on.

hi gimli, cool, glad to know i'm not the only one facing this, i was googling around for quite a while now.

for what it's worth, i found that omxplayer can play the tvheadend hd stream perfectly if i use the raspbian, and downgrade the firmare to https://github.com/raspberrypi/firmware/ hash 48f8bb0e470b7bf17fe812dc43860a0f45a6e4e2 of the official tree (just before they changed to vdec3), even with the newest omxplayer deb.

is there any thread/ticket i can follow regarding this? i'd be happy to help.

Nope, you just can wait and watch the RPI github.
[ 1597.768347] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped (times 50) Video stops playing and returns to home screen.
when playing HD movies via the youtube plugin version 12350 version 12026 is working ok (except for aspect ratio of pictures)
(2012-10-31, 18:19)dijkx Wrote: [ 1597.768347] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped (times 50) Video stops playing and returns to home screen.
when playing HD movies via the youtube plugin version 12350 version 12026 is working ok (except for aspect ratio of pictures)

This is a kernel problem and doesn't belong here. Report this on the RPI github.
(2012-10-28, 10:13)RiJo Wrote: If I start playback of an XviD file, the screen turns black and there's no sound.

just a note: my problems with XviD playback seems to be fixed in OpenELEC r12350 (xbmc-28ca9a4).
Hi everyone, I'm new on this OpenELEC for Raspberry and I'd like to know, is it possible to set output resolution to 1024x768 ? I'd like to use this baby with a led projector and native resolution is that one, so, is it possible ?

Thanks.
(2012-10-31, 19:48)Mopheus Wrote: Hi everyone, I'm new on this OpenELEC for Raspberry and I'd like to know, is it possible to set output resolution to 1024x768 ? I'd like to use this baby with a led projector and native resolution is that one, so, is it possible ?

Thanks.

force it in config.txt check the options for that here http://elinux.org/RPi_config.txt
R12349 and some keyboard shortcuts seem to have gone missing. "M" no longer brings up the playback controls and "I" doesn't bring up the info on selected item. May well be others that I don't know about.
Updated from r12282 to r12350. Blurry picture appears randomly, even when displaying single picture repetitively (beginning of the xbmc.log and SAM_5587.JPG). I noticed that when the picture is displayed incorrectly it takes much less time than when it's displayed correctly (approx.1-2s when blurry vs. 4-8s when good).

Also XBMC freezed after about 25 minutes while playing mp3 and picture slideshow on top of it.

http://sprunge.us/LWWC - xbmc.log 1st part
http://sprunge.us/UbbY - xbmc.log 2nd part
http://sprunge.us/DgRP - vcdbg reloc
http://forum.xbmc.org/showthread.php?tid...pid1214417 - blurry pictures described before

@popcornmix: it's actually the same jpg I used in the previous tests
I just installed the latest image to a 4gb sd card, but raspberry pi is freezing when i try to access the windows 8 SMB folder (installing add-ons, playing movies). This is happening very often and it does not unfreeze at all, i just have to turn it off and on again. I am using the 512mb version. Here is the xbmc.log:
http://pastebin.com/64zf06v4

(2012-10-30, 13:57)popcornmix Wrote:
(2012-10-30, 04:15)MilhouseVH Wrote: I really do wish you guys would re-consider this 720/1080p GUI upscaling fix, or at least include the option for it to be disabled rather than rely on custom builds.
Once the encoding/decoding of images is completely solid, we'll reconsider.
Currently:
1) There are bugs that cause decode errors
2) There are use cases that cause decode errors due to lack of RAM (e.g. fanart wall views)
3) Running at 1080p means even more use cases will cause decode errors due to lack of RAM

We want good bug reports to help fix (1) first. Then we can improve (2). Finally we can consider (3).
It's no good when most of the bug reports are from (3), and the useful (1) reports are lost in the noise.

OK that sounds fair enough, in which case I'll restrict my testing and bug reporting to the official 720p builds in order to assist with debugging.
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.
Hi
I have a Raspberry Pi with loaded with r12350.

I am trying to stream images, videos and music from my Windows 7 PC to XBMC via uPnP/DLNA. XBMC appears in the browse list, and I can choose XBMC to stream to. The stream is also initiated, but nothing appears on the screen.

I then had a look in .xbmc/temp/xbmc.log. In there, there was this line that puzzles me. It references to an IP address that is unknown to me (169.254.92.194), as I use the 192.168.1.x segment. There are several references to that IP adress. Can that be the reason why the streaming does not work? Is it a bug?

09:34:13 T:2953790560 ERROR: COMXImage::ReadFile http://169.254.92.194:10243/WMPNSSv4/251...0uMC5C.jpg not found

Regards
Lemme
169.254.92.194 I think loop back address, it is not getting IP properly from DHCP. Check that or try static IP.

I use SMB to get shares from a windows 7 machine, maybe try that way.

---------------------
I was wondering which of my R-Pi's would be the superior OpenELEC XBMC machine.

R-Pi A - 256mb
arm_freq=900
sdram_freq=450
core_freq=350

R-Pi B - 512mb
gpu_mem=256
arm_freq=900
sdram_freq=450

Basically one is a 512MB board but core_freq must run at stock AND the 256MB can overclock core_freq to 350. (but obviously less memory)

I am leaning towards the one with the faster gpu core speed, I would imagine this to be an advantage for video playback and such. The 512MB board, it just seems to have more memory free.
when overclocking the arm_freq is the most important thing, the other options don't have a high impact in performance. the GPU seems to handle everything fine (as long it has enough ram available for it...) . on the other hand you will notice that setting a higher CPU, will yield a better response feedback from the system due to the cpu being faster processing data when entering libraries menus, on online addons fetching and parsing data is way quicker as well.

for the 512 MB having some extra ram for caching also helps improving networking performance and allowing more background services
PROBLEM SOLVED:
It turned out that it was my Windows installation causing trouble. I tried to stream from another Windows 7 PC, and it went well. It turned out that it was my VirtualBox network stack causing trouble. I ran an "ipconfig /all" and found the IP adress associated with VirtualBox. I do not know how to fix it, but it is not XBMC related.


************************
Hi Wanderlei
It sounds strange if it is a loop back adress, can anyone confirm this?
I tried with a static IP adress, but no luck, the Pi does not recieve the stream.

Do anyone have a similar problem?

/Lemme


(2012-11-03, 18:45)Wanderlei Wrote: 169.254.92.194 I think loop back address, it is not getting IP properly from DHCP. Check that or try static IP.

I use SMB to get shares from a windows 7 machine, maybe try that way.

---------------------
I was wondering which of my R-Pi's would be the superior OpenELEC XBMC machine.

R-Pi A - 256mb
arm_freq=900
sdram_freq=450
core_freq=350

R-Pi B - 512mb
gpu_mem=256
arm_freq=900
sdram_freq=450

Basically one is a 512MB board but core_freq must run at stock AND the 256MB can overclock core_freq to 350. (but obviously less memory)

I am leaning towards the one with the faster gpu core speed, I would imagine this to be an advantage for video playback and such. The 512MB board, it just seems to have more memory free.

(2012-11-03, 22:48)Lemme Wrote: PROBLEM SOLVED:
It turned out that it was my Windows installation causing trouble. I tried to stream from another Windows 7 PC, and it went well. It turned out that it was my VirtualBox network stack causing trouble. I ran an "ipconfig /all" and found the IP adress associated with VirtualBox. I do not know how to fix it, but it is not XBMC related.


************************
Hi Wanderlei
It sounds strange if it is a loop back adress, can anyone confirm this?
I tried with a static IP adress, but no luck, the Pi does not recieve the stream.

Do anyone have a similar problem?

/Lemme


(2012-11-03, 18:45)Wanderlei Wrote: 169.254.92.194 I think loop back address, it is not getting IP properly from DHCP. Check that or try static IP.

I use SMB to get shares from a windows 7 machine, maybe try that way.

---------------------
I was wondering which of my R-Pi's would be the superior OpenELEC XBMC machine.

R-Pi A - 256mb
arm_freq=900
sdram_freq=450
core_freq=350

R-Pi B - 512mb
gpu_mem=256
arm_freq=900
sdram_freq=450

Basically one is a 512MB board but core_freq must run at stock AND the 256MB can overclock core_freq to 350. (but obviously less memory)

I am leaning towards the one with the faster gpu core speed, I would imagine this to be an advantage for video playback and such. The 512MB board, it just seems to have more memory free.

Anything 169.254.x.x is an APIPA address ... which stands for Automatic Private IP Addressing.

You will receive these addresses when you DHCP client cannot get an ip address from a DHCP server.
Your "loopback" address is generally 127.0.0.1

In Virtualbox, check your virtual machine's network settings... if you want it to recieve a 192.168.1.x address, you may need to set the network adapter to a "bridged network".
  • 1
  • 25
  • 26
  • 27(current)
  • 28
  • 29
  • 174

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