[Milhouse]

I can play the YouTube url. I am getting quite a lot of buffering so that may affect things.
So far I've had no issues stopping playback with omxplayer enabled.
I have seen high cpu when omxplayer was disabled, and that did take a while to stop.
I'll see if I can find why that happened, but I'm not sure that's your issue.

I see the same with OpenELEC build #0330. Network connection is wired with 20Mbps internet downstream, testing the stream which artoo used in his last post (details below).

With omxplayer, the video is smooth and there is no delay when stopping.

With dvdplayer, playback starts OK but then begins to stutter during the first 30 seconds, and remains very choppy throughout. Leave it to play like this for a few minutes - CPU loads around 5% on each core - and then suddenly the CPU load on one core will become pegged at 100%. Playback continues, but stopping the video will hang the GUI, requiring a kodi.bin restart.

bcmstatsh.sh showing CPU load during playback: http://pastebin.com/raw.php?i=qppUMfxT - the CPU starts becoming erratic at 01:41:06, playback stopped at 01:42:42.
dvdplayer debug log (covering just the last few minutes, including the period when CPU load increases): http://xbmclogs.com/pmijyzhui

This is how I'm playing the latest stream: http://pastebin.com/raw.php?i=biacCTXS (it's one long line, which the forum software will mangle)

As you say, might be unrelated, but this might also give you an easier way to test if nothing else.

Edit: There's a new commit on the newclock4 branch that fixes the high CPU with dvdplayer, although choppy playback (skipped frames) remains a problem.

[da-anda]

edit: nvm

You mean non volatile memory ?

mmm not sure what you mean by nvm

nvm = never mind
I had written a post of which I found out a couple mins later that it was superfluos, so I emptied it. But popcornmix quoted my initial post anyways.

[artoo]

I can play the YouTube url. I am getting quite a lot of buffering so that may affect things.
So far I've had no issues stopping playback with omxplayer enabled.
I have seen high cpu when omxplayer was disabled, and that did take a while to stop.
I'll see if I can find why that happened, but I'm not sure that's your issue.

I see the same with OpenELEC build #0330. Network connection is wired with 20Mbps internet downstream, testing the stream which artoo used in his last post (details below).

With omxplayer, the video is smooth and there is no delay when stopping.

With dvdplayer, playback starts OK but then begins to stutter during the first 30 seconds, and remains very choppy throughout. Leave it to play like this for a few minutes - CPU loads around 5% on each core - and then suddenly the CPU load on one core will become pegged at 100%. Playback continues, but stopping the video will hang the GUI, requiring a kodi.bin restart.

bcmstatsh.sh showing CPU load during playback: http://pastebin.com/raw.php?i=qppUMfxT - the CPU starts becoming erratic at 01:41:06, playback stopped at 01:42:42.
dvdplayer debug log (covering just the last few minutes, including the period when CPU load increases): http://xbmclogs.com/pmijyzhui

This is how I'm playing the latest stream: http://pastebin.com/raw.php?i=biacCTXS (it's one long line, which the forum software will mangle)

As you say, might be unrelated, but this might also give you an easier way to test if nothing else.

Edit: There's a new commit on the newclock4 branch that fixes the high CPU with dvdplayer, although choppy playback (skipped frames) remains a problem.

First of all:

great tools. I love bcmstat.sh

however, I am having some troubles with texturecache.py. See output here http://pastebin.com/rnhiCQV5

anything silly I have missed?

Ill paste my bcmstat log as soon as I will be able to reproduce your conditions.

[Milhouse]

First of all:

great tools. I love bcmstat.sh

however, I am having some troubles with texturecache.py. See output here http://pastebin.com/rnhiCQV5

anything silly I have missed?

Ill paste my bcmstat log as soon as I will be able to reproduce your conditions.

No, unfortunately the googlevideo.com url expires fairly regularly in which case you get that error once it has expired. The url you were using (and I referenced in my post) expired "Tue Mar 31 05:15:38 BST 2015" (in Linux, "date --date=@1427775338", using the expires parameter from the url).

You'll need to get another url for the same video. One way to do this is by visiting the youtube page (https://youtu.be/rs4zHvC54wo) in a browser (eg. Firefox), clicking on download, then right clicking MP4 which should allow you to copy the new googlevideo.com url to your clipboard, then use that url with texturecache.py (until it too expires...).

Or use whatever method you've been using up until now to watch it - I only recommend using texturecache.py to play random internet streams as it often means it's not necessary to install an add-on that will never be used again (or that may also install a ton of other stuff which might cause longer term problems).

[popcornmix]

You'll need to get another url for the same video. One way to do this is by visiting the youtube page (https://youtu.be/rs4zHvC54wo) in a browser (eg. Firefox), clicking on download, then right clicking MP4 which should allow you to copy the new googlevideo.com url to your clipboard, then use that url with texturecache.py (until it too expires...).

Not sure Youtube/firefox has a download button by default. Do you have a downloader add-on installed?

[Milhouse]

Oh drat, that's entirely possible yes - I now remember installing a Firefox YouTube download extension a few years ago, but had totally forgotten about it and just assumed the download menu was part of the standard YouTube browser UI...

There's a new googlevideo.com url here: http://pastebin.com/raw.php?i=JEqDqtr2

It will expire: Wed Apr 1 20:02:35 BST 2015 (each url lasts for 6 hours).

[artoo]

from Milhouse

No, unfortunately the googlevideo.com url expires fairly regularly in which case you get that error once it has expired. The url you were using (and I referenced in my post) expired "Tue Mar 31 05:15:38 BST 2015" (in Linux, "date --date=@1427775338", using the expires parameter from the url).

