Login at Kodi Home

DDDamian · 2012-03-22, 21:29

Log level is fine. But you say if you move script.common.plugin.cache out of the addons directory your CPU usage is low, with it there it's high? In that case we need the log with it enabled and in the addons directory so it's active. Gotta reproduce the fault if anyone's going to find the answer.

We still can't see a full log with all the clutter. Are these legitimate directories? If you pick one and follow the path does it exist? Or have they been moved/renamed/deleted.

ericab · (This post was last modified: 2012-03-22, 21:48 by ericab.)

"But you say if you move script.common.plugin.cache out of the addons directory your CPU usage is low, with it there it's high?"

yes exactly

"In that case we need the log with it enabled and in the addons directory so it's active. Gotta reproduce the fault if anyone's going to find the answer."

it has *always* been in the addons directory, and enabled with the logs im showing

"We still can't see a full log with all the clutter. Are these legitimate directories? If you pick one and follow the path does it exist? Or have they been moved/renamed/deleted. "

they are legit directories; its all my movies !

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

ok; i went into settings and disabled "update movie library on startup"
now the log is clean, AND common.plugin.cache is in addons directory AND enabled:

here is the log of hight cpu:
http://pastebin.com/nH8nV2VA

here is the log right after with it DISABLED and cpu usage normal
http://pastebin.com/1Hq6kwwa

ericab · 2012-03-22, 22:25

ive read up on common.plugin.cache and enabled debugging in default.py

here is something new in the logfile:

00:21:17 T:2947537728 DEBUG: Process - The source file to load is /storage/.xbmc/addons/script.common.plugin.cache/default.py
00:21:17 T:2982660928 NOTICE: downloader ARGV: [' ']
00:21:17 T:2982660928 INFO: Scriptresult: Success
00:21:17 T:2982660928 INFO: Python script stopped
00:21:17 T:2982660928 DEBUG: Thread XBPyThread 2982660928 terminating

DDDamian · 2012-03-22, 22:29

(2012-03-22, 20:53)ericab Wrote: when that is moved from the addons directory; and reboot... cpu usage is completely normal.
if i move it back and reboot; back to 100% cpu.

(2012-03-22, 21:36)ericab Wrote: it has *always* been in the addons directory, and enabled with the logs im showing

Okay - just those two quotes seemed to conflict.

I guess the reason for wanting the "clean" debugs is to make it possible to spot the issue without reading a novel, and more importantly to actually see the issue. Pastebin has a limit on the size of a post, and in every case your logs are cut off short, so we don't actually see the issue. A Debug Log doesn't show everything, but a truncated Debug Log is seldom useful.

You obviously have an issue with UDisk and finding all those files, or at least how UDisk returns info to XBMC. As a result of all the log entries your log exceeds the Pastebin limits. It might also explain why the common.plugin.cache issues occur. Anyways, best of luck.

ericab · 2012-03-22, 22:32

well for the time being, can i safely keep script.common.plugin.cache out of the addons directory ?
what does it even do ?

ive posted over on the script.common.plugin.cache thread here on the forums.

bilbonvidia · 2012-03-22, 22:34

glad you solved, I do have that plugin in my addon folder.

**Martijn** · (This post was last modified: 2012-03-22, 22:37 by Martijn.)

(2012-03-22, 22:32)ericab Wrote: well for the time being, can i safely keep script.common.plugin.cache out of the addons directory ?
what does it even do ?

ive posted over on the script.common.plugin.cache thread here on the forums.

(2012-03-22, 22:34)bilbonvidia Wrote: glad you solved, I do have that plugin in my addon folder.

You can delete that add-on however it is used by several script for quick data acces (youtube plugin, Artwork Downloader and maybe more).
So they might break or be bad ass slow

Note:
use http://paste.ubuntu.com
this has no limit for logs ( i think)

TobiasTheCommie · 2012-03-23, 01:25

Hah, yes, script.common.plugin.cache is not at fault, so you can take that stupid grin of your face Martijn :þ

ericab · 2012-03-23, 01:35

a new update:

when my ethernet link is hooked up to my HTPC, common.cache constantly loads xbmc.bin @ 50-60% CPU usage , but when i unhook the ethernet link, cpu usage drops to a more normal 5-6% ?

**Martijn** · 2012-03-23, 01:37

(2012-03-23, 01:25)TobiasTheCommie Wrote: Hah, yes, script.common.plugin.cache is not at fault, so you can take that stupid grin of your face Martijn :þ

Not saying anything Big Grin

Use the commoncache a lot and not having this issue

DDDamian · 2012-03-23, 01:43

Yeah, his file system is a little messed up, and I think it's not even seeing commoncache as it's in a location that isn't mounting correctly.

DanLongman · 2012-03-23, 06:51

Hey so just tonight I noticed my CPU starting to go to 100% while idle.
ssh in and run top.

Looks like its upstart-udev-br at 100% cpu?

Weird thing is just got nyxboard. Reboot system cpu usage at idle is ~10% or less, then i plug in the RF transmittor for the nyxboard, jumps to 100% could this be related?

more:
I can confirm this is because of the nyxboard. I ssh'd in ran top and watched; Low CPU usage, And the second I plugged in the RF adapter the proc upstart-udev-br started and was at 100% CPU Usage.
Any idea what is going on?

now i can kill upstart-udev-br with a signal 9 and everything seems to work normally. with low CPU usage.
But what is this daemon and what is going on?

I will turn on debugging and get a log posted right away.

ericab · 2012-03-23, 06:57

Dan;

it doesn't sound related but it would be an interesting find if common.cache had something to do with it.......

maybe you could try to move /storage/.xbmc/addons/script.common.plugin.cache
down one level, and reboot. then try to plug in the RF adapter; while monitoring top of course.
report back !

DanLongman · (This post was last modified: 2012-03-23, 07:17 by DanLongman.)

Sure I can do that, Will report back right away.

for s&g's here is my log before touching common plugin cache.:
22:56:09 is when i plugged in rf

http://pastebin.com/x5sx5Z5A

Yes I think this is not related to your issue.

Yeah same thing happens with common plugin cache moved down a level.
Plug in RF adapter, upstart-udev-br jumps to 100% cpu usage and stays there.

like i said if i kill it everything seems to work fine, and so far I have not seen it respawn.
but what is it, and why is the nyxboard rf adapter making it mad.

Thanks for any help.

DanLongman · 2012-03-23, 07:21

more: So figured out its actually upstart-udev-bridge
here is the man page:

Code:
dan@XBMCNIX:~$ man upstart-udev-bridge

upstart-udev-bridge(8)                                  upstart-udev-bridge(8)

NAME

       upstart-udev-bridge - Bridge between Upstart and udev

SYNOPSIS

       upstart-udev-bridge [OPTIONS]...

DESCRIPTION

       upstart-udev-bridge  receives  information  about  kernel  uevents that

       udev(8) has completed and creates init(8) events for them.

       It emits events which match the pattern "S-device-A" where 'S'  is  the

       udev subsystem and 'A' is the udev action.  See udev(7) and for further

       details.

       Assuming /sys is mounted, possible values for subsystem for your system

       are viewable via /sys/class/.

EXAMPLES

       net-device-added

              Event emitted when a network device is added.

so not sure if bug with Nyxboard, or ubuntu bug. see bugs posted w/ google search.
And not sure what will happen leaving it not running. shouldn't be a problem, but pain to have to kill -9 it everytime i reboot.