search

jasonmc / forked-daapd

A re-write of the firefly media server (mt-daapd). It's released under GPLv2+. Please note that this git repository is a mirror of the official one at git://git.debian.org/~jblache/forked-daapd.git
http://blog.technologeek.org/2009/06/12/217
GNU General Public License v2.0
328 stars 45 forks source link

High CPU usage in every 5 minutes #91

Open sebestenyb opened 12 years ago

sebestenyb commented 12 years ago

Hi guys

I have a external harddrive called WD My Book Live Duo, which comes with a preinstalled forked-daapd. After moving my music library (~30k tracks, ~1200 artists, in a library structure of artist/album) I have a bit annoying issue. Approximately every 5 minutes the CPU usage of forked-daapd (checked by top on the device) jumps up to 100% for a few seconds, which is just enough to interrupt the playback for a few seconds, and force iTunes to rebuffer.

Is there any process in forked-daapd, which runs in every 5 minutes, and can cause this issue?

The related forum post on WD's forum: http://community.wdc.com/t5/My-Book-Live-Duo/iTunes-server-performance/m-p/394861/

Maybe related issues here: https://github.com/jasonmc/forked-daapd/issues/70 https://github.com/jasonmc/forked-daapd/issues/19 https://github.com/CBGoodBuddy/forked-daapd/commit/bd10978d5240bc22c03a6f3bd0492a6318b7d67d

Previously I used a Thecus N2100, which had a mt-daapd - and I've never had this kind of issue with the same library, even that's a much weaker device that the WD.

I'd really appreciate any advice, thanks, Balazs

elwertk commented 12 years ago

Hi! No idea of the version running on your WD device but here is an educated guess what may go on.

It seems you are running a version that has a fix applied for the 5 minute disconnect issue. Unfortunately as it looks it is not final one. It rather looks someone applied a quick fix by incrementing the db_rev cylce each update cycle. That does fix the disconnects but comes with a huge downside as it forces a reload of your entire library every 5 minutes. Not unlikely this cause the CPU peaks you are seeing.

If this is the case the solution would be to merge in the final solution and patch available for your platform.

All of the above is discussed in length in https://github.com/jasonmc/forked-daapd/issues/19

hope this helps

K.

sebestenyb commented 12 years ago

Cool, thanks for the quick and nice answer.

Unfortunately this is way beyond my knowledge, but I raised the issue for the WD support - I'm quite interested int heir response.

Oh, the version is:

Forked Media Server: Version 0.19 Copyright (C) 2009-2011 Julien BLACHE jb@jblache.org Based on mt-daapd, Copyright (C) 2003-2007 Ron Pedde ron@pedde.com Released under the GNU General Public License version 2 or later

I'm afraid it doesn't tell to much about the branch of it's codebase...

Cheers, Balazs

sebestenyb commented 12 years ago

FYI: http://community.wdc.com/t5/My-Book-Live-Duo/iTunes-server-performance/m-p/394861#M864

I built forked-daap on a Virtual Box'ed Debian, and it works without disconnection and CPU peaks. Even the remote pairing is working, which I couldn't get to work on the WD device (the symptoms were: https://github.com/jasonmc/forked-daapd/issues/80)

Sadly I have no idea how to build it for the device :)

sebestenyb commented 12 years ago

Managed to build it on the device, ffmpeg needed some configure tweaks (--disable-altivec) since it has a PPC processor. Interestingly enough, the remote pairing still suffers the symptoms described in https://github.com/jasonmc/forked-daapd/issues/80.

I'm testing the stability of the server today, and maybe I'll try to investigate that issue.

Thanks for your help, @elwertk

elwertk commented 12 years ago

Glad you got it working.

I still belive the pairing thing is a non issue caused by dodgy characters in the idevice name. See README:

"Watch out for fancy characters; for instance, the name of your device may include Unicode characters that aren't visually different from plain ASCII characters (like the single quote if your device name follows the default scheme of "Foo's iPhone"). If unsure, change the name of your device or capture the output in a file to extract the real, correct name."

So either change the idevice name to something fail proofed. Or redirect the output of

avahi-browse -r -k _touch-remote._tcp > foobla

and examine the DvNM for non ASCII chars and/or eventualy build the .remote file from it.

sebestenyb commented 12 years ago

Yea, I've read that, and renamed my son's iPod Touch to "iPod Touch", so except a space there's nothing fancy in that. And the pairing works in my test build in the VM-ed Debian. Also keep in mind that based on the log (see details in issue #80) the pairing is successful.

Anyway, I'll keep looking - thanks again.

Ps: the server is running since that, new files added, listened across the afternoon, no hickups, cool :)

sebestenyb commented 12 years ago

I tried what you mentioned, redirected the output of the avahi-browse to a file, removed the not needed parts, and used that file as *.remote, with the PIN, the result is the same.

