• 1
  • 254
  • 255
  • 256(current)
  • 257
  • 258
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
(2014-03-31, 16:35)popcornmix Wrote:
(2014-03-30, 09:29)MrNice Wrote: Every time I open System>system>video output, I get the message "Save resolution. Would you like to keep this change"

Any change with latest build?
Bravo popcornmix this bug is fixed!

Audio issue are the same see my Post: #3798
Config, video/audio player:
3T HDD <USB> Odroid N2+ / CoreElec <HDMI> Denon AVR-2313 <HDMI> LG TV 55UF860V
                                          <nfs wired> Linksys WRT32X router <USB> 4T HDD
(2014-03-31, 18:50)Forage Wrote: Am I the only one who still has the network connection (wired) dropping randomly? It happens on MilouseVH's builds, as well as with OE 4beta3. They still occur, during playback, as well as while not using the RPi.

Same happening here. I have three pi's running openelec, latest Millhouse builds. The two on WLAN don't drop off the network ever, the wired one does! I thought it was my own network but rebooted everything and it's still happening.

Debugging is on now so hopefully I'll get a meaningful log.
(2014-03-31, 21:20)Irisheyes Wrote:
(2014-03-31, 18:50)Forage Wrote: Am I the only one who still has the network connection (wired) dropping randomly? It happens on MilouseVH's builds, as well as with OE 4beta3. They still occur, during playback, as well as while not using the RPi.

Same happening here. I have three pi's running openelec, latest Millhouse builds. The two on WLAN don't drop off the network ever, the wired one does! I thought it was my own network but rebooted everything and it's still happening.

It seems to be a problem with fiq fsm patch. Add "dwc_otg.fiq_enable=0" at end of cmdline.txt.
@popcornmix: Did you miss my previous post or you didn't have the time to check it?

Thanks in advance for any reply.
(2014-03-31, 21:49)pplucky Wrote: @popcornmix: Did you miss my previous post or you didn't have the time to check it?

Thanks in advance for any reply.

I believe it's the same bug as the post I linked to. I'm waiting for a fix from the author.
You could try OpenElec Gotham beta 3 which shouldn't have that bug in.
(2014-03-31, 21:54)popcornmix Wrote:
(2014-03-31, 21:49)pplucky Wrote: @popcornmix: Did you miss my previous post or you didn't have the time to check it?

Thanks in advance for any reply.

I believe it's the same bug as the post I linked to. I'm waiting for a fix from the author.
You could try OpenElec Gotham beta 3 which shouldn't have that bug in.

OK, thanks for the update and for following it up. I will anyway try OE beta3 and report back.
(2014-03-31, 21:24)popcornmix Wrote:
(2014-03-31, 21:20)Irisheyes Wrote:
(2014-03-31, 18:50)Forage Wrote: Am I the only one who still has the network connection (wired) dropping randomly? It happens on MilouseVH's builds, as well as with OE 4beta3. They still occur, during playback, as well as while not using the RPi.

Same happening here. I have three pi's running openelec, latest Millhouse builds. The two on WLAN don't drop off the network ever, the wired one does! I thought it was my own network but rebooted everything and it's still happening.

It seems to be a problem with fiq fsm patch. Add "dwc_otg.fiq_enable=0" at end of cmdline.txt.

Thanks popcorn mix, I'll do that and report back.

EDIT: So far so good...
(2014-03-31, 21:20)Irisheyes Wrote:
(2014-03-31, 18:50)Forage Wrote: Am I the only one who still has the network connection (wired) dropping randomly? It happens on MilouseVH's builds, as well as with OE 4beta3. They still occur, during playback, as well as while not using the RPi.

Same happening here. I have three pi's running openelec, latest Millhouse builds. The two on WLAN don't drop off the network ever, the wired one does! I thought it was my own network but rebooted everything and it's still happening.

Debugging is on now so hopefully I'll get a meaningful log.