cool.

From popcornmix

Not sure Youtube/firefox has a download button by default. Do you have a downloader add-on installed?

No prob, popcornmix, I find my ways

Same video. same system as the previous tests.

This is the output of bcmstat.sh: http://pastebin.com/vL8f9tzw

I cannot say much about how the video played as I have done this test over ssh. Maybe my neighbour but we shall never know. I can tray again later on tonight or tomorrow evening.

[Milhouse]

As useful as bcmstat.sh is, its output becomes a lot more readable if you make your window wider so that the lines don't wrap.

[artoo]

As useful as bcmstat.sh is, its output becomes a lot more readable if you make your window wider so that the lines don't wrap.

yeah sorry about that:

http://pastebin.com/raw.php?i=vL8f9tzw

I guess I have added too many options to bcmstat -- I think you can just reduce the font size in firefox of the RAW .. if you haven't done it already

[Milhouse]

My bad, I'm currently viewing this on an Android tablet and Chrome automatically wraps the raw lines (no way to stop it, grrrr). If I copy & paste the text into QuickEdit it looks fine.

Anyway, it looks like you're still getting 100% CPU... if you test with the latest #0331 test build that problem should be fixed now.

[artoo]

I am not on OpenELEC, but on Raspbian. However, you put a bee in my bonnet so I had a look in meme repo and I have noticed there's a 14.2 in unstable so I wanted to give it a go.

(please feel free to say that it was bad idea and I will roll back)

So, just to clarify:

pi@PiServer $ uname -a
Linux PiServer 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux

pi@PiServer $ lsb_release
No LSB modules are available.

pi@PiServer $ sudo vcdbg log msg 2>&1 | grep DTOK
001067.290: Kernel trailer DTOK property says yes

pi@PiServer $ vcgencmd version
Feb 14 2015 22:23:03
Copyright © 2012 Broadcom
version 7789db485409720b0e523a3d6b86b12ed56fd152 (clean) (release)

pi@PiServer $ kodi --version
14.2-RC1 Git:e7ba06f Media Center Kodi
Copyright © 2005-2013 Team Kodi - http://kodi.tv

pi@PiServer $ sudo cat /etc/apt/sources.list
deb http://archive.raspbian.org/raspbian/ wheezy main contrib non-free
deb-src http://archive.raspbian.org/raspbian/ wheezy main contrib non-free

deb http://archive.mene.za.net/raspbian wheezy contrib unstable

------------------------------------

retest after kodi update to

14.2-RC1 Git:e7ba06f Media Center Kodi
Copyright © 2005-2013 Team Kodi - http://kodi.tv

100% CPU issue seemed fine with this one -- http://pastebin.com/raw.php?i=NYz6sTMx

I will be able to say more about smoothness of play and whether the "stop" issue is resolved when I get home.

[Milhouse]

The fix for 100% CPU isn't in that 3 week old build (only added to newclock4 yesterday), so you may need to test again for it to show itself.

[artoo]

The fix for 100% CPU isn't in that 3 week old build (only added to newclock4 yesterday), so you may need to test again for it to show itself.

Your were right milhouse, in fact still hangs with the unstable built in http://michael.gorven.za.net/ same issues same spikes.

There is no other more recent build for raspbian in there. I could compile one from source through your git [git://github.com/xbmc/xbmc.git] if that is that is what you indirectly meant by suggesting me to use openelec build #0330 or #0331.

[Milhouse]

Yes, in the absence of a Raspbian "nightly" you'll need to compile your own in order to test fixes like this.

[artoo]

Lazy artoo. I did not compile and I have just waited for a few days for the update in the http://michael.gorven.za.net/

System and kovi status:

Raspberry pi 2

pi@PiServer ~/.kodi/temp $ uname -a
Linux PiServer 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux

pi@PiServer ~/.kodi/temp $ lsb_release
No LSB modules are available.

pi@PiServer ~/.kodi/temp $ sudo vcdbg log msg 2>&1 |grep DTOK
001274.573: Kernel trailer DTOK property says yes

pi@PiServer ~/.kodi/temp $ vcgencmd version
Feb 14 2015 22:23:03
Copyright © 2012 Broadcom
version 7789db485409720b0e523a3d6b86b12ed56fd152 (clean) (release)

pi@PiServer ~/.kodi/temp $ kodi --version
14.2 Git:7cc53a9 Media Center Kodi
Copyright © 2005-2013 Team Kodi - http://kodi.tv

Kodi (14.2 Git:7cc53a9). Platform: Linux ARM 32-bit - Using Release Kodi x32 build (version for Raspberry Pi)

Kodi compiled Mar 29 2015 by GCC 4.6.3 for Linux ARM 32-bit version 3.2.51 (197171)
I am using the deb package installed from http://michael.gorven.za.net/ repo

Same system setup as before - just updating.

Same issues - Video (720) plays fine then I press stop on the remote at 12:06:39 and video hangs. You can see a clear 100% spike on cpu3 (see bcmstat) that starts at 12:06:41 and keeps going.

Kodi is frozen, so I gave "killall kodi.bin" to restart the media center.

Here is the link to the video http://pastebin.com/raw.php?i=6kPRHU2k [./texturecache.py playw "videolink"]

Here is kodi.log http://pastebin.com/raw.php?i=ptrAWAYa

here is bcmstat http://pastebin.com/raw.php?i=Nmn3yKUR [edited wrong link]

I am sure there will be a more recent build in openElec than mine (29th march). If so, can you say whether this is replicable on your end?

artoo