The avahi is not the same on the device and the Debian I used to test - and where the remote pairing was working: device: avahi-daemon 0.6.25 test debian: avahi-daemon 0.6.27

elwertk commented 12 years ago

Have you tried pairing on your device with a smaller library for testing purpose? 30k songs will keep the scan busy for a while on a smaller device.

This seems like a fairly good step by step: https://github.com/jasonmc/forked-daapd/issues/41

Other than that it could be any sort of dependencies not behaving as it should as this is a PPC device. But as they ship it with their firmware I do not believe you to be the first discovering pairing is not working at all?

sebestenyb commented 12 years ago

I've tried with a library, which has only 80 tracks, the result is the same, here's the spam level log:

[2012-05-12 08:51:06]     mdns: Avahi Browser: NEW service '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615' type '_touch-remote._tcp' proto 0
[2012-05-12 08:51:06]     mdns: Avahi Browser: NEW service '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615' type '_touch-remote._tcp' proto 1
[2012-05-12 08:51:06]     mdns: Avahi Resolver: resolved service '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615' type '_touch-remote._tcp' proto 0
[2012-05-12 08:51:06]     mdns: Service 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615, hostname iPod-touch.local resolved to 192.168.0.101
[2012-05-12 08:51:06]   remote: Discovered remote iPod touch (id 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615) at [192.168.0.101]:51854, paircode 6820353EFFC0E37B
[2012-05-12 08:51:06]   remote: Remote id 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615 not known, adding
[2012-05-12 08:51:11]     mdns: Avahi Resolver failure: service '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615' type '_touch-remote._tcp': Timeout reached
[2012-05-12 08:51:24]       db: Running query 'SELECT * FROM inotify WHERE wd = 5;'
[2012-05-12 08:51:24]     scan: File event: 0x100, cookie 0x0, wd 5
[2012-05-12 08:51:25]   remote: Adding Remote pin data: name 'iPod touch', pin '7900'
[2012-05-12 08:51:25]   remote: Remote 'iPod touch' found
[2012-05-12 08:51:25]       db: Running query 'SELECT * FROM inotify WHERE wd = 5;'
[2012-05-12 08:51:25]     scan: File event: 0x2, cookie 0x0, wd 5
[2012-05-12 08:51:25]   remote: Adding Remote pin data: name 'iPod touch', pin '7900'
[2012-05-12 08:51:25]   remote: Remote 'iPod touch' found
[2012-05-12 08:51:25]       db: Running query 'SELECT * FROM inotify WHERE wd = 5;'
[2012-05-12 08:51:25]     scan: File event: 0x8, cookie 0x0, wd 5
[2012-05-12 08:51:25]   remote: Adding Remote pin data: name 'iPod touch', pin '7900'
[2012-05-12 08:51:25]   remote: Remote 'iPod touch' found
[2012-05-12 08:51:25]   remote: Pairing hash for 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615/iPod touch: 6485EC1DF49743CA1F09F372429B6FD0
[2012-05-12 08:51:25]   remote: Pairing succeeded with Remote 'iPod touch' (id 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615), GUID: 061F07FB51FE4498
[2012-05-12 08:51:25]       db: Running query 'DELETE FROM pairings WHERE remote = '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615';'
[2012-05-12 08:51:25]       db: Running query 'INSERT INTO pairings (remote, name, guid) VALUES ('49888eb7a9e2199a7f1ded4efb996fa0cdf4b615', 'iPod touch', '061F07FB51FE4498');'
[2012-05-12 08:51:26]     mdns: Avahi Browser: REMOVE service '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615' type '_touch-remote._tcp' proto 0
[2012-05-12 08:51:26]   remote: Remote 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615 not found in list
[2012-05-12 08:51:26]     mdns: Avahi Browser: REMOVE service '49888eb7a9e2199a7f1ded4efb996fa0cdf4b615' type '_touch-remote._tcp' proto 1
[2012-05-12 08:51:26]   remote: Remote 49888eb7a9e2199a7f1ded4efb996fa0cdf4b615 not found in list

That timeout seems a bit strange for me, 5ms?

Cheers, Balazs

sebestenyb commented 12 years ago

Today I played around a bit with a Debian install in Virtual Box and my Western Digital MyBook Live Duo, trying to get the Remote.app working. I compared the installs, and realized that I have a couple of differences between the two avahi-daemon.conf files. Since the remote pairing works fine in Debian, but not in the WD-MBLD, I copied the different values over, and suddenly it started working on the device too:

[publish]
# commented out the original values
disable-publishing=no               #yes
disable-user-service-publishing=no      #yes
#add-service-cookie=no
publish-addresses=yes               #no
publish-hinfo=yes               #no
publish-workstation=yes             #no
publish-domain=yes              #no

I don't really have any idea what did I change, and why those values prevented the pairing of the remotes, but now it seems to work, maybe it will help others as well :)