Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 156
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
#16
Still same result with stereoscopic files now files with black bars are also shown monoscopic (left frame fills entire screen) plus as written the tv doesn't get the switch to 3D signal either. Ie. worse than last build I'm afraid. May I ask why switch to 3D mode was reverted it worked fine?

Thanks Smile

Edit: fps is also reported wrong in codec info I get 250.000 fps on a irregular 31-32 fps stream.
Edit edit: this happens with "ol'" 0411b to I just never noticed. This might just be a fluke in the stream as I can't find other "bad" stream. All standard fps reports just fine.
#17
Subscribing for updates.
#18
(2014-04-16, 10:35)tuxen Wrote: May I ask why switch to 3D mode was reverted it worked fine?

Problem is it didn't work fine. It stopped the ability to watch video as mono and had some other side effects.
(see https://github.com/xbmc/xbmc/pull/3072 which has been stalled for 8 months for some reasons why this scheme is not correct).

This was the problem with my testing. I tested on a 2D TV at work, and got everything behaving the same as xbmc on windows.
But on the 2D TV, the auto switching patch was disabled so I didn't see the problem. At home with a 3D capable TV I found I couldn't enable explicit 3D view modes
(like off/mono/SBS/TAB).

It's not the only issue. It seems when TV can support 3D some of the scaling rectangles I get given are different by a factor of two, but I need to understand that more.

But for now I think automatic 3D switching as is currently implemented needs to be removed.
xbmc needs to handle all the 3D and scaling modes on the Pi like it does on the PC.
Then a new scheme for 3D switching needs to be added that doesn't break existing behaviour.
#19
Ah yeah I see the problem especially if watching/testing in mono.
Thanks for your kind explanation popcornmix, your answers are very informative. I really appreciate that. Smile and I hope the commit(s) starts going again.

Once again thank you guys and the rest of the openELEC team for what you do to optimize/stabilize XBMC on RPi, and prove that you do not need a powerhouse if things are coded properly.
#20
@popcornmix - using 0415b 3D was working initially (both eyes showed up), but after I started to browse the GUI and have the video run in the background the right eye vanished at some point and didn't come back. Maybe a GPU memory issue? What's the recommended GPU mem for a 512MB Model? IIRC I have it set to 128MB atm - should i double that and test again?

Btw - I also noticed the issues with the resolution switch, where the 1080pSBS resolution even prevented a switch to TAB mode. Had to change the resolution to 1080pTAB in order to get GUI TAB mode applied and video converted to TAB. So I also think it might be best for now to disable the experimental resolution switch commit until we refactored that part.
#21
Popcornmix.

I have compile error with latest newclock 3, firmware and Xbmc Gotham branch.

http://pastebin.com/JnSx8F1B



#22
(2014-04-16, 13:48)da-anda Wrote: @popcornmix - using 0415b 3D was working initially (both eyes showed up), but after I started to browse the GUI and have the video run in the background the right eye vanished at some point and didn't come back. Maybe a GPU memory issue? What's the recommended GPU mem for a 512MB Model? IIRC I have it set to 128MB atm - should i double that and test again?

You can try doubling it, but I suspect the behaviour will be the same.

The real problem is the rectangles passed to RenderUpdateCallBack don't make a lot of sense.
Typically with SBS video in SBS display mode the SrcRect is the whole video, and the DstRect is the left half of the screen.

I'm currently halving the SrcRect (but not the DstRect) to get something consistent, but I think that is not always the case, hence it started working, but then stopped when you adjusted something in OSD. Feels like an xbmc bug outside of omxplayer, but all I currently know is that it makes no sense, and it's not consistent....
#23
I have a problem when playing HD channel streamed from tvheadend. It plays but often goes to black screen and then plays again normaly, it does this about every 10secs and it eventually freezes! I have raspberry 512K board overclocked to 1000mhz, I've tried without overclock and does same thing. It works fine streaming to windows xbmc, no stutter on same HD channel so it has something to do with raspberry pi build!

thanks
Joe
#24
(2014-04-16, 14:40)rbej Wrote: Popcornmix.

I have compile error with latest newclock 3, firmware and Xbmc Gotham branch.

http://pastebin.com/JnSx8F1B

Needs firmware update to get updated /opt/vc/include header file.
#25
It may be a stupid question but... If I do a fresh install of MillhouseVH's build, does it include a newest firmware as listed in the changelog? Or do I have to update manually?
#26
(2014-04-16, 16:52)luksol Wrote: It may be a stupid question but... If I do a fresh install of MillhouseVH's build, does it include a newest firmware as listed in the changelog? Or do I have to update manually?

It will update automatically.
#27
On my side I now can switch between stereoscopic modes, and the gui corresponds correctly to this, but as mentioned there's only one side rendered, and that covers the entire screen.
#28
(2014-04-16, 01:36)Mafarricos Wrote:
(2014-04-15, 23:21)Mafarricos Wrote:
(2014-04-15, 23:08)MilhouseVH Wrote: Yes

Ok, will test it. With my WiFi dongle and keyboard dongle in previous I had to disable. Let's see if new kernel solves this for me.

It seems that videos dont freeze to me.
Good work!

Unfortunately, for me #0415b with the FIQ FSM patch still hangs randomly on videos when I have a USB wireless mouse dongle plugged in
#29
(2014-04-16, 18:04)edwr Wrote: Unfortunately, for me #0415b with the FIQ FSM patch still hangs randomly on videos when I have a USB wireless mouse dongle plugged in

How long between crashes? Does "dwc_otg.fiq_fsm_enable=0" make it reliable?
#30
(2014-04-16, 18:33)popcornmix Wrote:
(2014-04-16, 18:04)edwr Wrote: Unfortunately, for me #0415b with the FIQ FSM patch still hangs randomly on videos when I have a USB wireless mouse dongle plugged in

How long between crashes? Does "dwc_otg.fiq_fsm_enable=0" make it reliable?

It's pretty random - sometimes twenty minutes in, sometimes two hours. Playing a two hour movie will usually guarantee a hang at some point. The pi will otherwise be stable in the menu 24/7 as far as I can tell.

Adding that does seem to fix it, at least
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 156

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)8