I also get the same problem running on a wired network. I've just tried a complete reinstall and still the same problem. In openelec network settings the network connection disappears after about 2 minutes however I can still access the web. I can't however SSH in to the pi or see any files on my ubuntu mysql server. I'm a bit over rushed at the moment so will be interest if anyone has success by moving to beta 3. To be honest when these builds work, they're great so I'd rather not move backwards.
After some hours, my wlan stop working and doesn't show any networks available. Turning off and on again in OE settings solve this issue for another few hours.

"dwc_otg.fiq_enable=0" with this..

Any idea?
Hi all,

before we release our beta 4 soon, we need help to test the just updated kernel (3.14) which are included in this builds:
http://snapshots.openelec.tv/OpenELEC-RP...b1b.img.gz (Diskimage)
http://snapshots.openelec.tv/OpenELEC-RP...9f1b1b.tar (tarball)

please report back any issue kernel (driver) related (best compare with this builds (kernel 3.13):
http://snapshots.openelec.tv/OpenELEC-RP...47f.img.gz (Diskimage)
http://snapshots.openelec.tv/OpenELEC-RP...f4d47f.tar (tarball)

(there should not be any changes except the kernel update between the both)

Note: this builds contains not the newest patches from popcornmix, instead a almost vanilla XBMC Gotham Beta 3/4 is used with only a few backports.

Thanks much
greetings, Stephan

Image

Image
(2014-03-31, 17:29)MilhouseVH Wrote: Watch (using either omxplayer or dvdplayer) until about 03:00 and stop, then try playing again with dvdplayer this time resuming from 03:00 - it will be very slow to resume but should eventually give you just TrueHD audio and no video. Stop and resume using omxplayer and you'll have both video and TrueHD audio. I can also reproduce this behaviour with the AC3 track (you need to switch audio tracks when starting from beginning).

I'm not sure if this is the same with the original (larger than 500MB) file, but this file has a broken index which means seeking doesn't work (even with xbmc on windows).
When (on Windows) you resume from 3 minutes, it does start, but quite slowly. I think because seeking doesn't work, it is actually reading the 3 minutes worth of frames and discarding them.

On a PC that is feasible. On the Pi, that might be very slow.

Does seeking work with the full length file?
[quote='Stilt' pid='1668369' dateline='1396254530']
[quote='MilhouseVH' pid='1667894' dateline='1396210327']
New OpenELEC Gotham build: #0330
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.13.7 #1 PREEMPT Sun Mar 30 20:44:22 BST 2014 armv6l GNU/Linux

# vcgencmd version
Mar 30 2014 15:59:18
Copyright (c) 2012 Broadcom
version 8f13fa508997a043a3d78822e3f67ec044b4e7bf (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140330204313-r18050-g2d44624


========================================================================
Ok, Did a complete new install:
1) Installed Gotham OpenELEC Beta - Raspberry Pi ARM Version:3.95.3
2) Samba copied Gotham build: #0330 .tar to Upgrade
3) Rebooted,
4)after reboot Gotham logo disappeared (Frodo Logo now) and tar file got extracted looks like update worked.
5)Still Audio only one channel
6)Log: http://sprunge.us/MAIY
=================================
OpenELEC:~ # uname -a
Linux OpenELEC 3.13.7 #1 PREEMPT Sun Mar 30 20:44:22 BST 2014 armv6l GNU/Linux
OpenELEC:~ # vcgencmd version
Mar 30 2014 15:59:18
Copyright © 2012 Broadcom
version 8f13fa508997a043a3d78822e3f67ec044b4e7bf (clean) (release)
OpenELEC:~ #
OpenELEC:~ # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
OpenELEC:~ #
============================================================
Can anybody post a working USB DAC stereo log - only the "Enumerated ALSA devices:" section ?
(2014-04-01, 00:52)sraue Wrote: Hi all,

before we release our beta 4 soon, we need help to test the just updated kernel (3.14) which are included in this builds:
http://snapshots.openelec.tv/OpenELEC-RP...b1b.img.gz (Diskimage)
http://snapshots.openelec.tv/OpenELEC-RP...9f1b1b.tar (tarball)

