Kodi Community Forum

Full Version: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2015-02-24, 17:42)visata Wrote: [ -> ]I didn't like the slow channel switching on IPTV mpeg2 streams on 14.1 version, so I decided to give a try and test #0223 build. It works really fast!

The only issue I noticed that if deinterlacing was set to Auto or On, my IPTV streams were lagging, so I had to disable it. I have mpeg2 license and it is enabled.

Pi1 or Pi2? Is omxplayer enabled in video/acceleration settings?
It's Pi2. No, I didn't do enable anything. I will check omxplayer setting and report back later.
(2015-02-24, 13:54)popcornmix Wrote: [ -> ]Interesting. I've added to newclock4.

Have you pushed this commit, not seeing it yet in newclock4...
(2015-02-24, 19:37)Milhouse Wrote: [ -> ]Have you pushed this commit, not seeing it yet in newclock4...

Apparently not. Try now.
(2015-02-24, 12:15)OurJermain Wrote: [ -> ]Milhouse could you give a little more ram to the GUI for kodi gui on the RI2 build, it's smoother when you have lots of movies and tv shows, The gui shows the movies and tv pictures so it get choppy, if you don't have movies and tv-shows you will not see the choppyness.

What is your current gpu_mem setting, and what was it originally? If you want me to add "more" I need to know what you had to begin with, which might have been less than the current default (ie. from an old Pi1 config).

The default Pi2 gpu_mem (for fresh installs) is 256, and I only found it necessary to increase to 320 when using higher resolution imageres/fanartres with 1080 GUI and higher colour depth artwork. With the default artwork settings, 256 should be sufficient.
(2015-02-24, 19:42)popcornmix Wrote: [ -> ]Apparently not. Try now.

Thanks, I see it now - will include in tonight's build.
(2015-02-24, 14:15)charlieroot Wrote: [ -> ]Does this mean that there won't be support (in the future?) for USB /storage configurations?

No.

It just means that when a USB drive is being used for /Storage, it won't be possible to detect a broken SD or USB file system as the USB drive mounts too late leading resulting in fsck failure (because the drive is missing, so fsck bails before any file system is checked for errors). Consequently, forced fsck is impossible, due to the USB drive failure.

However, if you're using only the SD card for System and Storage then there will be no error and whenever a broken file system is detected, the forced fsck can be run.

See here for more details.
(2015-02-24, 15:40)evanspae Wrote: [ -> ]
(2015-02-20, 13:39)Milhouse Wrote: [ -> ]So #0213 is the last working build, or the first non-working build? Are you able to test on a Pi1, do you get the same crashes?

Just checked #0219 on RPI1 same issues activity icon goes slow then black screen and then reboots... same as on RPI2

Last working build seems to be r20266 ie #0213 on both Rpi platforms #02218,#0219,#0220,#0221,#0222 and #0223 not working

It's not at all obvious what changed in #0214 that could/would cause this to stop working... not sure why you jump to #0218 after #0213.
Quote:It's not at all obvious what changed in #0214 that could/would cause this to stop working... not sure why you jump to #0218 after #0213.

I didnt #0214 onwards.. all have same problem
(2015-02-24, 15:40)evanspae Wrote: [ -> ]logs here https://www.dropbox.com/sh/31t8upajt9zw1...5Pfja?dl=0

Looks to be a crash in argustv pvr addon.