please report back any issue kernel (driver) related (best compare with this builds (kernel 3.13):
http://snapshots.openelec.tv/OpenELEC-RP...47f.img.gz (Diskimage)
http://snapshots.openelec.tv/OpenELEC-RP...f4d47f.tar (tarball)

(there should not be any changes except the kernel update between the both)

Note: this builds contains not the newest patches from popcornmix, instead a almost vanilla XBMC Gotham Beta 3/4 is used with only a few backports.

Thanks much

With 3.95.1, 3.95.2 & 3.95.3, and all Millhouse builds (since 3/15, didn't try earlier), my Wi-Fi would mysteriously go up and down. As long as the slideshow screensaver wasn't running, I could "restart" the network about 50% of the time and get to it via SSH or Samba. I was running into "FIQ NYET" messages depending on FIQ configuration. Other times, I can see the WiFi reconnect multiple times via "dmesg" when I could get SSH to work. Sometimes, dmesg would be littered with "TX status timeouts." All during those times, video seemed to play OK. But once the slideshow screensaver started, it would cause the Samba and SSH connections to disconnect and not be found.

After many hours this past weekend, I settled on going to the OE Config Manager and looking at the connections refresh. What would happen is that during the refresh, the config would sometimes lose ALL the other 2.4GHz network listings except for the 5GHz connection. Whenever I could coax all the networks to appear on that screen, SSH and Samba would start working again.

Kernel 3.14 solved almost all my rPi intermitent network issues--at least that I can see in the last few hours. SSH and Samba connections are stable once again (staying connected) like it was with 3.2.4 and rBej builds. Curiously, I got only about two dozen TX status timeouts over the couple of hours. Normally, there would literally be hundreds and hundreds. Here's what the messages look like:

Code:
[ 5258.001742] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.002981] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.004252] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.005515] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.006760] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2


I'm now going to test kernel 3.13 for comparison...
(2014-04-01, 02:16)popcornmix Wrote: I'm not sure if this is the same with the original (larger than 500MB) file, but this file has a broken index which means seeking doesn't work (even with xbmc on windows).
When (on Windows) you resume from 3 minutes, it does start, but quite slowly. I think because seeking doesn't work, it is actually reading the 3 minutes worth of frames and discarding them.

On a PC that is feasible. On the Pi, that might be very slow.

Does seeking work with the full length file?

Yes I can seek in the full-size movie, but only with omxplayer (where resuming also works fine).

With dvdplayer, when starting from beginning (so that I have video) seeking will result in a static/frozen image with the audio continuing from the point that I have seeked to (which is probably similar to the resuming problem, where you get the audio but no video). So yes seeking kind of works, but only for audio and not video. I can't actually reproduce this behaviour with the 500MB sample, however, as seeking with dvdplayer will work (sort of, it doesn't freeze the video anyway, and only sometimes seeks forwards) - maybe the shorter index (or broken index) is an advantage here. Hmm.

Maybe it's just a duff rip? If so, please don't bother spending any more time on this!
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.
(2014-03-31, 16:21)popcornmix Wrote: It is likely there will be a change to the default scaling kernel soon as 0.14 does seem preferred (it was my favourite too).
Ideally we should stretch the shape of the kernel with the scaling ratio.

These were the kernels:

0.00 Sinc over the range +-3*PI with Hamming window applied,
0.02 Sinc with Hamming window applied,
0.04 Sinc over the range +-2.5*PI with Hamming window applied,
0.06 Sinc,
0.08 Sinc with Blackmann window applied,
0.10 Sinc with no side lobes,
0.12 Sinc with half the first side lobe
0.14 Mitchell Netravali (with B=1/3,C=1/3)
0.16 nearest_neighbour,

Here's another suggested by the image scaling guy (you can just enter that while video is playing):
Code:
vcgencmd scaling_kernel   0  -4  -8 -14 -18 -19 -16  -8   9  39  77 122 166 206 237 255 255 237 206 166 122  77  39   9  -8 -16 -19 -18 -14  -8  -4   0
It's a cubic with A=-0.5.

To my eyes (TV sharpness at zero), 0.08 exaggerated compression artifacts more than 0.14. My preference is for 0.14. Although I would be really curious about comparing it to Lanzcos3.
  • 1
  • 254
  • 255
  • 256(current)
  • 257
  • 258
  • 277

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