Code:
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x75949df8 in std::string::clear() () from /usr/lib/libstdc++.so.6
#1  0x006d29d0 in BufferReader::ReadLine(std::string&) ()
#2  0x6bada424 in FileReader::OpenFile() () from /usr/lib/kodi/addons/pvr.argustv/Kodi_ArgusTV.pvr
#3  0x6badb248 in MultiFileReader::OpenFile() () from /usr/lib/kodi/addons/pvr.argustv/Kodi_ArgusTV.pvr
#4  0x6bae8944 in CTsReader::Open(char const*) () from /usr/lib/kodi/addons/pvr.argustv/Kodi_ArgusTV.pvr
#5  0x6baded94 in cPVRClientArgusTV::_OpenLiveStream(PVR_CHANNEL const&) () from /usr/lib/kodi/addons/pvr.argustv/Kodi_ArgusTV.pvr
#6  0x6badef34 in cPVRClientArgusTV::OpenLiveStream(PVR_CHANNEL const&) () from /usr/lib/kodi/addons/pvr.argustv/Kodi_ArgusTV.pvr
#7  0x0084e784 in PVR::CPVRClient::OpenStream(PVR::CPVRChannel const&, bool) ()
#8  0x0085351c in PVR::CPVRClients::OpenStream(PVR::CPVRChannel const&, bool) ()
#9  0x0060e5a0 in PVR::CPVRManager::OpenLiveStream(CFileItem const&) ()
#10 0x0053a560 in XFILE::CPVRFile::Open(CURL const&) ()
#11 0x0045cc44 in CDVDInputStreamPVRManager::Open(char const*, std::string const&) ()
#12 0x0087138c in CDVDPlayer::OpenInputStream() ()
#13 0x00871780 in CDVDPlayer::Process() ()
#14 0x009699e4 in CThread::Action() ()
#15 0x0096a250 in CThread::staticThread(void*) ()
#16 0x76d94d88 in ?? () from /lib/libpthread.so.0

Presumably in the update:
Quote:vdr: update to vdr-2.1.10 (f334d939)
vdr-addon: bump to 4.3.8 (3937ea56)
(2015-02-24, 20:46)evanspae Wrote: [ -> ]I didnt #0214 onwards.. all have same problem

Can you give step-by-step instructions on how to set this up (and hopefully reproduce the crash). Argus TV seems to have a Windows component, where is this and how does it need to be configured (does it need extra hardware, ie. tuners etc.?) I enabled the Argus TV PVR addon, but it kept on saying "Connection lost" and I saw nothing in Confluence that would allow me to access the Live TV (and, hopefully, crash).
(2015-02-24, 20:49)popcornmix Wrote: [ -> ]Presumably in the update:
Quote:vdr: update to vdr-2.1.10 (f334d939)
vdr-addon: bump to 4.3.8 (3937ea56)

Is Argus TV using the vdr addon? I thought they were separate addons, but I'm probably wrong.

I can revert the vdr/vdr-addon change for the next build.

Edit: Or maybe evanspae needs the updated 4.3.8 vdr-addon - if a dependency exists between vdr-addon and Argus TV, I can upload an updated vdr-addon shortly.
(2015-02-24, 13:54)popcornmix Wrote: [ -> ]Interesting. I've added to newclock4.
I agree, it looks like the #ifdef is a leftover. Can't see a reason why posix should behave differently.

I agree it could make UI or playback starting more responsive, at the expense of artwork showing up later.

Have a look at this and this which were other experiments in thread priorities. I've not had a lot of evidence as to whether they are beneficial.
Yep, I've seen both these commits and tried to test them, but unfortunately I wasn't able to see any noticeable difference. (That was on Pi 1.)

(Firmware issue on GitHub: today's firmware works here too.)

(2015-02-24, 19:42)popcornmix Wrote: [ -> ]
(2015-02-24, 19:37)Milhouse Wrote: [ -> ]Have you pushed this commit, not seeing it yet in newclock4...
Apparently not. Try now.
It seems previous push went to master: https://github.com/popcornmix/xbmc/compa...r...master - oops.

Edit: @popcornmix is the last commit supposed to fix monoscopic mode? In that case I'm going to build it with da-anda's patch.
Edit2: Yay! da-anda's PR + last commit fix the issue with "Play as 2D".
In case it has any bearing on Argus TV, I've uploaded vdr-addon-4.3.8: RPi / RPi2
(2015-02-24, 19:56)Milhouse Wrote: [ -> ]
(2015-02-24, 14:15)charlieroot Wrote: [ -> ]Does this mean that there won't be support (in the future?) for USB /storage configurations?

No.

It just means that when a USB drive is being used for /Storage, it won't be possible to detect a broken SD or USB file system as the USB drive mounts too late leading resulting in fsck failure (because the drive is missing, so fsck bails before any file system is checked for errors). Consequently, forced fsck is impossible, due to the USB drive failure.

However, if you're using only the SD card for System and Storage then there will be no error and whenever a broken file system is detected, the forced fsck can be run.

See here for more details.

What I meant was support for forced fsck checks on USB /storage setups. But if I understand your answer correctly, USB partition do not mount (or to slow) for fsck so support for (forced) fsck is not possible.